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.
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.
Linky
"National Security is the chief cause of national insecurity." - Celine's First Law
Thanks god I am using windows.
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.
That said, you know someone does this. Hell, I have had to deal with web applications written mostly in shell and did much of their processing in shell.... the only thing that really topped it for idiocy was when I dove into some perl4 code for a password change form and found this gem:
$password = $q->param('password'); /usr/dict/words`" != "" {
if "`grep $password
}
No taint checking, nothing, just shell out with whatever someone put in the form. I loaded it up and added a "; touch /tmp/foo" on the end and verified there was no protection, then I found 4 more similar errors and figured that since security issues were not even why I opened the code to read it....I re-wrote it from scratch.
"I opened my eyes, and everything went dark again"
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.
Awww, come on, don't bash Bash when it is down...
Excuse me, but please get off my Pennisetum Clandestinum, eh!
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.
> 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.
Pfffft. I should have expected Korny jokes. (Ba-dum-csh.)
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
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.
sudo mv /bin/bash /bin/woosh
Bash has always felt a bit dangerous...
POUND! BANG! SLASH! bin SLASH! BASH!
#!/bin/bash
Example attacks are listed on Red Hat's security blog.