Hi,
at least in Xymon 4.2.28 (plus recent CVE patches, i.e. as currently in Debian Stable) there is an issue with an integer underflow in the FILE mtime/ctime/atime check which basically seems to happen when finding the file to check takes a moment (seconds) and the file in question has been modified after the search for the file has been started.
In such cases this integer underflow happens and causes a falso positive due to instead of the time difference being negative, it's insanely huge:
[red] /nf/2020/08/12/nfcapd.202008122015 File was modified 4294967289 seconds ago - should be <360 File was modified 4294967289 seconds ago - should be <960
So far for me this only happened, when
client-local.cfg contains
...commands to find the file, in our example it isfile:
ls -1 $(ls -1d /nf/2???/??/??/ | tail -1)* | tail -1to find the newest file under /nf/20??/ by first looking for the most recent directory and then finding the most recent file (both by just sorting them alphabetically) as listing all files would take much too long, hence the nested
... $() ....The corresponding entries in analysis.cfg are
FILE %/nf/[0-9]*/[0-9]*/[0-9]*/nfcapd.[0-9]* MTIME<360 SIZE>9000000 yellow FILE %/nf/[0-9]*/[0-9]*/[0-9]*/nfcapd.[0-9]* MTIME<960 SIZE>1500 red
On a machine with slow I/O, in our case on a not that strong VM used for testing.
I tried to reproduce this on a Raspberry Pi with a much simpler setup and Xymon 4.3.30, but failed so far and don't know, why:
client-local.cfg entry:
file:
sleep 90; echo /run/xymon-integer-underflow-buganalysis.cfg entries:
FILE /run/xymon-integer-underflow-bug red mtime<61 FILE /run/xymon-integer-underflow-bug yellow mtime>0
I then setup a cron job, touching the file every minute. Hence the 61 in the checks above.
Unfortunately this didn't suffice to trigger this issue. It is unclear to me why as the only explanation I have is the additional time needed to find the appropriate file to test. And the relevant code doesn't seem to have changed between 4.3.28 and 4.3.30...
So I cheated a bit and setup the cron job to always set the file stamp to one hour in the future using "touch -d 'next hour' . Then I at least could trigger that integer underflow:
red /run/xymon-integer-underflow-bug File was modified 4294963714 seconds ago - should be <61
I think there are several ways to fix this:
Move capturing the "now" timestamp just before checking the files timestamps, not before finding that file. Haven't noticed where the actual stat call is, though.
Use an signed instead of an unsigned integer to properly handle negative time differences. Tried to implement this as a patch as it seemed easy enough.
So far I managed to get this far:
[red] /run/xymon-integer-underflow-bug File was modified -3592 seconds ago - should be <61
So I guess that patch still needs more finetuning. Will send it once I got it fully working as I expect. But if there's interest in the incomplete patch already, I'm happy to send it anyways. (Respectively it is already online at https://salsa.debian.org/debian/xymon/-/blob/files-integer-undeflow/debian/p...)
Kind regards, Axel-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/