Hi,
I have released version 4.3.12 of Xymon on Sourceforge, and it is available from http://sourceforge.net/projects/xymon/files/Xymon/4.3.12/ . Due to a security bugfix, I strongly recommend upgrading to this version.
Regards, Henrik
NOTE: This release includes a bugfix for a security issue in the xymond_history and xymond_rrd modules. A "drophost" command sent to the xymond port (default: 1984) from an IP listed in the --admin-senders access control list can be used to delete files owned by the user running the xymond daemon. This is allowed by default, so it is highly recommended
List of changes:
rev 7211
Security fix: Guard against directory traversal via hostname in "drophost" commands
Fix crash in xymongen introduced in 4.3.11
SCO client: Fix overflow in memory calculation when >2 GB memory
Fix so "include" and "directory" definitions in configuration files now handle <tab> after the keyword
Fix for the Xymon webpage menu on iPad's and Android (touch devices)
Fix "drophost" handling so the host data directory is also cleared
xymond_rrd now processes data from "clear" status messages
Xymon clients now report the version number in the client data
Linux clients now align "ps" output so it is more readable.
New "generic" client message handler allows log/file monitoring from systems that are not known to Xymon.
The Xymon client now works if invoked with a relative path to the runclient.sh script
Other minor / internal bugfixes
Am 24.07.2013 11:13, schrieb henrik at hswn.dk:
Hi,
I have released version 4.3.12 of Xymon on Sourceforge, and it is available from http://sourceforge.net/projects/xymon/files/Xymon/4.3.12/ . Due to a security bugfix, I strongly recommend upgrading to this version.
Regards, Henrik
Hi Henrik, it seems you have only amd64 debs released, also i see deb dsc etc to recompile for 32 any hints for getting 32 version ?
NOTE: This release includes a bugfix for a security issue in the xymond_history and xymond_rrd modules. A "drophost" command sent to the xymond port (default: 1984) from an IP listed in the --admin-senders access control list can be used to delete files owned by the user running the xymond daemon. This is allowed by default, so it is highly recommended
List of changes:
rev 7211
Security fix: Guard against directory traversal via hostname in "drophost" commands
Fix crash in xymongen introduced in 4.3.11
SCO client: Fix overflow in memory calculation when >2 GB memory
Fix so "include" and "directory" definitions in configuration files now handle <tab> after the keyword
Fix for the Xymon webpage menu on iPad's and Android (touch devices)
Fix "drophost" handling so the host data directory is also cleared
xymond_rrd now processes data from "clear" status messages
Xymon clients now report the version number in the client data
Linux clients now align "ps" output so it is more readable.
New "generic" client message handler allows log/file monitoring from systems that are not known to Xymon.
The Xymon client now works if invoked with a relative path to the runclient.sh script
Other minor / internal bugfixes
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Am 24.07.2013 11:30, schrieb Robert Schetterer:
Am 24.07.2013 11:13, schrieb henrik at hswn.dk:
Hi,
I have released version 4.3.12 of Xymon on Sourceforge, and it is available from http://sourceforge.net/projects/xymon/files/Xymon/4.3.12/ . Due to a security bugfix, I strongly recommend upgrading to this version.
Regards, Henrik
Hi Henrik, it seems you have only amd64 debs released, also i see deb dsc etc to recompile for 32 any hints for getting 32 version ?
sorry for the noise got it
http://xymon.sourceforge.net/xymon/help/install.html
NOTE: This release includes a bugfix for a security issue in the xymond_history and xymond_rrd modules. A "drophost" command sent to the xymond port (default: 1984) from an IP listed in the --admin-senders access control list can be used to delete files owned by the user running the xymond daemon. This is allowed by default, so it is highly recommended
List of changes:
rev 7211
Security fix: Guard against directory traversal via hostname in "drophost" commands
Fix crash in xymongen introduced in 4.3.11
SCO client: Fix overflow in memory calculation when >2 GB memory
Fix so "include" and "directory" definitions in configuration files now handle <tab> after the keyword
Fix for the Xymon webpage menu on iPad's and Android (touch devices)
Fix "drophost" handling so the host data directory is also cleared
xymond_rrd now processes data from "clear" status messages
Xymon clients now report the version number in the client data
Linux clients now align "ps" output so it is more readable.
New "generic" client message handler allows log/file monitoring from systems that are not known to Xymon.
The Xymon client now works if invoked with a relative path to the runclient.sh script
Other minor / internal bugfixes
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Best Regards MfG Robert Schetterer
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Den 24.07.2013 11:30, Robert Schetterer skrev:
Am 24.07.2013 11:13, schrieb henrik at hswn.dk:
I have released version 4.3.12 of Xymon on Sourceforge, and it is available from http://sourceforge.net/projects/xymon/files/Xymon/4.3.12/
Hi Henrik, it seems you have only amd64 debs released, also i see deb dsc etc to recompile for 32
I see you found out how to do it. I do plan on putting 32-bit deb-files up for download, but cannot do that until later today when I am back at my build system.
Regards, Henrik
Hi,
On Wed, Jul 24, 2013 at 11:13:00AM +0200, henrik at hswn.dk wrote:
NOTE: This release includes a bugfix for a security issue in the xymond_history and xymond_rrd modules. A "drophost" command sent to the xymond port (default: 1984) from an IP listed in the --admin-senders access control list can be used to delete files owned by the user running the xymond daemon. This is allowed by default, so it is highly recommended
Does a CVE id exist for that vulnerability?
Is it known which Xymon versions are affected by that vulnerability?
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/
On 25-07-2013 17:36, Axel Beckert wrote:
On Wed, Jul 24, 2013 at 11:13:00AM +0200, henrik at hswn.dk wrote:
NOTE: This release includes a bugfix for a security issue in the xymond_history and xymond_rrd modules. A "drophost" command sent to the xymond port (default: 1984) from an IP listed in the --admin-senders access control list can be used to delete files owned by the user running the xymond daemon. This is allowed by default, so it is highly recommended
Does a CVE id exist for that vulnerability?
No. I suppose I could figure out how to request one - unless someone else already knows how ?
Is it known which Xymon versions are affected by that vulnerability?
All versions from 4.0 -> 4.3.11
Regards, Henrik
Hi Henrik,
thanks for the prompt reply.
On Thu, Jul 25, 2013 at 06:09:40PM +0200, Henrik Størner wrote:
Does a CVE id exist for that vulnerability?
No. I suppose I could figure out how to request one - unless someone else already knows how ?
I requested one via the Debian Security Team.
Is it known which Xymon versions are affected by that vulnerability?
All versions from 4.0 -> 4.3.11
Thanks for the information.
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/
Hi Henrik,
On Fri, Jul 26, 2013 at 10:34:21AM +0200, Axel Beckert wrote:
On Thu, Jul 25, 2013 at 06:09:40PM +0200, Henrik Størner wrote:
Does a CVE id exist for that vulnerability?
No. I suppose I could figure out how to request one - unless someone else already knows how ?
I requested one via the Debian Security Team.
CVE-2013-4173[1] has been assigned to this issue. Thanks to Salvatore Bonaccorso for his help.
[1] http://article.gmane.org/gmane.comp.security.oss.general/10728
In case you want to request one yourself next time, see https://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html for instructions.
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/
On 07/27/13 03:53, Axel Beckert wrote:
Hi Henrik,
On Fri, Jul 26, 2013 at 10:34:21AM +0200, Axel Beckert wrote:
On Thu, Jul 25, 2013 at 06:09:40PM +0200, Henrik Størner wrote:
Does a CVE id exist for that vulnerability?
No. I suppose I could figure out how to request one - unless someone else already knows how ?
I requested one via the Debian Security Team.
CVE-2013-4173[1] has been assigned to this issue. Thanks to Salvatore Bonaccorso for his help.
[1] http://article.gmane.org/gmane.comp.security.oss.general/10728
In case you want to request one yourself next time, see https://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html for instructions.
Kind regards, Axel Beckert
Hi Axel, Henrik
I noticed in the CVE link provided the following:
--[snip]--
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. --[snip]--
However, I checked several Xymon and Hobbit installations that we manage and each of them has the --admin-senders=127.0.0.1,$BBSERVERIP (for hobbit) and --admin-senders=127.0.0.1,$XYMONSERVERIP (for xymon) set.
I know for a fact that these settings were not manually added to the xymond daemon CMDs on our servers, so this appears to be the default, which means that by default Xymon (and Hobbit) systems are "not vulnerable."
Am I missing something?
Thanks!
-- Bill Arlofski Reverse Polarity, LLC http://www.revpol.com/ -- Not responsible for anything below this line --
Den 30.07.2013 14:01, Bill Arlofski skrev:
I noticed in the CVE link provided the following:
--[snip]--
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. --[snip]--
However, I checked several Xymon and Hobbit installations that we manage and each of them has the --admin-senders=127.0.0.1,$BBSERVERIP (for hobbit) and --admin-senders=127.0.0.1,$XYMONSERVERIP (for xymon) set.
I know for a fact that these settings were not manually added to the xymond daemon CMDs on our servers, so this appears to be the default, which means that by default Xymon (and Hobbit) systems are "not vulnerable."
Several people have pointed this out to me - I was mistaken when I wrote the vulnerability notice for Bugtraq. You are correct that the default installation is not vulnerable.
Regards, Henrik
Good morning, Henrik.
I was wondering if you would consider including a spec file in the tarball, so that those of us running RPM based distro's (RHEL, CentOS, etc) could use rpmbuild to build RPMs for our systems.
Thanks.
Mike Burger http://www.bubbanfriends.org
"It's always suicide-mission this, save-the-planet that. No one ever just stops by to say 'hi' anymore." --Colonel Jack O'Neill, SG1
From noon on August 3rd thru noon on August 4, I'll be participating in a 24 hour cycling relay to benefit the CASAs for Kids fund. If you'd care to donate, please visit:
casasforkidsfund.kintera.org/faf/donorReg/donorPledge.asp?ievent=1051384&supId=388504798
Thank you.
Hi,
I have released version 4.3.12 of Xymon on Sourceforge, and it is available from http://sourceforge.net/projects/xymon/files/Xymon/4.3.12/ . Due to a security bugfix, I strongly recommend upgrading to this version.
Regards, Henrik
NOTE: This release includes a bugfix for a security issue in the xymond_history and xymond_rrd modules. A "drophost" command sent to the xymond port (default: 1984) from an IP listed in the --admin-senders access control list can be used to delete files owned by the user running the xymond daemon. This is allowed by default, so it is highly recommended
List of changes:
rev 7211
Security fix: Guard against directory traversal via hostname in "drophost" commands
Fix crash in xymongen introduced in 4.3.11
SCO client: Fix overflow in memory calculation when >2 GB memory
Fix so "include" and "directory" definitions in configuration files now handle <tab> after the keyword
Fix for the Xymon webpage menu on iPad's and Android (touch devices)
Fix "drophost" handling so the host data directory is also cleared
xymond_rrd now processes data from "clear" status messages
Xymon clients now report the version number in the client data
Linux clients now align "ps" output so it is more readable.
New "generic" client message handler allows log/file monitoring from systems that are not known to Xymon.
The Xymon client now works if invoked with a relative path to the runclient.sh script
Other minor / internal bugfixes
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Hello everyone!
I've released updated Xymon RPMs at http://terabithia.org/rpms/xymon/ for version 4.3.12, built for EL5, EL6, and Fedora 19. This includes the recent security update and all upstream changes.
As it's been a while since the last "announced" RPM release, and due to the large number of former patches that were integrated into the main distribution, I strongly suggest letting these smoke in a test environment before placing them into production (always a good idea, I know :) ).
Previous users of RPMs in the /testing/ directories should note that some experimental add-ons now require environment variables to be set to activate. In addition, please pay close attention to .rpmnew config files in /etc/xymon/ and the apache configuration snippet to ensure proper functioning and support of new features.
Many thanks as always to Henrik, for the design and release of an outstandingly flexible and scalable monitoring project!
Regards,
-jc
Hi,
On 26-07-2013 15:55, Mike Burger wrote:
Good morning, Henrik.
I was wondering if you would consider including a spec file in the tarball, so that those of us running RPM based distro's (RHEL, CentOS, etc) could use rpmbuild to build RPMs for our systems.
You mean, like the one in "rpm/xymon.spec" ?
Seriously - although there is a spec file in the tar-ball, my knowledge of RPM-building is very outdated (I stopped using rpm-based distro's several years ago). So I prefer to let others handle the task of building Xymon RPM's. jc maintains a set of Xymon RPM's over at http://terabithia.org/rpms/xymon/ and from what I hear they are quite good.
Regards, Henrik
I've used them...but his site also says that they're "not official rpms" so I wasn't sure if there was a more "official" method.
I thought I'd tried to run rpmbuild against the tarballs, before, and received a message back that no spec file could be found.
However, if JC is pretty much maintaining, I'm good with that, too.
Thanks.
-- Mike Burger AIX Administrator
Phone (317) 537-3680, Fax (317) 537-4680, Cell (317) 797-2040 E-mail: Mike.Burger at FreedomMortgage.com
participants (7)
-
beckert@phys.ethz.ch
-
cleaver@terabithia.org
-
henrik@hswn.dk
-
mburger@bubbanfriends.org
-
Mike.Burger@FreedomMortgage.com
-
rs@sys4.de
-
waa-hobbitml@revpol.com