26 ms·

Bash 'shellshock' bug is wormable

• ivrrimum 12y ago
  As i understand, this is ussless, cuz nobody stores any scripts in /cgi-bin folders, or maybe i just didint understand it right, can someone explain how would you exploit it ?
• 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".
    • 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...
• TheSoftwareGuy 12y ago
  I didn't realize iOS and OS X DHCP could be vulnerable. This just went from "Man a lot of other people should be worried about this" to "shit, shit, shit, shit, shit", since I don't run a web server.
  • sjy 12y ago
    Have you got a source for OS X DHCP being vulnerable? OS X has a copy of bash at /bin/sh so it's pretty vulnerable if you can find a way to remotely set environment variables and call system().
    • TheSoftwareGuy 12y ago
      It was in the article linked. at the bottom it mentioned them
      • stygiansonic 12y ago
        Unless the article was changed, the author only questioned whether they were vulnerable, and did not assert that they were: "One key question is whether Mac OS X and iPhone DHCP service is vulnerable..." One early analysis [0] seems to indicate that OS X not vulnerable to this sort of DHCP client exploit. 0. http://complexitydaemon.wordpress.com/2014/09/26/bash-os-x-dhcp-and-you/ http://complexitydaemon.wordpress.com/2014/09/26/bash-os-x-d...
  • 95014_refugee 12y ago
    iOS systems (unless jailbroken) do not have a shell of any sort; bash or otherwise.
• btown 12y ago
  From one of the comments: > The question isn't whether a CGI is written in bash, but if it calls out to bash no matter how indirectly. Lots of things use the system() libc function, so if /bin/sh is bash it's game over. Is this true? Which systems are vulnerable to this by default?
  • hackcasual 12y ago
    I think you need that + the ability to add anything to an environment variable. Not sure how easy that is. edit: reading this looks like its exploiting CGI scripts, presumeably through the host header
    • fabulist 12y ago
      Setting an environment variable is often pretty easy, but the Host: header is the wrong way to go. The webserver will usually ignore a bad Host: header. User-agent: is much more availing.
      • bodyfour 12y ago
        CGI will typically pass most any header along as a HTTP_headername environment variable (HTTP_HOST is just one example) I'd expect most malicious exploiters to use a non-standard header, since User-Agent's value is often logged.
• grimtrigger 12y ago
  Could anyone provide a simplified explanation for what this is and what it means?
  • amalcon 12y ago
    This is a completely bonkers, Slammer-level hair-on-fire vulnerability. Remember Heartbleed? This is much worse. If you have a computer with an OS other than Windows or Android, your safest bet is to unplug it from the Internet until the bash developers figure this all out.
    • grimtrigger 12y ago
      And my servers? Is there anything I can do without taking them offline?
      • amalcon 12y ago
        Well, you could remove bash entirely (say, by replacing it with a link to dash). Doing this will likely break things, however, up to and including rendering the machine unbootable depending on which distribution it is and how the init scripts are written. You could replace bash with e.g. a perl script that strips parenthesis from your environment variables, and then invokes a differently named copy of bash. That might not break anything. Then again, it might.
        • barsonme 12y ago
          > Well, you could remove bash entirely (say, by replacing it with a link to dash) Just did this, except I accidentally removed both bash and dash... it wasn't fun having to compile bash from source with zsh. For whatever reason it absolutely did not want to work. But all back to normal now.
      • wglb 12y ago
        I patched mine with a apt-get update sequence. It fixed the bug (first fix, not yet the second), and I didn't have to take the server down. Everything stayed up.
• tdicola 12y ago
  As someone who just runs an Ubuntu 14.04 desktop machine without any web server should I be concerned? I don't really see how anyone could remotely execute bash on my system.
  • LeoPanthera 12y ago
    It's hard, but not impossible. Apparently your DHCP client passes responses from the DHCP server to bash. Let's say, for the sake of argument, that your ISP's DHCP server is compromised. A worm could then spread to your system from it. This is entirely hypothetical, but not impossible.
    • tdicola 12y ago
      Ouch, what a mess. Thanks for the warning.
    • justincormack 12y ago
      to bash? or to /bin/sh? Or the user shell? On Ubuntu you are fine unless it explicitly calls bash or (unlikely) uses the user shell.
    • pbhjpbhj 12y ago
      What responses does it pass, does it not sanitise them? Can anyone link to details of what DHCP does that's relevant here? Thanks.
      • monort 12y ago
        Looking at http://code.metager.de/source/xref/isc-dhcp-debian/client/dhclient.c http://code.metager.de/source/xref/isc-dhcp-debian/client/dh... It seems that server_name from DHCP response is passed to environment variable without sanitising. 3437 if (check_option_values(NULL, DHO_HOST_NAME, 3438 lease->server_name, 3439 strlen(lease->server_name)) == 0 ) { 3440 client_envadd (client, prefix, "server_name", 3441 "%s", lease->server_name); And script that is run after that (dhclient-script) is written in bash at least on Debian.
• eah13 12y ago
  Honest question: does this mean this vulnerability has been in bash for essentially its entire history and someone only discovered it now? Seems quite likely that someone would have discovered it sooner, especially since it's so simple to exploit.
  • patio11 12y ago
    Ease of exploitation and ease of discovery have basically nothing to do with each other. Relatedly, "many eyes makes all bugs shallow" is, and always has been, totally horsepuckey. (And despite it being horsepuckey, and horsepuckey which is trivially exploitable in that if you believe it you'll produce software which can get owned by people who are better at e.g. counting to four than you are, people still believe it to this day.)
    • gioele 12y ago
      > Relatedly, "many eyes makes all bugs shallow" is, and always has been, totally horsepuckey. Consider that the contraction of the more complete saying "Many eyes make bugs shallower than they would be if there were only few eyes".
      • Tloewald 12y ago
        But then there's the "Many eyes lead to a sense of complacency" issue -- like "No-one ever got fired for buying IBM|Microsoft|Blackberry"
      • wglb 12y ago
        Given that this is a 20 year old bug, that suggests that the number of eyes on this code were either zero or uninterested. Also, the BEAST bug was identified 20 years ago and nothing was done until Thai and Juliano caused a mild panic.
  • robertgraham 12y ago
    This has been there for nearly the entire history of Bash, like 2 decades.
• walterbell 12y ago
  What are the best OS-specific alternatives to bash, which could be linked to /bin/sh until bash fixes are stable?
  • cperciva 12y ago
    On FreeBSD, /bin/sh is a good alternative to bash.
  • stephenr 12y ago
    On Debian /bin/sh is already provided by Dash
  • clarry 12y ago
    On OpenBSD, /bin/sh is a good alternative to bash.
• dustingetz 12y ago
  I have a macbookpro which is my developer workstation. It is in a default configuration, it is on 12 hours a day, always behind a NAT. What do I need to do to protect myself?
  • ProCynic 12y ago
    update bash (https://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271 https://apple.stackexchange.com/questions/146849/how-do-i-re...) or switch to a different system default shell until bash is updated.
    • maldeh 12y ago
      Keep in mind that /bin/sh is bash on OS X. So if you have any scripts with the #!/bin/sh preamble you'll have to replace the default sh too.
  • deleted 12y ago
    [deleted]
  • bodyfour 12y ago
    Just apply the security updates as they arrive from Apple. The highest-risk activities like running a webserver hosting CGI scripts isn't likely to apply to you. I can't say for certain nobody will find a clever client-side attack for OS/X but right now you don't need to join in the panic that many sysadmins are (rightly) feeling today.
  • ams6110 12y ago
    Are you running any remotely-accessible services? If not, I'd just wait for the next OSX update from Apple.
• fabulist 12y ago
  Test your local machine: export evil='() { :;}; echo vulnerable'; bash -c echo; Vulnerable computers will print 'vulnerable'. Test a CGI: curl -i -X HEAD "http://website" http://website" -A '() { :;}; echo "Warning: Server Vulnerable"' Vulnerable scripts will emit a "Warning" header. If you get a 405 error, try it with a GET request. I don't know the PoC fo new version which wiggles around the patch. I've tried the PoC on ksh, csh, and dash; if they're effected, its more nuanced. Its advisable to rename bash, and replace it with a symlink to dash; it shouldn't break any scripts, and even if it does its better than getting owned. mv /bin/bash /bin/_bash chmod ugo-x /bin/_bash ln -s /bin/dash /bin/bash
  • rsync 12y ago
    Actually, the first test would be 'which bash', since not all systems have it installed by default. Notably, FreeBSD, which has never included it by default.
  • valamit 12y ago
    so bash: warning: evil: ignoring function definition attempt bash: error importing function definition for `evil' would mean it's not?
    • yoha 12y ago
      That's the message you get on a patched machine. However, the patch is not sufficient: https://news.ycombinator.com/item?id=8365216 https://news.ycombinator.com/item?id=8365216 .
      • berkut 12y ago
        Or an earlier version of bash (4.1), which I'm assuming (haven't installed any patches within the last month on a centOS6 machine) hasn't got the issue?
        • bodyfour 12y ago
          If you see that "ignoring function definition attempt" message you definitely have the first patch applied (but not necessarily a fix for the second problem) That diagnositc was added by the patch itself. See http://ftp.gnu.org/pub/gnu/bash/bash-4.1-patches/bash41-012 http://ftp.gnu.org/pub/gnu/bash/bash-4.1-patches/bash41-012 Maybe you have auto-update turned on and didn't realize it?
• pdkl95 12y ago
  This is probably just a local problem in what I will euphemistically describe as my "very highly customized" shell, but... it might be useful to use "/usr/bin/env instad of just plain "env" in that one-liner test for the vulnerability. (or maybe the "command" builtin instead? It seems to also 'properly' show the vulnerability as well, but I'm not if that would affect the test in some cases)
• aus_ 12y ago
  Shellshock is also "reverse-shell-able". This Python script relies on /dev/tcp which is not available by default on some distros. (Source: @ortegaalfredo) But you could probably rework it to use netcat. http://pastebin.com/raw.php?i=166f8Rjx http://pastebin.com/raw.php?i=166f8Rjx
• ck2 12y ago
  Patched all the CentOS machines hours ago, whew. It's on yum now, just yum update
• blocke 12y ago
  Rogue DHCP servers should not be a problem in any decently engineered enterprise or college campus network. Cisco switches have included DHCP snooping for years which when used only allows authorized switch ports to act as a DHCP server. Any decent enterprise wireless platform should either have transparent firewall functionality to block client DHCP responses or an equivalent to DHCP snooping. If you've properly deployed these tools you've greatly limit the potential impact of a DHCP based worm. Home router? Anyone test this against Linksys junk yet?
• Animats 12y ago
  What about simply disabling CGI in Apache? If you're not using it, turn it off. Use "--disable-cgi" at Apache launch. This will break some "control panels", but you probably shouldn't be using a CGI-based control panel in 2014 anyway.
• deanclatworthy 12y ago
  Can anyone outline some clear steps for those of us on Debian Squeeze who have not yet got a patch?
  • thaumaturgy 12y ago
    Yes, you can switch to squeeze-lts and then update just bash. First, add the following two lines to your /etc/apt/sources.list: deb http://http.debian.net/debian/ squeeze-lts main contrib non-free deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free (you do not need to change or remove any other lines from sources.list). Then run the following command: apt-get update && apt-get install --only-upgrade bash ...which will update your apt sources (but not your installed software) and then will upgrade bash and only bash.
    • deanclatworthy 12y ago
      Thank you. This worked.
    • lemming 12y ago
      I just did this and got no upgrades.
      • thaumaturgy 12y ago
        squeeze-lts is only available for i386 or amd64 architectures, I think, or you might be hitting an out-of-date mirror. You might try http://mirror.cc.columbia.edu/debian/ http://mirror.cc.columbia.edu/debian/ instead of http://http.debian.net/debian/ http://http.debian.net/debian/
        • lemming 12y ago
          Using Columbia didn't help either. Using uname -m shows x86_64 so I guess that's it. I'll just have to wait for another update.
          • 12y ago
• zaroth 12y ago
  Shellshock is a perfect name coming after Heartbleed. But this bug is suffering from lack of marketing, lagging in the news behind the iOS update being pulled. It's sad to see an RCE somewhere so widespread and so interwoven with other software. It's also costly because now I'm questioning server integrity, thinking about what should really be re-imaged. I assume there are many more like this in the CVE pipeline... At some point I just have to live with the fact that outside access is possible to anyone so motivated.
  • prawn 12y ago
    Front page of the site of one of the major Australian newspapers: "Largest bug ever hits the internet" I think it will start to make its way out to the public with a bit more time.
    • zaroth 12y ago
      I'm sure they've picked up now that the patch was bad. Should be an interesting day. Wow the comments there are...
      • timv 12y ago
        If your conclusion that the patch was bad is based on the fact that CVE-2014-7169 still exists, I think that's an unfair assessment. The patch appears to have been a adequate fix to the bug that was discovered. The fact there is a second bug with a similar but not-identical attack vector, is a reflection on the robustness/correctness of the original code more than it is a reflection on the quality of the patch.
        • bodyfour 12y ago
          ... and also a reflection of how much security attention this one obscure feature has been receiving in the last 24 hours. This is very similar to the pattern we saw with heartbleed: a terrible bug with a lot of publicity followed by a series of other vulnerabilities found of various severity as suddenly it was "all eyes on OpenSSL": http://www.openssl.org/news/secadv_20140806.txt http://www.openssl.org/news/secadv_20140806.txt I wouldn't be surprised if we're going to see a repeat of that here.
• schniggie 12y ago
  CVE-2014-6271 cgi-bin reverse netcat shell https://gist.github.com/schniggie/5eeeb8ac943b5c2bb356 https://gist.github.com/schniggie/5eeeb8ac943b5c2bb356
  • verroq 12y ago
    Approximate 0% of production systems have netcat. Just pick your favourite one liner from http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-ch....
    • wiredfool 12y ago
      It's in the cloud images for Ubuntu 14.04.
• f00ber 12y ago
  Oh stop this stupidity already. If you are not running a Web server that spawns bash when serving an HTTP request, then you are NOT vulnerable. Are you running a Web server that uses CGI scripts written in shell or plain C that uses system() call? If you do, you have had other problems long before. There are some grumblings about DHCP _client_ setups on Linux passing parameters via environment variables to shell scripts executed by bash, but I am yet to see this. This would be a problem, but probably easily fixable. No need to panic or even patch anything (as always). If you running servers on your machine and allow inbound connections you should know exactly what those servers are and what they execute on behalf of external users. This is NOT remotely exploitable. It's an ad campaign for "security researchers" people.
  • clarry 12y ago
    It is hilarious that you claim this is not remotely exploitable in response to a post describing how a very simple and limited scan has already found thousands of vulnerable hosts in a short timeframe. And I dare say there are lots of admins who do not know exactly what their servers are going to execute because they're using software written by other people. That's why we call them admins, not software developers. By the way, system() can be used in quite a lot of languages, not just in plain C. And there are definitely more attack vectors than CGI. CGI is just the most obvious one.
    • f00ber 12y ago
      Well, let these _admins_ worry about this. This is of no concern for the moment for a regular Linux or OS X user. Now, an admin _must_ know every service running on entrusted boxes facing the Internet. CGI scripts hopefully are not common these days. If you run them do stop for other reasons. So far every "attack vector" implies having shell access to the target machine in some form. No need to panic for majority of people.
      • ccvannorman 12y ago
        Can you clarify this? As a Mac OS X user who connects to public wifi often, I'm still in the dark about whether I should literally turn off my wifi for now..
• f00ber 12y ago
  Oh stop this stupidity already. If you are not running a Web server that spawns bash when serving an HTTP request, then you are NOT vulnerable. Are you running a Web server that uses CGI scripts written in shell or plain C that uses system() call? If you do, you have had other problems long before. There are some grumblings about DHCP _client_ setups on Linux passing parameters via environment variables to shell scripts executed by bash, but I am yet to see this. This would be a problem, but probably easily fixable. No need to panic or even patch anything (as always). If you running servers on your machine and allow inbound connections you should know exactly what those servers are and what they execute on behalf of external users. This is NOT remotely exploitable. It's an ad campaign for "security researchers" people.
• f00ber 12y ago
  Oh stop this stupidity already. If you are not running a Web server that spawns bash when serving an HTTP request, then you are NOT vulnerable. Are you running a Web server that uses CGI scripts written in shell or plain C that uses system() call? If you do, you have had other problems long before. There are some grumblings about DHCP _client_ setups on Linux passing parameters via environment variables to shell scripts executed by bash, but I am yet to see this. This would be a problem, but probably easily fixable. No need to panic or even patch anything (as always). If you running servers on your machine and allow inbound connections you should know exactly what those servers are and what they execute on behalf of external users. This is NOT remotely exploitable. It's an ad campaign for "security researchers" people.
• idorosen 12y ago
  For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and am going to apply the CVE-2014-7169 patch as well once it passes review. Repository and instructions to reproduce without trusting me are located here: https://github.com/ido/macosx-bash-92-shellshock-patched https://github.com/ido/macosx-bash-92-shellshock-patched
• daviddede 12y ago
  It absolutely is. Specially now with thousands of cPanel servers known to be vulnerable: http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shock-thousands-of-cpanel-sites-are-high-risk.html http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shoc...
• hamstergene 12y ago
  I'm really surprised how many people out there write CGI in Bash. That's one of the things which would have never crossed my mind.
  • sophacles 12y ago
    It's less about writing CGI in bash, and more about writing CGI, then eventually calling system() from within the CGI program. This is very common, particularly with monitoring pages, etc.
• milankragujevic 12y ago
  Smart little tool to check if your website is vulnerable http://milankragujevic.com/projects/shellshock/ http://milankragujevic.com/projects/shellshock/ It can also do a deep check that checks many known URLs, not only the home page.
  • paulpepper 12y ago
    Is it possible for you to make the source for your test publicly available?
• urs2102 12y ago
  What you can do: http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7 http://apple.stackexchange.com/questions/146849/how-do-i-rec... If you need a temporary fix until there is a new update - this can prove to be quite useful.
• ccvannorman 12y ago
  Sorry in advance for noobing up this thread, but can you clarify this? As a Mac OS X user who connects to public wifi often, I'm still in the dark about whether I should literally turn off my wifi for now.. or am I safe?
  • wglb 12y ago
    The problem comes about if your mac is serving web pages. If you aren't then there is less worry.
    • Salemzzz 12y ago
      I think even just using DHCP put your Mac at risk: https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/ https://www.trustedsec.com/september-2014/shellshock-dhcp-rc...
      • wglb 12y ago
        That is true, if you don't control where the Mac can contact a DHCP server.
• krunkosaurus 12y ago
  Isn't this all just armchair prophesying? Let's see some screenshots actual exploits from anyone. It's hard to gain access to someone's shell unless it's 1990 and a server is using CGI-BIN. People are retweeting that this is "WORSE THAN HEARTBLEED!!!!111!" but Heartbleed literally left practically every server susceptible. I ran sample exploit code against a number of tests hosts and saw mysql queries and passwords streaming in plain text. Yeah shellshock is a big deal but I've yet to the ground rumble and shake and Y2K x 10000 happen. This seems like a big deal but it actually isn't. Most likely no one can access your shell. Patch and move on.
  • eropple 12y ago
    Well, that depends. Are you running Passenger? http://blog.phusion.nl/2014/09/25/security-advisory-phusion-passenger-cve-2014-6271-bash-vulnerability/ http://blog.phusion.nl/2014/09/25/security-advisory-phusion-... What about the rest of your servers? I can't claim to know that none of mine don't call system() somewhere deep in them.
• dholl 12y ago
  I got tired of the hype. How's the following code for a mitigation? Basically, if some program does invoke /bin/bash, control first passes to this code which truncates suspicious environment variables. (and it dumps messages to the system log if/when it finds anything...) The check should match for any variety of white space: =(){ =() { = ( ) { etc... but feel free to update it for whatever other stupid things bash allows. The code is at http://ad5ey.net/bash_shock_fix.c http://ad5ey.net/bash_shock_fix.c Simple usage: cd /bin gcc -std=c11 -Wall -Wextra bash_shock_fix.c -o bash_shock_fix mv bash bash.real ln -s bash_shock_fix bash phoenix(pts/1):~bin# ls -al bash* lrwxrwxrwx 1 root root 14 Sep 27 00:23 bash -> bash_shock_fix -rwxr-xr-x 1 root root 1029624 Sep 24 14:51 bash.real -rwxr-xr-x 1 root root 9555 Sep 27 00:23 bash_shock_fix -rw-r--r-- 1 root root 2990 Sep 27 00:23 bash_shock_fix.c phoenix(pts/1):~bin#