Date: Sat, 27 Jul 2013 00:57:33 -0600 From: Kurt Seifried <kseifried@...hat.com> To: oss-security@...ts.openwall.com CC: Salvatore Bonaccorso <carnil@...ian.org>, henrik@...n.dk Subject: Re: CVE Request: Xymon Systems and Network Monitor - remote file deletion vulnerability -----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 . > >  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@...n.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-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.