Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

The importance of avoiding the shell

by jhourcle (Prior)
on Sep 25, 2014 at 11:34 UTC ( #1101954=perlmeditation: print w/replies, xml ) Need Help??

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

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

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.

Replies are listed 'Best First'.
Re: The importance of avoiding the shell
by Corion (Pope) 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.

      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

        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.

      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

      HTH! :)

      Cheers Rolf

      (addicted to the Perl Programming Language and ☆☆☆☆ :)

        The shell used by system is actually given by perl -V:sh.

        $ perl -V:sh sh='/bin/sh';

        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

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

        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

        ... had to use ...

        ktrace -di perl -e 'print system q[date 2>&1 </dev/null]'

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

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

      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?

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

        While $ENV{HTTP_ACCEPT} is tainted, system doesn't check if it's tainted.

        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.

        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

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.

      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

      (Of course, that doesn't matter for the bash vulnerability.)

      system BLOCK LIST won't call the shell on any system.

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!

Re: The importance of avoiding the shell
by Tux (Abbot) 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

      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.

        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] ~ >
        perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1101954]
Front-paged by Arunbear
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (3)
As of 2017-12-17 07:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What programming language do you hate the most?




















    Results (462 votes). Check out past polls.

    Notices?