Re: CVE Request: Xymon Systems and Network Monitor - remote file deletion vulnerability

[Kurt Seifried <kseifried () redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/26/2013 02:27 AM, Salvatore Bonaccorso wrote:
> Hi Kurt
>
> Henrik Størner (CC'ed) announced on xymon mailinglist and bugtraq
> an update for Xymon, a systems and network monitor. xymon is
> vulnerable to a remote file deletion vulnerability (see attached
> full announce text).
>
> Upstream commit fixing the issue is at [1].
>
> [1] http://sourceforge.net/p/xymon/code/7199/
>
> Can a CVE be assigned to this issue?

Excellent request! Please use CVE-2013-4173 for this issue.


> Regards, Salvatore
>
> ----- Forwarded message from Henrik Størner <henrik () hswn dk> -----
>
> 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
>
> ----- End forwarded message -----



- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJR829dAAoJEBYNRVNeJnmTGAYP/1bnFiu8Hk5RwP4ypJ58lwEu
vL6nxs9ZYuNBUTWQ7d+nreVrmla0vhhTs2juAq0NauPkcdUYIYu2Xm8Lropbvc+D
jV7IVYzaOAnxQC+pjyo1vo7uG5A6+d4V4jOX3L/MzT/Kbp8JWurc+gUypy3cVifQ
wzK0CSR9UJAhExoaoCs6gritEpi3tyvEEzokJzwev2cj31MUtxIr03pP2H2PAGXn
2SFO63egtn2tY6l4cY3DKo1J+x0if+4PjcPQFThqF55YrEC3dKmkY4ODO2385cJr
c5Ho2nqA66mUWHt5LRoz7Ok4+yee5Hq7HBcYR0JYJ1kktfx+gxAHS1h4SSeyOM0+
wlfn7NDlgG6AswGSrtVHUSYlTeETIrdCiGJ3KY6EGTB+xbJwD2Rut+MZlPOYzYU/
ZLTv8UxGnxcKXPsDwusmWWYYAi1ZZvb0Ic/B1BlTCoZHcKo2aDMzxejpT5gJjIWz
yt2W8jzi244ckv2TgFOWJ9sCYhCSn1YQvm5Pqj/jPG4rHBxlmYjg1GkEUn6gPuob
3QioZDNEZEwCxOSAQn969dbAxYRbOXXicm+trgck/tHQ141n8HM6zFz18Mcag61z
WweL/+ob8OmBnoUdgx2jCASUHpL+94l3GDSCddlDE4NiahLoEIbsWGh8sMjnXXkt
2aw2uR0elzjwRUN64atz
=Qgss
-----END PGP SIGNATURE-----