[Xymon] Remote Code execution

[Christoph Zechner]

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