[Xymon] Remote Code execution

[Jeremy Laidman]

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.

The discussion about running arbitrary "code" on a client machine -
commands that are determined by a configuration file on the server - is a
feature of Xymon. It's not a buffer overflow bug. While this makes some
people (myself included) feel a bit uncomfortable, the risk of exploitation
is considerably less than that of a classic "remote code execution
vulnerability" such as described in the Packetstorm post.

Here's a quick backgrounder, for those not familiar with this feature: The
"arbitrary commands" are the use of backticks in pseudo-filenames in log:,
file: or dir: entries in client-local.cfg. If I add an entry for a host
along the lines of "log:/bin/ls -t /var/log/my-logfile-* | head -1" means
that I can always look at the latest logfile, even though the filenames
have a datestamp suffix that changes. However, if I add an entry like
"log:`rm -rf />/dev/null 2>&1`" then I can attempt to do something nasty
(as the xymon user on the client machine). If there were a compiler on the
client machine, I could conceivably send actual code, have it compiled, and
then run it; this might give me more flexibility in my abuse of the client
machine (eg compile and run a remotely-accessible backdoor).

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).

(As an aside, I wonder if the same facility is available for Windows
clients. Can anyone comment on this?)

For me to abuse this facility, I'd need write access to a configuration
file on the Xymon server. I can't remotely exploit this from an arbitrary
location, only from on the Xymon server. I can't somehow get the client to
connect to my rogue server, and give it a fake payload to execute with
backticks around my evil commands. The payload has to be present on the
Xymon server as configured on the Xymon client.

To exploit this, I have to launch some sort of attack *from* the Xymon
server, using an account with write access to the client-local.cfg file.
This file wouldn't normally be writable by anyone except the xymon user and
root. If Xymon was installed from a Terabithia package, this file is owned
by root, so not even the xymon user could exploit this. There's no good
reason for the xymon user to be able to write to this file, and it seems
simple enough to change ownership of the file and ameliorate this
risk. Certainly, if I could somehow get the xymond process (which accepts
connections from anywhere) to write to an arbitrary file that is owned by
the xymon user account, then this could be an attack vector on all machines
that the Xymon server monitors via Xymon clients. But this does depend on
an exploit on the Xymon server.

The Packetstorm post contains several vulnerabilities (which are all closed
from Xymon version 4.3.25) that included a "remote code execution"
vulnerability, CVE-2016-2054, that uses a buffer overflow. This is a
vulnerability in the xymond process, which runs as the xymon user. This
vulnerability allows an attacker to run code as the xymon user only. The
attack can be launched from anywhere that has connectivity to the Xymon
server. Quite a bad exploit, but it's not a remote root exploit.

I'm certainly less concerned about the ability to use backticks in a file
on the Xymon server to run commands on Xymon clients as the xymon user,
than I am about the ability for a remote attacker to run code on the Xymon
server as the xymon user.

Of course, the backtick facility allows the buffer overflow exploit against
the Xymon server to be leveraged to send commands to my whole fleet of
Xymon clients.

So, in answer to Christoph's question: yes, remote commands can still be
executed, under limited situations and context, but remote code execution
is not possible since v4.3.25. My advice to anyone would be to implement
Henrik's recommended mitigations in the Packetstorm post, and also add the
"--noexec" parameter to logfetch. Those steps can then be reversed/adjusted
where necessary, and after careful consideration of the risks and benefits,
and alternatives.

Cheers
Jeremy

On Wed, 13 Oct 2021 at 04:10, John Thurston <john.thurston at alaska.gov>
wrote:

>
> On 10/12/2021 6:11 AM, Christoph Zechner wrote:
> > after reading an old thread about remote code execution on here [1], I
> > wondered if something like this is still possible nowadays with xymon?
>
> Last time I looked, the Xymon client software permitted execution of
> arbitrary code supplied from the Xymon server. This default behavior
> could be changed by flipping a switch in the client's configuration (uh
> huh. Yeah, sure).
>
> I have never considered this to be a "feature".
>
> --
> Do things because you should, not just because you can.
>
> John Thurston    907-465-8591
> John.Thurston at alaska.gov
> Department of Administration
> State of Alaska
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20211013/0b5d3834/attachment.htm>