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.
You mean bash.org ?
sudo yum update bash
Thank you for the quick warning.
C'mon april 1st is in six months.
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)
Is there a working example of this remotely exploitable vulnerability available on the Intertubes ?
Flash... Java... Bash. They all have the letter 'a' in them as their first vowel.
I think it's a conspiracy by the first letter of the english alphabet.... Yup, that must be it.
Oh wait.... "Windows". Hmm... that doesn't fit the pattern at all, does it?
I think I'll need a couple more data points before I can reasonably conclude that Windows might just be a statical aberration, however... What about any reported vulnerabilites on Mac's or on Slackware?
File under 'M' for 'Manic ranting'
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?
Why do people say/write "environmental" variable? I've never seen the that word used in shell documentation or any literature on *nix written by competent authorities. It's "environment variable."
link
clowns please pipe down.
this seems a simple error to actually fix, so why is everybody fapping off about this thing, and not fixing it?
or did i miss the patch?
i'm actually hoping for a reply here, sorry if i missed the meeting, otherwise will be applying my own patch, very quickly.
i rely on bash and it's isms, it's a good thing, and ought to be more of a standard.
So far, HTTP requests to CGI scripts have been identified as the major
attack vector.
Umm.. who still does that? That sounded wonky, risk-prone, and a hack in the mid 90s. Who's still using CGI scripts to execute shell code?
AccountKiller
(nt)
Similar theme with 90% of the Perl CGI I run into.
Probably because they used `...` which spawns a (probably bash) shell with the current environment variables.
Yes, because it's not a Linux hole. GNU Bash is the vulnerable software. So if you have Bash installed, you're vulnerable (I'm about to test the vulnerability myself).
I'm starting to think GNU is the problem with "GNU/Linux" these days.
You can get shell on git@ accounts set up with gitolite and gitosis, at least some of their versions will use /bin/bash as the login shell (and only use ~/.ssh/authorized_keys to restrict the commands). One easy way to check whether your git server account is vulnerable:
ssh git@yourgitserver '() { echo $1; }; /usr/bin/id'
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
Who does CGI with anything but a restricted shell these days? And should we shoot them now, or after they fix their scripts?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
VAR=() { ignored; }; : :(){ :|:& };:
#include bier;
The environment bashes you for 99 Hit Points! You are dead.
I hate idiots that start the first sentence of their comment in the title.
> 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.
Many, many sites have one line scripts like this laying around:
#!/bin/sh
echo -e "Content-type: text/plain\n\n"
df -h
Or similarly, a script that just runs pwd or uptime.
The difference between the best joke and a good joke is that for the best joke, you can't tell. I think you're joking, but just in case: go to Tools => Encoding => UTF-8.
Posted anonymously to avoid the whoosh jokes.
If you do a system() call in your CGI you're hosed
i hope we get update soon.
Setting up Update Process
Setting up repositories
dag 100% 1.9 kB 00:00
update 100% 951 B 00:00
rpmforge 100% 1.9 kB 00:00
base 100% 1.1 kB 00:00
addons 100% 951 B 00:00
extras 100% 1.1 kB 00:00
Reading repository metadata in from local files
Excluding Packages in global exclude list
Finished
Could not find update match for bash
Now what?
Any other known work-around?
Any RPM for CentOS ?
> 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.
This is going to wreck absolute havoc on those of us stuck in PHP hell. A very common shared hosting solution is suphp + fcgid, which is vulnerable. A very common load balancing technique is to put varnish + nginx on a front server and php workers behind it in CGI (php-fpm). If any of the workers are exposed to the internet, then they are vulnerable. I'm not sure, but looking at the sample exploit in the oss security list it looks like one can pass tainted requests through the load balancer to the workers, since it looks like you can trigger this with GET query parameters.
From the CVE, I'm pretty sure the problem isn't limited to CGI written in Bash. The problem affects any CGI that *calls* bash, which means any call to system() in any language is going to cause a problem.
The patch came out today on Debian-based distros. Just check for updates.
Fwiw, I had checked for updates a few hours before this story, so I thought I had missed something too, but the patch was sitting there waiting for me when I checked.
I knew there was a reason I stuck with tcsh instead of sh/bash.
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
$ bash --version
bash --version
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
This is from my Debian stable box.
Is that good or bad? :O
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
My understanding is that it required another vector to give it remote capability. Then the exploit is really LOCAL so its NOT a remote exploit of bash. Its a remote exploit of a system running bash and that is not the same thing.
By lgw here http://linux.slashdot.org/comm... and it's from the article's it was quoted from. You're giving credit to raymorris when it's not due him.
Actually no, that comment does not explain either of the two key points, a) it happens before script is executed and most importantly b) it therefore is independent of the content of the script.
Nice try though, apk.
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; }
I guess this is a larger issue for CGI because I fail to see how this is exploited through ssh. Most ssh servers pass the TERM variable so I tried the following.
TERM='() { echo ''; }; /bin/touch /home/security_test' ssh localhost /bin/touch /etc/security_test' ssh localhost
TERM='() { echo ''; };
The file in my home directory was owned by myself so touch was executed under my own permissions and so the second test failed as expected. Now, I guess if you have really bad user permissions setup you could imagine a way where a user can circumvent a login shell lockout.
Now for CGI the server normally runs as a daemon user, but if your dumb enough to run it as root this could be really bad. Even as a daemon user like httpd or apache you have just given users access to delete your entire web root so that is really problematic. But, at the point that your executing random subsell strings typed in by the user with out sanitation you kind of deserve to get bashed anyways.
Can anyone think of a better use case where proper security measures still lead to a wide open security flaw due to this bug?
Debian and ubuntu have been patched by the security team 4 hours ago (more or less when this article has been written).
This is bad. The reason is lots of things that use bash put unchecked data into environment variables.
As an example, imagine some cgi wants to test is a string is valid, and somebody wrote a clever bash script that does this check, and reads the string by looking in $INPUT. The cgi takes whatever the user typed on their web form, does setenv("INPUT", text) and then runs the bash script, which uses "$INPUT" at places it wants the text.
No matter how carefully written the bash script is, if the user can type "() { :;}; exploit" into the text field, it will run "exploit". There is no reason for the cgi to test for any syntax errors because that is the job of the bash script!
It seems hard to believe such a bug is possible. It appears that when setting an environment variable, if it is a function, it runs some code that splits the text at semicolons, puts the first section in the environment variable, then runs the rest as shell input! But I can't figure out any reason such code exists. I thought at first it was pasting "export " on the start of the environment line and executing that using the interpreter, but tests show that does not work because it splits at the spaces. And if you add quoting to fix that then it also fixes the semicolon. And it obviously examined the environment variable to see if is a function, because semicolons in non-function ones are handled correctly. So I think bash code might be quite a mess for such a bug to be possible without much more obvious bugs happening...
That's good. The version number means nothing since Debian backported the fix rather than upgrading bash completely, but the check above didn't say vulnerable so you're clear.
F21 alpha boot.iso release was vulnerable reporting:
vulnerable
this is a test
after yum updqate to bash.x86_64 0:4.3.22-3.fc21
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
If you write network facing code, you _always_ clean your environment before calling system() or any similar calls. Properly written CGI scripts are not vulnerable. On the other hand, there's a lot of CGI crap out there ...
Thank you, sir. Good job to Debian team on releasing the fix!
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
...is supposed to be secure....unlike windows.
sudo aptitude update;
sudo aptitude safe-upgrade;
done.
Uh, Linux geek since 1999.
cgi scripts or binaries are remote vulnerable.
I have a CentOS build from April 2011 and it seems to be immune to the attack. When was the faulty code added and and by who?
If you bother to read the referenced article you'd notice For the stable distribution (wheezy), this problem has been fixed in
version 4.2+dfsg-0.1+deb7u1.. Yawn.
Am I wrong but that this exploit only works if you are running CGI scripts? Am I also wrong in thinking that if you are running PHP as an Apache Mod that this exploit doesn't work unless you are executing command line stuff?
Also the SSH aspect seems to be more of a privilege problem whereby someone has to have a valid ssh account before they can start hacking?
I am going to go out on a limb and say, if you are using CGI you are a dumbass and if you give anyone who you can't trust with ssh then you are also a dumbass. I don't think that I have configured a CGI serving machine since last millennia (literally).
Would something like this work? "avoir && ln -s /usr/bin/whoami /usr/bin/quisuis-je && quisuis-je"
Example attacks are listed on Red Hat's security blog.
Remember the HTTP_* variables set by the web server that calls the cgi program? Yep, you got it. Yes, they're a viable vector.
Also many many other programming languages, C, perl, etc. over call another programs, such as 'ping', 'nslookup' via bash. Basically because they don't want to re-implement things already done!
Not just Linux, but all UNIX with the affected bash. BSD, Solaris, MacOSX, etc. Probably even Windoze if you have Cygwin installed??
I'm sorry, I've meant to link to http://seclists.org/oss-sec/20... (you may want to walk the thread up a bit) and https://bugzilla.redhat.com/sh...
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
While bash is by far my favourite UNIX shell, I've seen various bits of evidence that have indicated a need for major refactoring, for quite a while now. I would look into it myself, but there is always the risk that whatever changes I proposed would be rejected. Perhaps I should think about creating a fork, although that would be a lot of work.
We've created the first batch of Sagan (log analysis engine - http://sagan.io) signatures to detect this. This monitor bash history and Apache logs for attempts. More information can be found at:
https://groups.google.com/forum/#!topic/sagan-users/Z8GEj20b0K4
Apache:
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORT (msg:"[APACHE] Remote execution attempt via CVE-2014-6271"; content:"|28 29| { |3a 3b|}"; program: apache|httpd; classtype: exploit-attempt; flowbits: set, exploit_attempt, 86400; parse_src_ip: 1; fwsam: src, 1 day; reference: url,wiki.quadrantsec.com/bin/view/Main/5002180; reference: url,web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271; sid:5002180; rev:3;)
Bash:
alert syslog $EXTERNAL_NET any -> $HOME_NET any (msg:"[BASH] Remote execution attempt via CVE-2014-6271"; content:"|28 29| { |3a 3b|}"; content: "HISTORY"; program: bash|-bash; classtype: exploit-attempt; flowbits: set, exploit_attempt, 86400; reference: url,wiki.quadrantsec.com/bin/view/Main/5002179; reference: url,web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271; sid:5002179; rev:1;)
That is because the higher level commands over to more error checking and handle more exceptional conditions that the low level library calls! It makes sense to use a higher level function that (gets improved with time) than to use the low level function that you need to 'maintain' when problems and exceptions arise.
This is the same reason why people use 'co-processing using a command like "mysql" instead of using a mysql API library.
1/ if the library updates, you need to recompile things, where commands are often more stable, and backward compatible.
2/ the command does the error checking.
3/ you typically only need to do minor lookups and not full blown database modifications
4/ you don't need to be an 'expert' (DBA) to use the simplier command.
Just having Bash installed does not make a system vulnerable. In order for the system to be vulnerable you also need to provide a method for a remote party to pass an environment string to the Bash shell. This would typically be handled via CGI when the web server hands GET and POST data via an environment variable to a Bash script. I do not believe Apache call to Bash for launching a Perl based CGI script so the global attack surface should be pretty small. I do not think I have seen a Bash CGI script since the 90's.
-rd
No.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I ran the two test scripts, and one said 'busted'. Then I ran apt-get update;apt-get upgrade (ubuntu), and then re-ran the scripts. And now instead of saying busted, it says: warning: X: ignoring function definition attempt, and error importing function definition for `X'.
So I was vulnerable for a few minutes, and now not.
Hello time traveller... you are welcome in my time, or any time for that matter...
(bash cgi's? what is this? 1996?)
Don't you also need to have a possibility for someone to inject Bash functions and run their environment definition?
Which systems let remote users do that?
Umm, no. Lots of CGI scripts of any denomination will spawn shells to run shit. Doesn't matter what you write it in if you spawn off any subshells and happen to be using bash.
Does this mean that you can attack over say DHCP/dhclient? Can I root my android phone using this?
Only if the language allows you to set environment variables to arbitrary values.
How can you have a remote vulnerability in something that doesn't listen on the net in the first place?
As for using shell scripts for CGI - yeah, we did that 15 years ago, and we knew back then that it was a stupid thing to do, because writing a secure shell script is virtually impossible. Just one variable that isn't perfectly quoted, and script injection becomes easy. If you're still doing that, that's your remote vulnerability, not bash itself.
So, how about a local privilege escalation exploit? Nope, bash is not setuid (if it is, you've got bigger problems), so this cannot give users access to anything that their own user id doesn't already have access to. Any modern unix ignores the setuid bit for shell scripts and su and sudo set up a new environment before calling anything. If you have anything that give elevated access to a shell script without doing the same, that's your problem. Just like the bash as cgi above, if you do that you already have problems without this bug.
I fail to see the vulnerability. People who are already doing something stupid with bash now have 101 problems where before they only had 100, but why would they care more about this problem than the rest? I'm not going to worry, I'm sure I'll get an update in a few days when the bug has been fixed for real, but as it's not a bug I've ever hit, and no way it's going to affect my security, I will take no further action.
Look, there is a bug, obviously, but to say that it is "remotely exploitable" is a half-truth, and that it is "on level with or worse than heartbleed" is nonsense.
There are a lot of things that need to "line up" in order for this to be remotely exploitable.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
It seems that the Hiawatha webserver is not vulnerable for this exploit, because it doesn't URL decode environment variables. Wise decision (CGI's seem to work fine without it) or just luck? Is there a standard which says that CGI environment variables should be URL decoded?
It doesn't have to be like this. All we need to do is make sure we keep talking.
% ksh :;}; echo vulnerable' bash -c "echo this is a test"
$ env x='() {
vulnerable
this is a test
$ echo $KSH_VERSION
@(#)PD KSH v5.2.14 99/07/13.2
Any cgi that calls bash with user-supplied arguments, right? Not an expert on this, but I would think you would be very careful allowing anything remotely user-supplied into a system() call.
A system() call calls /bin/sh by default; /bin/sh might not be bash.
Also, a non-string argument to system bypasses the shell completely in many programming languages. Try system('/bin/echo', '$SHELL') in Perl for example.
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...
I was explaining it to someone (co worker) yesterday as the vulnerability is there, but there needs to be an attack vector open as well. My demo to him was on an SGI system running IRIX - Bash was vulnerable, but without AccetEnv in SSH being enabled or something like Apache CGI the exploit can't be used.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Earlier this week, there was much cursing in Ft. Meade. Today, there is much cackling in Calgary.
A blog (a truncation of the expression web log) is a discussion or informational site published on the World Wide Web and consisting of discrete entries ("posts") typically displayed in reverse chronological order (the most recent post appears first).
wietlówki led
Monitoring Pojazdów
sprawozdanie finansowe
System ERP
przepywy pienine
NAVISION consolidation
That would work so long as your yum repos weren't already pwned ...
Don't have nightmares now!!
Even if they fix the basic bug, which is that functions are exported as environment variables, but the function can be trailed with extra commands, the whole idea seems extremely dangerous to me. What if you define a function called ls or cp or some other common command? It's pretty likely something will call it, and the whole problem is back in play.
The bigger problem to me seems to be that cgi scripts export user parameters to environment variables before calling bash. I mean, bash itself as a cgi web handler seems incredibly dangerous already. Too powerful for this application. But to then have unvetted user defined environment variables? This is insane. There's plenty of blame to go around here.
Not updated in Debian Squeeze yet, though.
My other account has a 3-digit UID.
CMD.EXE -- bulletproof!
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
/bin/sh is frequently a symlink to /bin/bash
# ls -alh /bin/sh /bin/sh -> bash
lrwxrwxrwx. 1 root root 4 Sep 24 12:47
Phones don't run bash so probably none. For better or for worse almost no embedded system uses bash, they have more basic shells or in android's case a custom barefuly functioning shell.
It also affects bash scripts called from programs run by CGI, so e.g. Perl, python, C, C++ programs using system(). Since environment variables are inherited by all subprocesses, it affects grandchildren, greatgrandchildren, and all the other sub-processes that get created all the way down.
Some scripting and programming languages use the shell to expand "glob" patterns, e,g,
$names = glob( "/tmp/[0-9]*" )
or in other places where it may not be obvious.
I'm not interested in comparing numbers of holes in different systems as it ony takes one hole for an intruder to get in.
Live barefoot!
free engravings/woodcuts
Has anyone traced back for how long this vulnerability existed..?
When I execute: env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
on ksh under Sco unix 5.0.7 - it outputs vulnerable
I'm not sure if ksh on other platforms would also be vulnerable (probably)
I'm sorry, I overstated the issue. The command I typed still only exposes the issue in the bash program, not the ksh program. Setting the x=.... function and then invoking bash is an issue, but if you run: env x='() { :;}; echo vulnerable' ksh -c "echo this is a test"
you don't see vulnerable, I'm sorry for the confusion.
My Cygwin is:
user@myComputer ~ :;}; echo vulnerable' bash -c "echo this is a test"
$ env x='() {
vulnerable
this is a test
user@myComputer ~
$
ALL iPhones ship with bash, no? (i noticed Apple pushed out 8.0.2 update for iOS this afternoon...)
At least for RedHat/CentOS, CVE-2014-7169 has been patched now as well. https://rhn.redhat.com/errata/...
"The (ancient) version of bash that ships with OS X appears vulnerable."
Some really ancient versions of OSX shipped not bash but tcsh, which was (is?) the NetBSD default shell. So who's going to write the anti-bash rebuttal to the famous "Top Ten Reasons not to use the C shell": http://www.grymoire.com/unix/C...
Nope can't find any evidence that iPhones ship with a full bash install, but they do have the capability to run some bash commands.
"When information is power, privacy is freedom" - Jah-Wren Ryel
IIF the CGI script is bash based... and WTF do you mean by "binaries" ?
-- 29A the number of the Beast