[Xymon] Remote Code execution

[Christoph Zechner]

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.

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

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

ad 2) thanks, I did not know about this option and have rolled it out on 
my clients now.

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

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.

Cheers
Christoph


> 
> Cheers
> Jeremy
> 
> On Wed, 13 Oct 2021 at 04:10, John Thurston <john.thurston at alaska.gov 
> <mailto: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 <mailto:John.Thurston at alaska.gov>
>     Department of Administration
>     State of Alaska
>     _______________________________________________
>     Xymon mailing list
>     Xymon at xymon.com <mailto:Xymon at xymon.com>
>     http://lists.xymon.com/mailman/listinfo/xymon
>     <http://lists.xymon.com/mailman/listinfo/xymon>
> 
> 
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>