Slashdot Mirror
Remote Exploit Vulnerability Found In Bash
kdryer39 sends this news from CSO: A remotely exploitable vulnerability has been discovered by Stephane Chazelas in bash on Linux, and it is unpleasant. The vulnerability has the CVE identifier CVE-2014-6271. This affects Debian as well as other Linux distributions. The major attack vectors that have been identified in this case are HTTP requests and CGI scripts. Another attack surface is OpenSSH through the use of AcceptEnv variables. Also through TERM and SSH_ORIGINAL_COMMAND. An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation.
I'm not suprised; Bash has always felt a bit dangerous...
https://marc.info/?l=oss-security&m=141157106132018&w=2
-=/\- Jizzbug -/\=-
Because we've finally become popular enough to warrant script kiddies finding holes in our toys!
Captcha: Outcry
I can't find the bash icon in the Start menu. Anyone know where it is so I can remove it and avoid this exploit?
Thanks.
sudo yum update bash
Thank you for the quick warning.
So, if I undestand correctly, this affects shell scripts used for CGI; do people actually do that on what scale?
Only person I know who does this is a CS teacher in my college, onhis homepage which he has had since early 90s, are there actually commercial installations which do this, some major product with large install base ("asking this for my son")?
Linky
"National Security is the chief cause of national insecurity." - Celine's First Law
Thanks god I am using windows.
This is the test to see if you are vulnerable:
:;}; echo vulnerable' bash -c "echo this is a test"
env x='() {
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
All the systems I've done security pen tests against that were using bash for CGI were so easy to hack via other means it wasn't funny. And of course that web server CGI was running as root so root shell and done.
Stop using Bash for CGI unless you want to get pwned. Similar theme with 90% of the Perl CGI I run into.
My favorite of this sort of thing is CVE-2009-1717, which was a bug in Apple's terminal emulator in Mac OS X. Sending certain escape sequences to it caused it to blow up and potentially execute code. What was fun is that putting a "telnet://" link in a web page would automatically cause Mac OS X to automatically open a terminal and connect to a remote host with no prompting by the user. It was a pretty neat vulnerability.
...but it's being eaten...by some...Linux or something...
Someone correct me if I'm mistaken, but doesn't this exploit depend on programs not validating input?
The example given in the post to oss-security mentions HTTP request headers containing malicious data being passed into CGI programs which then call out to Bash. Wouldn't taint-checking input eliminate that attack vector?
Well, that's OK. i is like a for large enough values of a (or really small values of i).
And depending on what part of the world you're in, the sound of vowels can change quite a bit.
A few years back, my wife's mother and some friends were in the southern US ... she walked into the store and asked if they have any pins ... the cashier asked if she "wanted a ball point pin or a fountain pin". I kid you not.
In fact, my wife had an economics prof from Texas once. There was no discernible difference between the sound of "microeconomics" and "macroeconomics", because apparently a and i have the same value there.
Therefore, in Texas, your statement is 100% true. ;-)
Lost at C:>. Found at C.
VAR=() { ignored; }; : :(){ :|:& };:
#include bier;
> Someone correct me if I'm mistaken, but doesn't this exploit depend on programs not validating input?
Suppose you have pwd.cgi, which prints the name of the current directory:
#!/bin/sh
echo -e "Content-type: text/plain\n\n"
pwd
Notice the script uses no input at all. It is potentially vulnerable. Here's why. Suppose you did want to validate your input. You'd look at the contents of $QUERY_STRING, right? You can find what the user entered in the QUERY_STRING environment variable because bash puts it there. That's the step where the problem lies - bash can EXECUTE the contents of the query string while setting the environment variable. This occurs before the user's script even begins to run.
app-shells/bash-4.2_p47-r1 is not vulnerable. I just updated.
> Oh I had the same thought....I mean, by the time an "attacker" is modifying arbitrary environment variables in your process, well...you are already pretty compromised. If you wrote your CGI, then you are the one that compromised yourself.
The contents of the CGI script don't matter. The exploit occurs before the script runs. It happens as bash is setting up the environment in which the script will be run.
Suppose you have pwd.cgi, which prints the name of the current directory:
#!/bin/sh
echo -e "Content-type: text/plain\n\n"
pwd
Notice the script uses no input at all. It is potentially vulnerable. Here's why. Suppose you did want to validate your input. You'd look at the contents of $QUERY_STRING, right? You can find what the user entered in the QUERY_STRING environment variable because bash puts it there. That's the step where the problem lies - bash can EXECUTE the contents of the query string while setting the environment variable. This occurs before the user's script even begins to run.
Almost *ANY* CGI is vulnerable, because the way CGI works is by environment variables. And the attacker can control them. You don't have to be doing anything stupid or wrong to be affected. It looks like other ways of executing web applications (e.g., mod_php) are safe - to the extent that they don't use a popen or a system() or something, which is a pretty common thing to do.
Your DHCP client (on a Linux) machine passes data to its hooks via environment variables. These can be set by the attacker. Even better, it's running as root. Boom, connect to a rogue AP and get rooted while receiving an address assignment.
You probably do Git commits via a (locked-down) SSH login. That's compromised.
Shells are everywhere. Again, this doesn't require your application to have screwed up. This is a flaw in how environment variables are parsed and set, which is something that was presumed safe, so nobody thought about it. Bad bad bad bad. Not Heartbleed bad, but close.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
Sure, but anything remote that can set up environment variables before starting bash can exploit it. Lots of idiot programmers like to blindly shell out to do stuff even when there's a simple library function to do things, such as unlink("$path") vs. system("rm $path"). And environment variables have this pesky habit of sticking around when you do that. Environment variables are commonly used with CGI, which is also commonly used with idiot programmers. So while it may be a "local" exploit, that's with unusually large values of "local".
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
sudo mv /bin/bash /bin/woosh
Well I don't know much bash, so I figured out why this is happening, though it still seems unbelievable.
Apparently the normal way to define a function is to write "x() {...}". But it stores it in an environment variable for some reason, I think so that a recursively called bash gets the same function definition.
To support that, on startup it scans the environment for variables starting with "() {" (spacing must be exactly that). It then defines the function by pasting the variable name onto the start of the variable and interpreting that. And the interpreter splits at the semicolons and executes the remaining text as commands, leading to this bug.
The whole thing looks pretty messy. Certainly it should have been possible to call some lower-level function *after* the interpreter has figured out it is defining a function, and that one would barf on the semicolon. Also you get this interesting and misleading effect:
$ export x='() { echo WORKS;}'
$ x
x: command not found
$ bash -c x
WORKS
Their solution is rather annoying because you now cannot set environment variables to all possible byte strings. That sucks. They should have left the environment variable set to the text and not defined the function.
Example attacks are listed on Red Hat's security blog.
The problem affects any CGI that *calls* bash, which means any call to system() in any language is going to cause a problem.
Nowadays, on most systems, /bin/sh is a proper Bourne Shell (either ash or dash), and no longer bash. So system() should no longer be an issue, but explicitly calling bash still would be...