Xymon Systems and Network Monitor - remote file deletion vulnerability
Hi,
a security vulnerability has been found in version 4.x of the Xymon Systems & Network Monitor tool (https://sourceforge.net/projects/xymon/).
Impact
The error permits a remote attacker to delete files on the server running the Xymon trend-data daemon "xymond_rrd". File deletion is done with the privileges of the user that Xymon is running with, so it is limited to files available to the userid running the Xymon service. This includes all historical data stored by the Xymon monitoring system.
Vulnerable versions
All Xymon 4.x versions prior to 4.3.12 with the xymond_rrd module enabled (this is the default configuration).
Note that Xymon was called "Hobbit" from version 4.0 to 4.2; all of the "Hobbit" versions are also vulnerable.
Mitigating factors
The attack requires access to the xymond network port (default: tcp port 1984).
If access to administrative commands is limited by use of the "--admin-senders" option for the "xymond" daemon, then the attack is restricted to the commands sent from the IP-adresses listed in the --admin-senders access list. However, the default configuration permits these commands to be sent from any IP.
Systems where xymond_rrd is disabled are not vulnerable, but this is not the default configuration.
Details
Xymon stores historical data, trend-data etc. for each monitored host in a set of directories below the Xymon "server/data/" directory. Each monitored host has a set of directories named by the hostname.
When a host is no longer monitored, the data stored for the host can be removed by sending a "drop HOSTNAME" command to the Xymon master daemon. This is forwarded to xymond_rrd and other modules which then handle deleting various parts of the stored data, essentially by performing the equivalent of "rm -rf <xymondatadirectory>/rrd/HOSTNAME". In the vulnerable versions of Xymon, the hostname sent to xymond was used without any checking, so a hostname could include one or more "../" sequences to delete files outside the intended directory.
There are other modules that delete files in response to a "drophost" command, but for various reasons these are not vulnerable to the attack.
Credit and timeline
The bug was discovered by "cleaver" during investigation of a bug originally reported to the Xymon mailing list on July 17 - http://lists.xymon.com/archive/2013-July/037838.html - and I was notified via private e-mail on July 21st when it was realized to be a security related issue.
A bugfix - r7199 - was committed to the Sourceforge SVN code repository on July 23rd, and version 4.3.12 was released on July 24th.
Henrik Størner Xymon developer
Thank you so much for the notice and quick response, Henrik!
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
On Thu, Jul 25, 2013 at 1:35 PM, Henrik Størner <henrik at hswn.dk> wrote:
Hi,
a security vulnerability has been found in version 4.x of the Xymon Systems & Network Monitor tool (https://sourceforge.net/projects/xymon/).
Impact
The error permits a remote attacker to delete files on the server running the Xymon trend-data daemon "xymond_rrd". File deletion is done with the privileges of the user that Xymon is running with, so it is limited to files available to the userid running the Xymon service. This includes all historical data stored by the Xymon monitoring system.
Vulnerable versions
All Xymon 4.x versions prior to 4.3.12 with the xymond_rrd module enabled (this is the default configuration).
Note that Xymon was called "Hobbit" from version 4.0 to 4.2; all of the "Hobbit" versions are also vulnerable.
Mitigating factors
The attack requires access to the xymond network port (default: tcp port 1984).
If access to administrative commands is limited by use of the "--admin-senders" option for the "xymond" daemon, then the attack is restricted to the commands sent from the IP-adresses listed in the --admin-senders access list. However, the default configuration permits these commands to be sent from any IP.
Systems where xymond_rrd is disabled are not vulnerable, but this is not the default configuration.
Details
Xymon stores historical data, trend-data etc. for each monitored host in a set of directories below the Xymon "server/data/" directory. Each monitored host has a set of directories named by the hostname.
When a host is no longer monitored, the data stored for the host can be removed by sending a "drop HOSTNAME" command to the Xymon master daemon. This is forwarded to xymond_rrd and other modules which then handle deleting various parts of the stored data, essentially by performing the equivalent of "rm -rf <xymondatadirectory>/rrd/HOSTNAME". In the vulnerable versions of Xymon, the hostname sent to xymond was used without any checking, so a hostname could include one or more "../" sequences to delete files outside the intended directory.
There are other modules that delete files in response to a "drophost" command, but for various reasons these are not vulnerable to the attack.
Credit and timeline
The bug was discovered by "cleaver" during investigation of a bug originally reported to the Xymon mailing list on July 17 - http://lists.xymon.com/archive/2013-July/037838.html - and I was notified via private e-mail on July 21st when it was realized to be a security related issue.
A bugfix - r7199 - was committed to the Sourceforge SVN code repository on July 23rd, and version 4.3.12 was released on July 24th.
Henrik Størner Xymon developer
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Hi Henrik,
On Thu, Jul 25, 2013 at 07:35:23PM +0200, Henrik Størner wrote:
If access to administrative commands is limited by use of the "--admin-senders" option for the "xymond" daemon, then the attack is restricted to the commands sent from the IP-adresses listed in the --admin-senders access list. However, the default configuration permits these commands to be sent from any IP.
At least for 4.3.11 I could not reproduce the fact that the default config permits these commands to be sent from any IP.
The installed tasks.cfg as well as tasks.cfg.DIST both contain these lines:
[xymond]
[...]
CMD xymond --pidfile=$XYMONSERVERLOGS/xymond.pid
--restart=$XYMONTMP/xymond.chk --checkpoint-file=$XYMONTMP/xymond.chk --checkpoint-interval=600
--log=$XYMONSERVERLOGS/xymond.log
--admin-senders=127.0.0.1,$XYMONSERVERIP
^^^^^^^^^^^^^^^^^^^^^^^^
--store-clientlogs=!msgs
(This does not lower the severity of the missing basename call in xymond_rrd, but may lower the impact with regards to how many installations are remotely vulnerable.)
Kind regards, Axel Beckert
-- Axel Beckert <beckert at phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT H 6 voice: +41 44 633 41 89 Departement of Physics, ETH Zurich CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/
participants (3)
-
beckert@phys.ethz.ch
-
henrik@hswn.dk
-
josh@imaginenetworksllc.com