[Xymon] Integer underflow in FILE mtime/ctime/atime check

[Axel Beckert]

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 is

    file:`ls -1 $(ls -1d /nf/2???/??/??/ | tail -1)* | tail -1`

  to 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-bug`

* analysis.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/patches/93_fix_integer_underflow_in_files_check.patch)

		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/