Also of course the ultimate issue involved isn't simply the ability to pass commands to agents, but the integration of SSL and agent/server authentication to prevent man-in-the-middle attacks or simply just sniffing for server/agent traffic.

Though these are much larger issues beyond the scope of this ticket. But this is a good start to improving agent security for those of us who must use UserParameters (In some extreme cases, across the internet..stupid network) when built in functions are missing.

could you please show a specific way to get a shell escape with the current set of disallowed characters ?

the ONLY characters allowed to be passed should be: [a-zA-Z0-9]

that wouldn't work well for those zabbix users who would like to pass parameters in any language but english (and even for english that would make most users enable unsafe characters)

Getting a shell this way would be a multi-honed attack.

This is ONE example. Pen Testing is very environmentally specific.

Mainly I'd watch traffic from servers and proxies and look for user parameters that were checking files or paths, etc. At that point I'd simply feed it to a directory outside the scope of the intended original path / location, and begin probing for things like configuration files, /etc/passwd, etc.

I assume many people UserParameters that use curl, grep, cat, ls, mysql, etc. I certainly do. Some might even have something like chk.error,sh /zbx/chk_errors $1 |grep $2, etc etc.

My point was not to restrict userparameters to A-Z,a-z,0-9. It was to add in escaping some of the most common attack paths someone would take. And you have caught most of the characters, but I'm saying ones like, (And COMBINATIONS of characters. Not even touching how easy to take a windows host would be.):

=
%
..
./
../
//
: (Almost forgot the colon. That's a HUGE one. Can allow for path and port changes.)

Again, this is a minor problem compared to agent-server-proxy encryption and agent-server-proxy authentication. Which is what the core issue is. But this one is an easier fix.

You are correct on A-Z,a-z,0-9. You would need to match the equivalent of each countries alphabet and number system. I would also think that PERIOD (.), DASH , and UNDERSCORE (_) would also be safe as they are often in variable, table, and file names.

If I was tasked with securing this particular function and couldn't do encryption or authentication, I'd still likely implement this and some form of sanitation for both Linux and Windows. Windows being the more vulnerable, but less monitored target. But I bet if you scanned around there are quite a few public Windows Servers running zabbix agents on them.

There is one plus side to this, BASH already performs some sanitation on things like this, as long as the code (I haven't checked) on the AGENT, is telling BASH to surround any UserParameter ($1,$2...), in QUOTES. Which I'm assuming you are doing and that's why you disallowed the \ character. But again, I don't know.

Users who write parameters however and want to keep them safe, should hardcode the location or path, avoid spawning additional shells, using too many pipes, and split up UserParameters into safe components IN QUOTES as such:

EXTREME EXAMPLE

UserParameter=cat.file[*],cat $1 <-- this would be ridiculously unsafe.

Instead:

UserParameter=cat.file[$1].apache.access.log,cat /var/log/apache/"$1"/

This would prevent me, even WITH unsafe parameters, from taking certain actions. Such as saying, $1="access.log;cat /etc/passwd"

BASH would have evaluated this to be: cat '/var/log/apache2/access.log;cat /etc/passwd' (As an exact filename, NOT an input). 

So the result would be (Even as ROOT): cat: /var/log/apache2/access.log;cat /etc/passwd: No such file or directory.

Using this methodology, you should be able to pipe commands to make safe, logical UserParams.

Like: (dunno if $1,$2 is correct, but I think using * is unsafe too)

UserParameter=tail.apache.access.log[$1,$2],cat /var/log/apache/"$1"/ |tail -n"$2";
(the -n"$2" could potentially cause issues. it might be better to do "-n $2" or -n "$2"; or -n "$2" -- 

The main issue is that currently the unsafe combination of SPACE-(double)DASH, (double)DASH-SPACE is allowed to be used.)

UserParameter=tail.apache.access.log[$1,$2],cat /var/log/apache/"$1"/ |tail -n"$2" --

(ended with a command seperator, e.g. semicolon or BETTER YET, a command terminator --, e.g. DASH DASH, is just an extra thing I do to ensure I closeout the command evaluation and protect the statement.)

If you follow most of these steps and make smart decisions, you shouldn't have anything to worry about.

To Devs: If you want my specific advice. Remove the following characters AND combinations (In addition to the current list:
\ ' ” ` * ? [ ] { } ~ $ ! & ; ( ) < > | # @

[start]
=
, (comma)
%
..
./
../
// (slash-slash)
+
:
.\
..\

• [SPACE-DASH] (would allow additional flags and operations to commands, including redirection, this is probably one of the most dangerous linux ones ATM. If filtered, you could still easily use file-name.txt, etc.)
  [end]

Here are two decent articles on Shell input and injection attacks:

• https://developer.apple.com/library/mac/documentation/OpenSource/Conceptual/ShellScripting/ShellScriptSecurity/ShellScriptSecurity.html
• https://www.golemtechnologies.com/articles/shell-injection

The only other thing I might do, is when possible, have the agent interact as a doorman between any "server" requests for user parameters, scripts, etc and push the workable data into a tmp directory with no symbolic link or exec ability. Once the information was delivered, remove is from the protected tmp cache.

The other reason I opened this, is that users who are likely to enable unsafeuserparams, are likely doing it to get about a bad and very poor design decision.

But ultimately, nothing will ever be 100% secure. It's important that as users we protect zabbix and how we use it. In particular the biggest thing that would help the community to be safer would be server/agent auth and encryption. But I believe there's a ticket open for that and falls beyond the scope of this.

I am hopeful though that the brief writeup above will help someone write safer userparams in their environment.

FYI, windows would already be vulnerable with unsafeuserparameters turned on simply due to the following: = % and :, This could very easily be used to set a windows environment variable to launch a shell, program or application string.

From the linux side, the only other things I can think of would be:

• [SPACE-DASH] (would allow additional flags and operations to commands, including redirection, this is probably one of the most dangerous linux ones ATM. If filtered, you could still easily use file-name.txt, etc.)
  and
  // [Slash-Slash] (would allow certain commands args to be commented out and possibly circumvented.)

Making ONE place for the list request. CONSIDER THE ABOVE LISTS INVALID. The content, instructions, and exploits above still apply, but for the list, I will keep it updated here as I find more exploits.

TAG'S OFFICIAL LIST OF UNSAFE CHARACTERS FOR ZABBIX AGENTS ON LINUX AND WINDOWS

To Devs: If you want my specific advice. Remove the following characters AND combinations (In addition to the current list: 
\ ' ” ` * ? [ ] { } ~ $ ! & ; ( ) < > | # @

^ (one of the most dangerous on this list)
= (second most dangerous, shellshock is just one of many many examples. Windows is also vulnerable.)
, (comma, yup)
% (Extremely vulnerable windows character in scripting inputs and will alter environment vars and enter system paths.)
.. (redirection, performs action on partent directory, possible to chain together using operators.)
+ (alter commands and operations)
: (port, file, user, and location redirection ability)
// (slash-slash, Can redirect input, nullify protection steps, etc from multiple commands.)
./ (equivalent to running sh somecommand)
../ (also allows traversing directories, symlinks, and launching commands)
.\ (same [blocked already])
..\ (same [blocked already])
-  [dash space, huge redirection vulnerability, see below]
 - [space-dash] (would allow additional flags and operations to commands, including redirection, this is probably one of the most dangerous linux ones ATM. If filtered, you could still easily use file-name.txt, etc. Specifically, filter _- (_ is space) AND -_ (dash-space))
--  [double-dash space]
 -- [space double-dash]
 / [space-slash]
/ [slash-space]
_\ and \_ [space-backslash, backslash space, (backslash already blocked!]
 . [space period]
. [period space]

 # The following strings followed by a space of options flag, but if I had to choose, I'd block them. 
echo [echo, SPACE] - kinda a big deal..
exec  [yes, the letter combination, SPACE (mainly linux bash)]
command [command, SPACE (windows and linux)]
set -o (bash)
set -p (bash)
shopt (bash)
call (windows, call, space)
con (windows)

The ABOVE took me a long time to test. But I think this is MOST of the vulnerabilities for user parameters input exploits on both Windows and Linux agents.

------------------------------------------------------------------------------------------

 Paranoid List
--------------------
set [set, SPACE]
unset [unset, SPACE]
declare [declare, SPACE]
typeset [typeset, SPACE]
enable [enable, SPACE]
export [export, SPACE]

If you were PARANOID, which being in InfoSec, I am, I would also block the below:

exec
eval
alias
set
unset
sh
fg
bg
cd
break
continue
command
dirs
getopts
hash
history
jobs
kill
let
logout
popd
pushd
printf (could be used to circumvent filtering in the first place, would be hard though)
pwd
read
readonly
return (if used properly, could even make check report back expected info)
shift
shopt
suspend
test
trap
type
ulimit
umask
unalias
unset
wait
...

TBH, ANYTHING the agent tried to launch as a binary, that didn't evaluate in the initial working runs of the userparameter. And pretty much everything on this page: http://linux.about.com/library/cmd/blcmdl1_compgen.htm

if you are that concerned about security, you can avoid passing parameters in userparameters and just hardcoding what they do in the config file.

besides that, is there any scenario where the current set of disallowed characters actually allows a shell escape ?

I wrote up a large post on how to create secure(er) UserParameters simply by formatting them correctly and enforcing quotes, splitting them up, etc. If you like I can write up something for the manual on best practices for UserParameters.

But I think we're getting somewhat off track. If this was something that was discovered on something like a Github enterprise appliance, Apache, RPC Service, etc. It would immediately have a CVE posted.

But I'm telling you only one possible point of attack. And not even the largest.

However using just this issue. Windows agents are especially vulnerable, Yes, I can get a shell. There's multiple different ways to so this provided a user has setup bad UserParameters (Which is quite common as they do not have much documentation regarding this subject.). Zabbix however, in this scenario, I would most likely use for what we call "enumeration".

For which zabbix is a treasure trove of enumeration data on not just user accounts, authentication, services, but backend infrastructure topology. It's one angle of attack. Maybe I'd just spoof through an entire subnet of agents for active check lists, then try to compromise those agents.

A security vulnerability isn't typically one step and you have root. While this is a major one, it's not the biggest.

This same request probably applies to several built in agent keys and items and may perhaps even have larger exploits and less parameter filtering.

But the largest problem that needs addressing from a security standpoint, is that agents and servers do not authenticate one another (PSK, RSA Cert, etc) nor have any encryption mechanism (SSL, IPsec, etc). And please don't take offense to this. But I'm telling you flat out now, you are losing business because of this. Because I know many companies that cannot even TRY Zabbix because of the lack of this. This would be due to one of the many wonderful compliance and security standards (SOX, PCI, etc) we have.

I was suggesting a minor change to resolve this one issue quickly by looking over the list I provided and prioritize it by risk. Which if I had to pick the worst offenders, they would be the following:

^ (almost missed this guy. BIG BIG one. Sorry, Super tired >.<)
=
% (big one for windows, all versions)
.. (big one)
+
__- (space-dash, __ = space)
-- (dash-dash)
: (another big one)
//
__. (space-period)
.__  (period-space)

But if I have explain why this is a problem. I'm not sure how much help I can be beyond what I've provided.

If you like, I can try to demonstrate to you sometime this week or next how the characters I mentioned could be used to compromise a system. But again, not the biggest security issue, just a faster fix. I haven't gotten a lot of chances to examined the Agent's built-in keys and processing, web UI XSS/SQL injection possibilities, or possible Server/Proxy vulnerabilities.

Thank you for your time.

strong authentication and encryption is handled in other issues, including ZBXNEXT-17

Yes, I can get a shell.

could you please show a specific example of that ?

I'd be happy to. Give me a few days as it'll be in my free time.

Is this something you'd want specifics of posted publicly here?

if it's a successful result, emailing them to [email protected] would be appreciated

Tried it before bed. Got one. Emailing.

for the record, a supposed way to have shell escape with caret was provided, but i was unable to reproduce that. if anybody has a way to do that, please let me know

No example has been provided on how it is possible to exploit the current set of restricted characters. Therefore, closing as "Won't fix". If you manage to find an example, please reopen.