[Xymon] Remote Code execution

On 14/10/2021 15:30, Jeremy Laidman wrote:

Christoph

On Thu, 14 Oct 2021 at 18:01, Christoph Zechner <zechner at vrvis.at <mailto:zechner at vrvis.at>> wrote:

Hi,

On 13/10/2021 04:04, Jeremy Laidman wrote:
 > I think the "remote code execution" mentioned in the two
references are
 > two very different things: remotely configuring commands to run
on the
 > client, in the context of collecting data, versus remotely sending
 > arbitrary pre-compiled code over the Internet to execute on the
Xymon
 > server,?by leveraging the ability to overflow a memory buffer.
Calling
 > them both "remote code execution" is confabulating two different
things.

That's on me, I was just trying to summarise different approaches in a
non-precise way, sorry.

Sorry, I didn't mean this as a criticism. I think the terminology you used in the two cases is quite reasonable, in their contexts. It's just that in the one context, there's the potential for people to confabulate the two meanings. And to be honest, the ability to run arbitrary commands on a host server, even by design, isn't above being given the once-over?with a critical eye. As sysadmins, it's our responsibility to keep our systems going, which means defending against malicious attackers as well as our own accidents!

I'm glad you raised the discussion. The principle of avoiding remote code execution is valid regardless of whether the execution is by design or by accident. After all,?an accident can only occur when there aren't sufficient safeguards to protect against it, and?we should consider accidents inevitable. As a result of your questions, my team is now taking a look at our Xymon deployments to see where we can reduce risks, by seeing what changes we can make to the way we collect some of our data for Xymon's analytics.

<snip>

 > This feature is on by default. There appear to be two ways to it
off: 1)
 > don't run the clients in central mode, and 2) add the "--noexec"
 > parameter to logfetch (in LOGFETCHOPTIONS in the file
xymonclient.cfg).

ad 1) clients are per default not running in central mode or did I
misunderstand you here?

I thought they did. But I had to check this for myself.

To run in local mode, the xymon client script xymonclient.sh needs to be run with the "--local" switch,?specified within the clientlaunch.cfg file. The default entry for [client] that runs the client script, doesn't have the "--local" switch. So by default, the client runs in central mode. From the original clientlaunch.cfg:

[client] ? ? ? ? ENVFILE $XYMONCLIENTHOME/etc/xymonclient.cfg ? ? ? ? CMD $XYMONCLIENTHOME/bin/xymonclient.sh ? ? ? ? LOGFILE $XYMONCLIENTLOGS/xymonclient.log ? ? ? ? INTERVAL 5m

I checked versions between 4.3.4 (from 2012, long before the vulnerabilities were reported) to 4.3.28, and none has "--local" in clientlaunch.cfg.

I tried to run a client in local mode today (Debian 10), but it was not possible, because the "xymond_client" binary is missing from the Debian package (bug report [1]).

I didn't check the Terabithia?packages, but I have no reason to think they would default to local mode.

So yes, Xymon clients run in central mode, by default. I suspect it wasn't always the case, and I'm quite sure that Xymon/Hobbit's precursor, BigBrother, didn't have a central mode.

Thank you very much for your time and effort, I highly appreciate
it. It
seems to me that "--noexec" would be a good sane default for
logfetch in
any way.

I concur.

And if we really wanted to be extra careful (paranoid?), we might adjust the xymonclient.sh script to run logfetch like so:

LD_PRELOAD=/usr/libexec/sudo/sudo_noexec.so /usr/libexec/xymon-client/logfetch $LOGFETCHOPTS $LOGFETCHCFG $LOGFETCHSTATUS >>$MSGTMPFILE

(assuming the "sudo" package is installed, and has noexec enabled; there's also a useful standalone utility called "noexec" at http://noexec.sourceforge.net/ <http://noexec.sourceforge.net/>)

Given that the logfetch command accepts input from a remote system, we might prefer to have an assurance that the input cannot be used to trick logfetch into running commands. I'm not necessarily promoting this as a "best practice", and it's likely to have problems (dependency on sudo for one), but as a mental exercise in looking for ways to almost eliminate a class of attack, there's at least some value in that.

Nice suggestion, I will look into that as well, thank you!

Cheers Christoph

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903614

Cheers Jeremy