The first reason is that the bug interacts with other software in unexpected ways. We know that interacting with the shell is dangerous, but we write code that does it anyway. An enormous percentage of software interacts with the shell in some fashion. Thus, we'll never be able to catalogue all the software out there that is vulnerable to the bash bug. This is similar to the OpenSSL bug: OpenSSL is included in a bajillion software packages, so we were never able to fully quantify exactly how much software is vulnerable.
The second reason is that while the known systems (like your web-server) are patched, unknown systems remain unpatched. We see that with the Heartbleed bug: six months later, hundreds of thousands of systems remain vulnerable. These systems are rarely things like webservers, but are more often things like Internet-enabled cameras.
Internet-of-things devices like video cameras are especially vulnerable because a lot of their software is built from web-enabled bash scripts. Thus, not only are they less likely to be patched, they are more likely to expose the vulnerability to the outside world.
Unlike Heartbleed, which only affected a specific version of OpenSSL, this bash bug has been around for a long, long time. That means there are lots of old devices on the network vulnerable to this bug. The number of systems needing to be patched, but which won't be, is much larger than Heartbleed.
There's little need to rush and fix this bug. Your primary servers are probably not vulnerable to this bug. However, everything else probably is. Scan your network for things like Telnet, FTP, and old versions of Apache (masscan is extremely useful for this). Anything that responds is probably an old device needing a bash patch. And, since most of them can't be patched, you are likely screwed.
Update: I think people are calling this the "shellshock" bug. Still looking for official logo.
Update: Note that the thing with the Heartbleed bug wasn't that that the Internet was going to collapse, but that it's in so many places that we really can't eradicate it all. Thus, saying "as bad as Heartbleed" doesn't mean your website is going to get hacked tomorrow, but that a year from now we'll be reading about how hackers got in using the vulnerability to something interesting.
Exploit details: The way this bug is exploited is anything that that first sticks some Internet parameter in an environmental variable, and then executes a bash script. Thus, simply calling bash isn't the problem. Thus, some things (like PHP apparently) aren't necessarily vulnerable, but other things (like CGI shell scripts) are vulnerable as all get out. For example, a lot of wireless routers shell out to "ping" and "traceroute" -- these are all likely vulnerable.
20 comments:
Never mind my previous comment, I've done some further research... seems a bit shocking that some server processes will take untrusted input provided by the user and stick it into a bash environment variable. Or is that just my ignorance of web server processes talking?
Thank you for a down to earth summary, rather than the rhetoric driving clicks. Very much appreciated.
shellshock
http://i.imgur.com/h4wSK8f.png
I'm still unsure how are any embedded devices (routers among them) vulnerable to this particular CVE.
Can you please point me at router firmware (or custom router firmware) that actually uses bash, the latter being one of the slowest and resource-hogging shells? Almost all Linux-based routers run Busybox, which implements its own tiny shell.
This also does not affect the majority of *NIX/BSD servers as those usually don't have bash (besides possible personal user shells, and those that host CGI scripts that specifically use #!/usr/bin/bash instead of #!/bin/sh; /bin/sh is never bash in this case). Same can be said about Ubuntu which uses dash as its /bin/sh replacement. As in, the vulnerability can be exploited on these systems, but only locally (and probably only if there are setuid bash scripts, otherwise all you get is run some code with your own effective UID/GID).
sudo apt-get install --only-upgrade bash
source:http://www.linuxnews.pro/patch-bash-shell-shock-centos-ubuntu/
Please correct me if I'm not understanding this properly. Everyone is going OMG OMG OMG I has bash on my system, therefore any hacker can suddenly do anything on any Linux computer that's out there, including my desktop, android phone, and any VPS Linux hosting servers I have....
In order for this to be exploited, all of the following must happen:
1) expose a service on the internet
2) that service has a feature where a parameter or argument that originates from the user side, is placed in an environment variable, intended to be used by bash.
3) that service spawns bash to perform some task
And less likely, the other way around. Where you run client side software that has a feature that spawns bash to perform a task, where the server side gets to decide on something that ends up in an environment variable on the client side.
So. This means that a hacker just accessing a webpage is not going to be able to use this security hole.
A CGI script is an obvious risk, but who uses that anymore? To feed dynamic content, much more often are things like php and Java using JSP and things like that. Neither of those ends up using bash, and even if it did, there is no way to influence an environment variable.
Then there is talk about "but you have telnet on your system, therefore you're screwed". Ok, I have telnet. So now what. A hacker can invoke my telnet app? No. I'm going to telnet into a malicious server?
Ok, so, I might use telnet to debug a remote html server. telnet google.ca 80. And then type "GET /" enter enter. Even if Google tried, could they inject something causing bash to run something for them? Noway.
Yes, this bug is big, I'm sure. But it seems to be that the stars kind of have to line up, for a hacker to do anything with it. Anything that spawns bash where an environment variable is used to store an argument...
That's it isn't it?
And I'd love to patch it, but my Ubuntu 13.10 box, upgrade bash only got bash to version 4.2.45
A remote server is using Ubuntu 9.10. apt-get doesn't appear to work anymore on that one.
So now what. Compile a patched bash executable from source? Probably would be dependency hell, to get it to compile.
So, am I panicking too much, or too little here?
PANIC!!
Check out https://shellshocker.net/ for an online vulnerability tester and also a guide to fix your system.
So even patched to latest 4.3.25, even though test 1 no longer shows the bug, test 2 still fails.
So, it seems that there exists no full fix for this bug up till now.
Apparently, the stuff like user-agent, context type, or some other stuff usually sent in headers is provided to CGI scripts (e.g.: bash) using environment variables. So, in order to run arbitrary command, all you need to do is send a slightly mangled user agent string. So, yes, this is pretty exploitable
não entendi nadinha......
Sergey, thanks, that makes sense. However, causing an environment variable to contain a malicious script is not enough. Something has to spawn a bash process. Cgi-bin can cause that, but who uses that these days?
Any other ideas of spawning bash processing in remote services like Apache?
~Mike
I’m completely with Unknown and 古明地さとり.
Also, why is nobody panicking about the ability to override builtins and /bin tools by passing functions of the same names in environment variables? Merely because it’s harder to exploit?
I have created a Public Domain svg shellshock logo:
Shellshock Logo SVG courtesy of Tanner Brockwell
CUPS can run shell filters. Most of them have #!/bin/sh, textonly has #!/bin/bash (WTF?). So on Debian and Ubuntu systems that symlink /bin/dash to /bin/sh, no real problem except for textonly.
Now CUPS isn't normally exposed outside a firewall (unless you happen to have it on your laptop and connect to a public wifi network).
I do agree that while the exploit is severe, it may not be as widespread as the media and some "experts" say it is. For example, the default shell on dd-wrt and openwrt is busybox, as a lot of the supported routers only have 4-16MB of FLASH and 2-64MB of RAM. While bash is available as an installable package for embedded routers, it's not used extensively, and isn't installed as /bin/sh, so things that shell out like udhcpc won't touch it.
ps. GNU site today made available patch 26 which plugs the hole completely.... It compiles from source without too much hassle. Careful installing! By default it goes in /usr/local somewhere, which won't be good enough. Copying it to /bin/bash you'd have to chmod o+rx afterwards.
In other news: NetBSD and FreeBSD now offer a build-time option that enables function imports from envvars (disabled by default) for the bash port.
To quote:
> It is not wise to expose bash's parser to the internet and then debug it live while being attacked.
False, wrong, hoax, the bug is not affecting everyone on the web, but just those having specific websites using (insecure) cgi-bin.
Why are people so crazy about it, I don't know. For myself, I won't update bash. I don't see the necessity. Heartbleed was indeed a bigger big deal.
Lolo, I disagree. While I agree that the most frequent most obvious hole is cgi-bin spawned from Apache, there are other targets. For instance you could have an exec() statement (or one of the related ones) inside a php script.
You yourself might not be directly affected, but a (small?) percentage of servers on the internet are hackable right now. A small percentage of half a billion servers is not nothing.
There are various stat-reporting packages that are cgi-bin based and other standard tools. Hackers will be scouring the internet for servers that have that. We will see shellshock scans for a long to come probably.
Post a Comment