Slashdot Mirror

← Back to Stories (view on slashdot.org)

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

Posted by timothy on from the oy-oy-oy dept.

The recently disclosed bug in bash was bad enough as a theoretical exploit; now, reports Ars Technica, it could already be being used to launch real attacks. In a blog post yesterday, Robert Graham of Errata Security noted that someone is already using a massive Internet scan to locate vulnerable servers for attack. In a brief scan, he found over 3,000 servers that were vulnerable "just on port 80"—the Internet Protocol port used for normal Web Hypertext Transfer Protocol (HTTP) requests. And his scan broke after a short period, meaning that there could be vast numbers of other servers vulnerable. A Google search by Ars using advanced search parameters yielded over two billion web pages that at least partially fit the profile for the Shellshock exploit. More bad news: "[T]he initial fix for the issue still left Bash vulnerable to attack, according to a new US CERT National Vulnerability Database entry." And CNET is not the only one to say that Shellshock, which can affect Macs running OS X as well as Linux and Unix systems, could be worse than Heartbleed.

13 of 318 comments (clear)

  1. Worse than Heartbleed? by charlesbakerharris · · Score: 3, Insightful

    You mean "worse than a vulnerability that doesn't seem to have been exploited on any significant scale"?

    1. Re:Worse than Heartbleed? by Anonymous Coward · · Score: 4, Insightful

      What a stupid argument.

      1. It will be, if it wasn't before.

      2. You can't know that information.

    2. Re:Worse than Heartbleed? by LordLimecat · · Score: 3, Insightful

      Heartbleed exploits were and will continue to be generally undetectable. If any private keys were stolen, we wont ever know.

    3. Re:Worse than Heartbleed? by Anonymous Coward · · Score: 5, Insightful

      I just rm -rf / a vulnerable linux laptop (dummy laptop) simply by having it connect to my malicious dhcp server.

    4. Re:Worse than Heartbleed? by wagnerrp · · Score: 4, Insightful

      There are a large number of systems where the fix for this is simply to delete the thing.

      If you could simply delete it, because you weren't using it, your system was never vulnerable and in need of fixing anyway.

    5. Re:Worse than Heartbleed? by Anonymous Coward · · Score: 4, Insightful

      Bah. Just replace bash then - or upgrade it. Read about this bug today (on a linux machine), tested for it - and it was fixed already. The bug may be a bad one, but the fix is out already. Got it through a standard upgrade of arch, no specific action to fix this. Fix bash, and all that cgi/ssh is as safe as ever.

      Trivial to exploit - but trivially fixed too.

  2. "could be worse than Heartbleed" by Junta · · Score: 3, Insightful

    To be fair, anyone using bash as the cgi handler for anything remotely serious was already doing it wrong. Bash by it's nature is a facility trying to let the presumably authenticated user of it to do whatever they want, even if it looks somewhat weird. Yes this bug warrants fixing, but putting bash or similar in a path where untrusted environment variables and/or argv is present is a very dubious design decision. Besides, fork and exec for every request is a huge no no, and that's the only way to fly with bash.

    Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:"could be worse than Heartbleed" by jpvlsmv · · Score: 5, Insightful
      Except for the system "utilities" that are actually bash scripts, such as /usr/bin/xzgrep. These are vulnerable to inheriting malicious environment variables from the parent processes even if the overlying process is not a shell script.

      The other reasonable vector is the use of environment variables set by your dhcp client before running /etc/sysconfig/if-up.d/* based on whatever is contained in the first DHCPOFFER packet it receives.

    2. Re:"could be worse than Heartbleed" by fnj · · Score: 4, Insightful

      You mod him up, and people who are smart will mod him down.

      Try to understand, this is not about executing bash scripts as cgi, and it's not about sanitizing input. Period. It is about httpd setting environment variables from unsanitized user input when calling ANY cgi. And if perl or python or php then invoke bash by, for example, executing a call to system(), the environment gets passed to bash, and bash can be made to execute something bad just by having the environment set badly, and you can be pwned.

      It took me a bit to "get it" myself.

  3. Preempting dumb discussion by LordLimecat · · Score: 4, Insightful

    Looking at security discussions in terms of OS is really, really dumb. Windows wasnt vulnerable to heartbleed or this, but not because its Windows. Linux isnt affected because of the kernel. As has been the case for a very long time, actual OS flaws are exceedingly rare.

    Anyone who uses this as an opportunity to post a screed about how Linux is better or worse than Windows is showing their ignorance by boiling down complex security considerations into black and whites.
     

  4. How to disable CGI in Apache by Animats · · Score: 5, Insightful

    If you're running Apache on Linux/UNIX, and don't absolutely need CGI, turn it off now.

    Put a "#" in front of
    LoadModule cgi_module modules/mod_cgi.so
    in /etc/httpd/conf/httpd.conf. This will totally disable all CGI scripts. That's a good thing. Apache is willing to execute CGI scripts from far too many directories, and many Linux distros have some default CGI scripts lying around.

    Note that this will break CPanel, but not non-CGI admin tools such as Webmin.

    People are out there probing. This is from an Apache server log today from a dedicated server I run.

    89.207.135.125 - - [24/Sep/2014:23:08:56 -0700] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 301 338 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

  5. Re:So flog the bash developer who checked this in. by Aristos+Mazer · · Score: 5, Insightful

    The bug is 25 years old at least. Pre-dates the existence of GIT and most other source code control software in use today. I have no idea what SCC would've been used 25 years ago. To give perspective -- this bug predates the WWW by at least a year.

  6. Re:I love it. by Anonymous Coward · · Score: 0, Insightful

    Yes, on Linux you have bugs that allow anyone with even basic technical skills to remotely exploit your servers. And you're bragging about this, asshole?

    Windows exploits are of the "Hey, idiot, run this thing!" nature, and of course many idiots run it. If you are halfway intelligent it's easy to run a secure Windows machine.

    Linux exploits, especially this ridiculous mack-truck sized one, are of the "Fuck you, I own your machine asshole" variety. They are drinking your milkshake, and you're still waxing clueless about how bad Windows is when it is superior in just about every technical dimension _other_ than the fact that 70% of its users are complete idiots, compared to only about 40% on Linux.

    The fact is that this "bug" shows what assholes you neckbeards are. It's an enormous bug that will plague you for months and years, all the while you bloviate to anyone who will listen how secure Linux is.

    Good luck, douchebag. This couldn't have happened to a happier bunch of fuck-knuckles, frankly.