The default for logfetch's options (found in /etc/xymon/xymonclient.cfg) is:

LOGFETCHOPTS=""

which enables it to execute arbitrary code [1]. This can and should be
prevented by default by using

LOGFETCHOPTS="--noexec"

instead.

Best regards
Christoph Zechner


patch:
--- xymonclient.cfg.DISt
+++ xymonclient.cfg.PATCHED
@@ -18,7 +18,7 @@
  include /var/run/xymon/xymonclient-include.cfg

  # Options to logfetch, the xymon binary which examines log files for
recent changes.
-LOGFETCHOPTS=""
+LOGFETCHOPTS="--noexec"


  # Local Mode (Only) Options


[1] https://manpages.debian.org/bullseye/xymon-client/logfetch.1.en.html

Hi,

Christoph Zechner wrote:

Yes, I saw the discussion on that on the upstream mailing list[2]. As
mentioned there by others, this is on purpose and only during a "pull"
from the server, i.e. no remote code execution by arbitrary attackers.
I updated the bug report title accordingly.

[2] https://lists.xymon.com/archive/2021-October/thread.html#47749

Downside here is that Xymon doesn't use TLS and hence DNS spoofing
attacks might be able to redirect the client's connection if hostnames
instead of the recommended IPs are used in /etc/default/xymon-client.

Otherwise attacking this would require first hijacking either the
routing or a router inbetween for a MITM attack on this.

Hrm. The Debian package for sure will switch that option if upstream
does.

I'm though currently a bit reluctant to apply this patch and deviate
from upstream's defaults (even more) since the default settings with
IP addresses are less prone to that attack as if the admin uses DNS
names instead of the recommended use of IP addresses for the server.
Tagging as "upstream" for now.

JFTR: I use that feature in some places and I don't know how widely it
is used by others. I though suspect it is indeed used rather rarely.
The common use-case seems to be if the syslog server adds a date
extension already upon file creation so that logrotate becomes
unnecessary. AFAIK none of Debian's syslog servers does that by
default, though.

Myon: Any opinion on this?

		Regards, Axel

Re: Axel Beckert

I guess most installations don't need the feature, so we could indeed
disable it by default, and put a note into README.Debian (+ NEWS) that
people need to actively enable it.

Christoph

Hi again,

Christoph Zechner wrote:

This is clearly not "critical". Myon already fixed that.

It is also no root security hole. It gives you access to the xymon
user only. (If the admin configured the xymon user to be able to use
sudo, that's another problem.)

		Regards, Axel

Hi Christoph,

I admittedly just noticed the severity which the bug reporter set when
seeing this mail:

Debian Bug Tracking System wrote:

"critical" is indeed clearly wrong. I'd have rather said "important"
only as the claim of being a "root hole" is wrong. But ok.

I'm though not sure if this is acceptable for stable updates as it is
a rather invasive change IMHO.

		Regards, Axel

Re: Axel Beckert

I only moved it off "critical" which it really is not. If you think
important (or wishlist?) makes more sense, go ahead.

It would be ok if we buy the security part.

Christoph

Hi,

Apologies for that, I was not sure how to classify it, but since it was
a security-related issue, I thought it was appropriate.

That's true, reportbug stated "introduces a security hole allowing
access to root (or another privileged system account), or data normally
accessible only such accounts" and since xymon automatically creates a
few sudoers entries for its plugins, I thought it best to use this.
Sorry if that was a little over-zealous. :-/

Cheers
Christoph

Hi,

Christoph Berg wrote:

For me, "important" seems appropriate. If the security team disagrees,
I'm fine with their opinion on this issue as I might be a bit biased
here as I use and value the feature in question.

There is some security impact by this feature, yes. But IMHO the
impact is moderate at most as the client only executes code which it
requested explicitly from the server (but does that by default which
this bug-report is about) and exploiting would require one of these
conditions:

* Compromising a router (or routing in any other way) inbetween to
  modify the response by the monitoring server — which are usually all
  in the same perimeter.

* Compromising the monitoring server itself.

* Using DNS hostnames on the client (which is explicitly not
  recommended for reliability reasons) in combination with a DNS
  spoofing attack, spoofing the server's DNS record and redirecting
  logfetch to fetch code from the wrong server.

Hint for the security team: Xymon currently does not use TLS for
monitoring checks unless you build that yourself with stunnel.

Reliability might be one of the reasons here, but I suspect more a
lack of upstream developer resources to be the reason.

Anyway, I'll prepare an update of Xymon for Unstable changing the
default setting to "logfetch --noexec" and then we'll see if more
(like stable updates or so) is needed.

		Regards, Axel

Hi,

Christoph Berg wrote:

For me, "important" seems appropriate. If the security team disagrees,
I'm fine with their opinion on this issue as I might be a bit biased
here as I use and value the feature in question.

There is some security impact by this feature, yes. But IMHO the
impact is moderate at most as the client only executes code which it
requested explicitly from the server (but does that by default which
this bug-report is about) and exploiting would require one of these
conditions:

* Compromising a router (or routing in any other way) inbetween to
  modify the response by the monitoring server — which are usually all
  in the same perimeter.

* Compromising the monitoring server itself.

* Using DNS hostnames on the client (which is explicitly not
  recommended for reliability reasons) in combination with a DNS
  spoofing attack, spoofing the server's DNS record and redirecting
  logfetch to fetch code from the wrong server.

Hint for the security team: Xymon currently does not use TLS for
monitoring checks unless you build that yourself with stunnel.

Reliability might be one of the reasons here, but I suspect more a
lack of upstream developer resources to be the reason.

Anyway, I'll prepare an update of Xymon for Unstable changing the
default setting to "logfetch --noexec" and then we'll see if more
(like stable updates or so) is needed.

		Regards, Axel