7 ms·

Yep. We're currently basically waiting to see which completes first: a) a patch for bash which actually works gets released and then trickles into the various w

by patio11 12y ago

Yep. We're currently basically waiting to see which completes first: a) a patch for bash which actually works gets released and then trickles into the various ways to get it on every machine in the world or b) someone writes ~10 lines of payload code (download rootkit, execute, connect to IRC channel, join botnet, etc) and then just hits everything in IP4 space with a for loop. Optionally, the for loop gets distributed to new nodes joining the bot net. If you cannot say "I run no Linux/Unix/MacOS/compatible/etc machine which connects other machines" you should be at battle stations right now. We're all racing against a for loop and the for loop will probably have a head start.

cperciva 12y ago
I run no Linux/Unix/MacOS/compatible/etc machine which connects other machines How about "I don't run bash"? There are other perfectly good shells, you know...
- patio11 12y ago
  You and Thomas can ignore everything I say about security. J. Random Rails Developer, on the other hand, probably gets useful signal if I start panicking. (Am I panicking? YES.)
- inportb 12y ago
  I suspect that many folks who "don't run bash" actually do use bash quite a bit, e.g. in initscripts and various software packages.
  - stephenr 12y ago
    Any decent shell script is written to use "sh" not bash, and on debian/etc sh is provided by dash not bash. So while a lot of people are affected, your reasoning points to other issues that are very solveable
    - erikb 12y ago
      This more of a "should be", right? Maybe most shell scripts should use "sh" but I see "bash" way more often.
      - stephenr 12y ago
        I guess it comes down to how you interpret things. I specifically said any decent shell script. My logic is that if it is not using "sh", but instead relying on bash (or any other specific shell really), it's not a decent shell script. If I were to amend the sentence to make the meaning clearer, I would still not use "should be", I would use "must be".
        yen223 12y ago
        If you can confidently assert that every shell script your system runs is "decent", then you'll have no problem. The thing is, very few of us can confidently make that assertion.
        stephenr 12y ago
        That all depends where your shell scripts come from. In my experience most of the shell scripts provided by packages for debian, do use /bin/sh. A quick check of .sh files on a couple of squeeze/wheezy installs showed that the vast majority of shell scripts using Bash come from node modules, which quite frankly is not surprising.
        eropple 12y ago
        You're overreaching. I write scripts against bash, not sh, because it's a better scripting language for what I need. It's more readable and its constructs are easier (for me) to follow. I don't care about POSIX-compatibility when bash can be installed literally anywhere. It's a dependency for the devops stuff that I run and maintain, much like Ruby is a dependency and all the gems in my Gemfile. It's a considered decision, not a sign of "indecency".
        12y ago
- quesera 12y ago
  Or "I don't run UNIXes that default to bash, or hide it under /bin/sh, etc." Unfortunately, bash shows up in surprising places, including default Solaris installs nowadays. On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far. I'll put more effort into establishing its acceptability as a solution tomorrow. BSDs won't have bash unless someone has gone out of their way to install it, which can be undone straightforwardly. But it could be a long night for our Linux brethren and sistren. Good luck, and remember to stay hydrated. :) EDIT: obviously, don't chmod 0000 your login shell! Fix that first. Make sure whatever you switch to isn't a symbolic or hard link to bash.
  - bodyfour 12y ago
    > On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far. In the case of OSX, /bin/sh is also bash. For some reason they are separate binaries (at least on my laptop running 10.9.5) but they're both really bash inside: $ ls -ld /bin/sh /bin/bash -r-xr-xr-x 1 root wheel 1228240 Sep 21 21:37 /bin/bash -r-xr-xr-x 1 root wheel 1228304 Sep 21 21:37 /bin/sh $ /bin/sh --version GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13) Copyright (C) 2007 Free Software Foundation, Inc. $ /bin/bash --version GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13) Copyright (C) 2007 Free Software Foundation, Inc. So even if you chmod bash to 0 you could still be exposed by anything that uses /bin/sh -- system(), popen(), most shell scripts, etc (ETA: as I've mentioned elsewhere in this thread most people running OSX probably aren't badly impacted since they're not running CGI-based web software or other high-risk activity. I'm just pointing out that your bash-ectomy of OSX isn't as complete as you think it was)
    - quesera 12y ago
      Yikes, yes. Thanks for pointing that out! There might be more of an impact than expected on OSX, too -- no telling what Apple does with their system services. We've seen mention of dhcp-client and CUPS. The latter, at least, could also be an issue on OSX.
- wiredfool 12y ago
  Someone is going to be going through busybox soon, and then there (potentially) will be a whole bunch more exploitable boxes that don't have a generally have a regular update cycle.
  - smellf 12y ago
    You're right, of course. Exploitable weaknesses in busybox are going to be killer - I think shellshock will turn out to be the start of something really big. But, to clarify for others, the existing shellshock PoC doesn't work on the busybox environment I tested (v1.20.2).
- count 12y ago
  As you well know, as long as your system doesn't use bash for anything, even implicitly :) Many folks are thinking that just because they switched their user's login shell to 'ksh' to be one of the cool ruby kids, that they're safe.
donw 12y ago
Ubuntu 10.04LTS - 14.04LTS appears to be patched: http://www.ubuntu.com/usn/usn-2362-1/ http://www.ubuntu.com/usn/usn-2362-1/ Logging into my server, things look good -- this is why you turn on automatic security updates. :)
- timv 12y ago
  That update appears to only patch CVE-2014-6271 and not CVE-2014-7169 ( See: https://news.ycombinator.com/item?id=8365158 https://news.ycombinator.com/item?id=8365158 ) Although 7169 appears to be more difficult to exploit than 6271, you're not out of the woods until a patch gets distributed (+applied!) that covers both CVEs.
  - donw 12y ago
    Good catch, thanks!
igammarays 12y ago
What about using the exploit to remotely patch machines?
- smellf 12y ago
  That's a very cool idea.
bodyfour 12y ago
It won't be as simple as scanning all IP4 space because for most vulnerable hosts you still will need to know a URL of a cgi program that can cause bash to be executed (either because they're written in shell or, more likely, that there is some path found that can cause popen()/system()/etc to be called) If you read Robert Graham's blog post about his scan for this (posted to HN earlier today) he mentioned that the hosts he found by just looking at the root URL are probably a tiny subset of what's really out there. What we'll probably see is lots of blackhats looking at common CGI-based packages, finding a way to provoke an exploit using that, and then doing an IPv4 scan exploiting just that one. There will also be a long-tail of people mounting more directed attacks against URLs they suspect are CGI based.
- patio11 12y ago
  I think you underestimate attack vectors. d6c477a79ea7a633c2bb0e358e32399c1b18eb7d <-- Will ruin 1+ HNers' day sooner rather than later if they don't patch. Successful exploit doesn't require the exploit writer even knowing that vector existed to say nothing of successfully guessing a URL.
  - janlin1999 12y ago
    What does "d6c477a79ea7a633c2bb0e358e32399c1b18eb7d" mean? Also, I'm learning about this and am primarily concerned about the possibility of remote exploits -- if a web server returns 404 for an invalid URL, how does the attack vector work if the exploit writer does not successfully guess a URL? Thanks.
    - fr4 12y ago
      It is probably a SHA hash of a one-liner proof of concept that he has that he doesn't want to reveal as yet, but wants to prove that he was talking about at a later date.
    - djb_hackernews 12y ago
      Take for example your favorite web app server, rails, django, etc. whatever it may be. (Not saying these are necessarily exploitable, but potentially) Now imagine that for EVERY request, no matter if it is a valid path or not, one of the things it does is load all of the headers for the request into bash variables...

by patio11 12y ago

cperciva 12y ago

I run no Linux/Unix/MacOS/compatible/etc machine which connects other machines How about "I don't run bash"? There are other perfectly good shells, you know...

patio11 12y ago
You and Thomas can ignore everything I say about security. J. Random Rails Developer, on the other hand, probably gets useful signal if I start panicking. (Am I panicking? YES.)
inportb 12y ago
I suspect that many folks who "don't run bash" actually do use bash quite a bit, e.g. in initscripts and various software packages.
- stephenr 12y ago
  Any decent shell script is written to use "sh" not bash, and on debian/etc sh is provided by dash not bash. So while a lot of people are affected, your reasoning points to other issues that are very solveable
  - erikb 12y ago
    This more of a "should be", right? Maybe most shell scripts should use "sh" but I see "bash" way more often.
    - stephenr 12y ago
      I guess it comes down to how you interpret things. I specifically said any decent shell script. My logic is that if it is not using "sh", but instead relying on bash (or any other specific shell really), it's not a decent shell script. If I were to amend the sentence to make the meaning clearer, I would still not use "should be", I would use "must be".
      - yen223 12y ago
        If you can confidently assert that every shell script your system runs is "decent", then you'll have no problem. The thing is, very few of us can confidently make that assertion.
        stephenr 12y ago
        That all depends where your shell scripts come from. In my experience most of the shell scripts provided by packages for debian, do use /bin/sh. A quick check of .sh files on a couple of squeeze/wheezy installs showed that the vast majority of shell scripts using Bash come from node modules, which quite frankly is not surprising.
      - eropple 12y ago
        You're overreaching. I write scripts against bash, not sh, because it's a better scripting language for what I need. It's more readable and its constructs are easier (for me) to follow. I don't care about POSIX-compatibility when bash can be installed literally anywhere. It's a dependency for the devops stuff that I run and maintain, much like Ruby is a dependency and all the gems in my Gemfile. It's a considered decision, not a sign of "indecency".
        12y ago
quesera 12y ago
Or "I don't run UNIXes that default to bash, or hide it under /bin/sh, etc." Unfortunately, bash shows up in surprising places, including default Solaris installs nowadays. On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far. I'll put more effort into establishing its acceptability as a solution tomorrow. BSDs won't have bash unless someone has gone out of their way to install it, which can be undone straightforwardly. But it could be a long night for our Linux brethren and sistren. Good luck, and remember to stay hydrated. :) EDIT: obviously, don't chmod 0000 your login shell! Fix that first. Make sure whatever you switch to isn't a symbolic or hard link to bash.
- bodyfour 12y ago
  > On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far. In the case of OSX, /bin/sh is also bash. For some reason they are separate binaries (at least on my laptop running 10.9.5) but they're both really bash inside: $ ls -ld /bin/sh /bin/bash -r-xr-xr-x 1 root wheel 1228240 Sep 21 21:37 /bin/bash -r-xr-xr-x 1 root wheel 1228304 Sep 21 21:37 /bin/sh $ /bin/sh --version GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13) Copyright (C) 2007 Free Software Foundation, Inc. $ /bin/bash --version GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13) Copyright (C) 2007 Free Software Foundation, Inc. So even if you chmod bash to 0 you could still be exposed by anything that uses /bin/sh -- system(), popen(), most shell scripts, etc (ETA: as I've mentioned elsewhere in this thread most people running OSX probably aren't badly impacted since they're not running CGI-based web software or other high-risk activity. I'm just pointing out that your bash-ectomy of OSX isn't as complete as you think it was)
  - quesera 12y ago
    Yikes, yes. Thanks for pointing that out! There might be more of an impact than expected on OSX, too -- no telling what Apple does with their system services. We've seen mention of dhcp-client and CUPS. The latter, at least, could also be an issue on OSX.
wiredfool 12y ago
Someone is going to be going through busybox soon, and then there (potentially) will be a whole bunch more exploitable boxes that don't have a generally have a regular update cycle.
- smellf 12y ago
  You're right, of course. Exploitable weaknesses in busybox are going to be killer - I think shellshock will turn out to be the start of something really big. But, to clarify for others, the existing shellshock PoC doesn't work on the busybox environment I tested (v1.20.2).
count 12y ago
As you well know, as long as your system doesn't use bash for anything, even implicitly :) Many folks are thinking that just because they switched their user's login shell to 'ksh' to be one of the cool ruby kids, that they're safe.

donw 12y ago

Ubuntu 10.04LTS - 14.04LTS appears to be patched: http://www.ubuntu.com/usn/usn-2362-1/ http://www.ubuntu.com/usn/usn-2362-1/ Logging into my server, things look good -- this is why you turn on automatic security updates. :)

timv 12y ago
That update appears to only patch CVE-2014-6271 and not CVE-2014-7169 ( See: https://news.ycombinator.com/item?id=8365158 https://news.ycombinator.com/item?id=8365158 ) Although 7169 appears to be more difficult to exploit than 6271, you're not out of the woods until a patch gets distributed (+applied!) that covers both CVEs.
- donw 12y ago
  Good catch, thanks!

igammarays 12y ago

What about using the exploit to remotely patch machines?

smellf 12y ago
That's a very cool idea.

bodyfour 12y ago

It won't be as simple as scanning all IP4 space because for most vulnerable hosts you still will need to know a URL of a cgi program that can cause bash to be executed (either because they're written in shell or, more likely, that there is some path found that can cause popen()/system()/etc to be called) If you read Robert Graham's blog post about his scan for this (posted to HN earlier today) he mentioned that the hosts he found by just looking at the root URL are probably a tiny subset of what's really out there. What we'll probably see is lots of blackhats looking at common CGI-based packages, finding a way to provoke an exploit using that, and then doing an IPv4 scan exploiting just that one. There will also be a long-tail of people mounting more directed attacks against URLs they suspect are CGI based.

patio11 12y ago
I think you underestimate attack vectors. d6c477a79ea7a633c2bb0e358e32399c1b18eb7d <-- Will ruin 1+ HNers' day sooner rather than later if they don't patch. Successful exploit doesn't require the exploit writer even knowing that vector existed to say nothing of successfully guessing a URL.
- janlin1999 12y ago
  What does "d6c477a79ea7a633c2bb0e358e32399c1b18eb7d" mean? Also, I'm learning about this and am primarily concerned about the possibility of remote exploits -- if a web server returns 404 for an invalid URL, how does the attack vector work if the exploit writer does not successfully guess a URL? Thanks.
  - fr4 12y ago
    It is probably a SHA hash of a one-liner proof of concept that he has that he doesn't want to reveal as yet, but wants to prove that he was talking about at a later date.
  - djb_hackernews 12y ago
    Take for example your favorite web app server, rails, django, etc. whatever it may be. (Not saying these are necessarily exploitable, but potentially) Now imagine that for EVERY request, no matter if it is a valid path or not, one of the things it does is load all of the headers for the request into bash variables...