[Xymon] Remote Code execution

[Jeremy Laidman]

Christoph

On Thu, 14 Oct 2021 at 18:01, Christoph Zechner <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 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/)

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.

Cheers
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20211015/bb14b05b/attachment.htm>