The importance of avoiding the shell

For those who haven't heard, there was a Bash exploit announced yesterday. Although a patch did come out (4.3.25), there are reports that it does not fully fix the problem.

Using variations of the test string that was posted to slashdot, it looks as if perl makes your system invulnerable:

sh-3.2$ env x='() { :;}; echo vulnerable' sh -c "echo this is a test"
vulnerable
this is a test
sh-3.2$ env x='() { :;}; echo vulnerable & echo' perl -e 'system "echo
+ test"'
test
sh-3.2$ env x='() { :;}; echo vulnerable' perl -e 'print `echo test`'
test
[download]

... but unfortunately, perl only protects you when you either pass system a list. In other cases, if it sees a shell meta character in your string, you're still vulnerable:

sh-3.2$ env x='() { :;}; echo vulnerable' perl -e 'print `echo test;`'
vulnerable
test
sh-3.2$ env x='() { :;}; echo vulnerable' perl -e 'system "echo test;"
+'
vulnerable
test
sh-3.2$ env x='() { :;}; echo vulnerable' perl -e 'system qw(echo test
+;)'
test;
[download]

Your main attack vector is CGIs -- anyone can set their user-agent, or pass in a query string, and the webserver will set environmental variables automatically. Should your scripts shell out, they're exploitable.

So, the moral of the story: always use the list form of system, and avoid backticks if you can. If you have to do strange things w/ redirecting output, look at IPC::Open2 and IPC::Open3 which can also take list inputs.

Comment on The importance of avoiding the shell Select or Download Code

Replies are listed 'Best First'.
Re: The importance of avoiding the shell by Corion (Patriarch) on Sep 25, 2014 at 11:39 UTC
Note that "the shell" in this case is only problematic if your system default shell is `bash`. If your system default shell (`/bin/sh`) is something other than `bash` (for example, ash, dash, ksh, some vendor sh), in the case of this CVE you are likely safe. Still, it's a good idea to use Perl built-ins instead of shelling out.	[reply] [d/l] [select]
Re^2: The importance of avoiding the shell by jhourcle (Prior) on Sep 25, 2014 at 11:53 UTC
Notice how in my first test, I called `sh`? Some OSes (these examples were from a MacOS X box) use `bash` for `sh`. You should run the tests and check if you're vulnerable. Don't just think 'oh, it won't happen to me, I'm using `ksh`', as perl may still send to a vulnerable `sh`: `sh-3.2$ ksh $ set -o emacs $ env x='() { :;}; echo vulnerable' ksh -c "echo this is a test" this is a test $ env x='() { :;}; echo vulnerable' perl -e 'system "echo test;"' vulnerable test` [download]	[reply] [d/l] [select]
Re^3: The importance of avoiding the shell by mr_mischief (Monsignor) on Sep 26, 2014 at 13:51 UTC
This is why Corion, whom I assure you is not an idiot, mentioned the concept of the default shell. Please do read what you are responding to before repeating what was just said in a haughty way.	[reply]
Re^2: The importance of avoiding the shell by LanX (Saint) on Sep 27, 2014 at 10:25 UTC
here code sample that helped me identifying which shell is used by `system` et al. > perl -e 'print ` ls -l /proc/\$\$/exe `' lrwxrwxrwx 1 lanx lanx 0 2014-09-27 12:13 /proc/25970/exe -> /bin/dash [download] HTH! :) Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :)}	[reply] [d/l]
Re^3: The importance of avoiding the shell by ikegami (Patriarch) on Sep 29, 2014 at 06:36 UTC
The shell used by `system` is actually given by `perl -V:sh`. `$ perl -V:sh sh='/bin/sh';` [download] If you want to find out if that's `bash`, you can use `$ ls -l /bin/sh lrwxrwxrwx 1 root root 9 Apr 10 17:08 /bin/sh -> /bin/bash` [download] Like your code, that only works if and only if `/bin/sh` is a symlink. A more reliable check is `$ /bin/sh --version GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu) ...` [download]	[reply] [d/l] [select]
Re^4: The importance of avoiding the shell by LanX (Saint) on Sep 29, 2014 at 13:36 UTC
Re^5: The importance of avoiding the shell by ikegami (Patriarch) on Sep 29, 2014 at 13:43 UTC
Re^3: The importance of avoiding the shell by parv (Parson) on Sep 27, 2014 at 12:04 UTC
I was trying to create an example for FreeBSD 8-STABLE, and found that one cannot rely on (from system) ... ... If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system's command shell for parsing (this is "/bin/sh -c" on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to "execvp", which is more efficient. ... ... as I could not find any trace of a shell for `system q[date 2>&1]` & ktrace via ... `ktrace -di perl -e 'print system q[date 2>&1]' \ && kdump -d \| fgrep /bin/sh` [download] ... had to use ... `ktrace -di perl -e 'print system q[date 2>&1 </dev/null]'` [download] ... to invoke the shell (/bin/sh). Apparently `2>&1` does not qualify as shell metacharacters (here). (An actual example has yet to be produced.) date 2	[reply] [d/l] [select]
Re^4: The importance of avoiding the shell by Corion (Patriarch) on Sep 27, 2014 at 12:09 UTC
Re^5: The importance of avoiding the shell by BrowserUk (Patriarch) on Sep 27, 2014 at 12:50 UTC
Some notes below your chosen depth have not been shown here
Re^5: The importance of avoiding the shell by parv (Parson) on Sep 27, 2014 at 12:12 UTC
Re: The importance of avoiding the shell by petdance (Parson) on Sep 25, 2014 at 15:50 UTC
This also points to one of Perl 5's great features, taint mode and the -T flag. The core of the bash problem is that it takes outside data and treats it as code. Perl's -T flag prevents your program from making the same mistake without explicitly untainting the data. From perlsec: (With -T enabled), you may not use data derived from outside your program to affect something else outside your program--at least, not by accident. All command line arguments, environment variables, locale information (see perllocale), results of certain system calls ("readdir()", "readlink()", the variable of "shmread()", the messages returned by "msgrcv()", the password, gcos and shell fields returned by the "getpwxxx()" calls), and all file input are marked as "tainted". Tainted data may not be used directly or indirectly in any command that invokes a sub-shell, nor in any command that modifies files, directories, or processes, with the follow- ing exceptions: ... It pains me that so far there are no plans (so far as I know) to carry over taint mode into Perl 6. xoxo, Andy	[reply]
Re^2: The importance of avoiding the shell by Anonymous Monk on Sep 26, 2014 at 15:14 UTC
To be clear in my head, you're saying that if I run CGI scripts in taint mode that I don't need to worry about this bash bug from CGI?	[reply]
Re^3: The importance of avoiding the shell by ikegami (Patriarch) on Sep 29, 2014 at 06:54 UTC
I'm pretty sure that is what he's saying, but he's wrong if that's the case. `$ HTTP_ACCEPT='() { :;}; echo 0wn3d' \ perl -T -e'$ENV{PATH}=""; system(q(/bin/ls -- "$HOME"))' 0wn3d ... contents of home dir ...` [download] While `$ENV{HTTP_ACCEPT}` is tainted, `system` doesn't check if it's tainted.	[reply] [d/l] [select]
Re^3: The importance of avoiding the shell by Anonymous Monk on Sep 26, 2014 at 15:25 UTC
Taint mode, like most security measures, is "just" an additional security measure. Whether or not you "need to worry" depends a whole lot on the individual situation. Generally, turning on taint mode in CGI scripts is a good idea, but it is not a silver bullet.	[reply]
Re^3: The importance of avoiding the shell by petdance (Parson) on Oct 01, 2014 at 19:50 UTC
No, I am not making any claims about taint mode mitigating the bash bug. My point is that the bash bug is, at its core, about treating untrusted data as executable code. Perl's taint mode is designed to catch that problem in Perl code. Say you get an argument from the command line in your Perl program. That variable is now tainted, because it came from an untrusted source. Now, say you try to execute a command with `system` using that variable. Perl's taint mode will disallow it because the data fed to `system` is untrustworthy. xoxo, Andy	[reply]
Re: The importance of avoiding the shell by Anonymous Monk on Sep 25, 2014 at 12:48 UTC
So, the moral of the story: always use the list form of `system`, and avoid backticks if you can. If you have to do strange things w/ redirecting output, look at IPC::Open2 and IPC::Open3 which can also take list inputs. One trap for the unwary: `system(@cmd);` isn't completely reliable either, since if `@cmd` only has one element, it may still invoke the shell, the solution is to write `system { $cmd[0] } @cmd;` (documented in exec). AFAIK such a syntax is not available for IPC::Open3 and piped opens, so there it is important to make sure that `@cmd` always has at least two elements.	[reply] [d/l] [select]
Re^2: The importance of avoiding the shell by ikegami (Patriarch) on Sep 29, 2014 at 06:30 UTC
And in Windows, even `system LIST` with multiple values can invoke the shell. For example, the following should fail given that `dir` is a shell builtin. `>perl -e"system 'dir', '/b'" foo bar` [download] (Of course, that doesn't matter for the `bash` vulnerability.) `system BLOCK LIST` won't call the shell on any system.	[reply] [d/l] [select]
Re: The importance of avoiding the shell by Anonymous Monk on Sep 25, 2014 at 11:50 UTC
A couple modules that can avoid the shell: IPC::System::Simple's `systemx` and `capturex`; IPC::Run3 (when called with an arrayref). There are lots of other modules out there that do similar things, but it's important to read the docs: Many of them don't specify whether they can avoid the shell!	[reply] [d/l] [select]
Re: The importance of avoiding the shell by Tux (Canon) on Sep 26, 2014 at 06:09 UTC
`csh` had a similar bug in the 80's when: env TERM='`rm -rf *`' csh did what you think it does. Enjoy, Have FUN! H.Merijn	[reply] [d/l] [select]
Re^2: The importance of avoiding the shell by ikegami (Patriarch) on Sep 29, 2014 at 06:44 UTC
I think `ssh` can specify the value for `TERM`, making `ssh` an attack vector if you can get it to execute `sh`/`bash` (directly or indirectly). But the new vulnerability is worse because it can be any env var, and CGI will gladly populate env vars with values of the attacker's choice for him. Any CGI script that executes `bash` is a dead easy attack vector. Attackers have been scanning for a CPanel script that shells out.	[reply] [d/l] [select]
Re^3: The importance of avoiding the shell by shmem (Chancellor) on Sep 30, 2014 at 08:18 UTC
I think ssh can specify the value for TERM, making ssh an attack vector if you can get it to execute sh/bash. Right; simple test: `qwurx [shmem] ~ > env TERM='() { :;}; echo vulnerable' ssh localhost ... Last login: Tue Sep 30 10:14:54 2014 from localhost vulnerable qwurx [shmem] ~ >` [download] perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'	[reply] [d/l]

Back to Meditations