CVE-2014-6271: Remote Exploit Vulnerability found in BASH

Seen something interesting in the news or on the intertubes? Discuss it here.

Moderators: Zamfir, Hawknc, Moderators General, Prelates

KnightExemplar
Posts: 5494
Joined: Sun Dec 26, 2010 1:58 pm UTC

CVE-2014-6271: Remote Exploit Vulnerability found in BASH

Postby KnightExemplar » Thu Sep 25, 2014 12:35 am UTC

I have no idea how it works, but it sounds bad. Update your servers everyone!

http://seclists.org/oss-sec/2014/q3/650

For those who aren't system administrators, this is a worst-case scenario for Linux. Bash is the most common "shell" (command line) for Linux. Now... there are some restrictions on how the vulnerability works, but this basically blows a hole in any CGI script on a BASH based system. (including Debian, Ubuntu Red Hat, Fedora...). The primary concern is that all CGI scripts (including many PHP, Python and Ruby configurations) are vulnerable. Fortunately, my personal server uses FastCGI for PHP, so I should be good. Nonetheless, I updated BASH to get rid of this as soon as I heard about it.

ycombinator has a very good thread going on right now: https://news.ycombinator.com/item?id=8361574.

In the worst case, your system is vulnerable to something as simple as:
https://news.ycombinator.com/item?id=8361813
mmastrac 9 hours ago | link | parent | flag

Oh damn:

curl -H 'User-Agent: () { :;}; echo; echo vulnerable to CVE-2014-6271' <shell script CGI URL>

Tested and working against a shell script CGI.


Fix it today with "aptitude update / aptitude upgrade" or however your distribution handles upgrades. It looks like the response has been pretty quick and within hours a fix has been pushed to all major distributions I follow. Still, you need to go in there and update your systems, this is a big one. As stated in the ycombinator thread, if you don't understand what is going on... and if you are responsible for any Linux based system right now... your job is to update Bash ASAP.

Run the following inside of Bash:

Code: Select all

  env x='() { :;}; echo vulnerable' bash -c "echo this is a test"


If "vulnerable" is printed, update Bash immediately.
First Strike +1/+1 and Indestructible.

Derek
Posts: 2181
Joined: Wed Aug 18, 2010 4:15 am UTC

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby Derek » Thu Sep 25, 2014 8:32 am UTC

Windows is not the most secure OS, on account of having a shell that's just that anemic.

Of course, I've got MSYS installed, so strictly speaking I'm still vulnerable.

KnightExemplar
Posts: 5494
Joined: Sun Dec 26, 2010 1:58 pm UTC

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby KnightExemplar » Thu Sep 25, 2014 1:05 pm UTC

Here's an excellent article describing the issue: http://www.troyhunt.com/2014/09/everyth ... about.html

On a scale of 0 to 10 (where 10 is Heartbleed), "Shellshock" scores a 20. Heartbleed didn't let you execute arbitrary code on a remote server. Shellshock does. Heartbleed only affected https connections. Shellshock has already proof-of-concept code against HTTP, HTTPS, DHCP, SMTP, and SSH (albet a very restricted form of SSH, but SSH proof of concept nonetheless). This is going to be one of the biggest vulnerabilities to hit the Linux community for years.

Basically, Heartbleed was a critical information leak attack where hackers could potentially steal your SSL Certificates. Shellshock is a critical remote execution attack, where hackers can execute whatever code they want on your system (including just... grabbing your SSL certificates... or deleting them... or... yeah...)

This is definitely a bigger deal than Heartbleed.

Derek wrote:Windows is not the most secure OS, on account of having a shell that's just that anemic.

Of course, I've got MSYS installed, so strictly speaking I'm still vulnerable.


Technically, yes.

But Windows is the only safe OS. Even Mac OSX uses Bash, so the attack surface of this vulnerability is absolutely staggering in scope.

The main issue is when you have bash hooked up to the web somewhere. Windows won't spawn a bash shell if you execute a "system" call or "popen". Mac OSX and Linux will, and as soon as that happens your computer / server is completely pwned.

-----------------

Furthermore, people are finding out that the patch last night was incomplete. Everyone is still vulnerable and no patch is in sight to completely fix the problem. :cry: :cry:

System Administrators are going to have to stay on top of this one and update regularly until all the Bash bugs are figured out. At this point, people are recommending that you switch shells because its so bad. ("dash" as a replacement). No doubt, switching shells away from Bash is going to take a major testing effort for production code.

People have switched out bash for performance reasons. Here's an article for switching to dash on Debian / Ubuntu.

http://lowendbox.com/blog/replacing-big ... scripting/

This minor performance enhancement can close the hole on any Bash vulnerability. Might as well do it.

-------------

Security researchers are figuring out just how absolutely massive this bug is in scope.

http://www.theinquirer.net/inquirer/new ... heartbleed
"Conservatively, the impact is anywhere from 20 to 50 [percent] of global servers supporting web pages. Specifically, this issue affects web servers using GNU bash to process traffic from the internet. In addition, this bug covers almost all CGI-based web servers, which are generally older systems on the internet."
First Strike +1/+1 and Indestructible.

Derek
Posts: 2181
Joined: Wed Aug 18, 2010 4:15 am UTC

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby Derek » Thu Sep 25, 2014 3:39 pm UTC

The remarkable thing is that the exploit is just so obvious/dumb. When defining a function in an environment variable, the interpreter just keeps running after the function is over execute whatever other code there is. Literally anyone with Bash experience could construct an exploit for this. It seems remarkable that no one has ever found this before.

User avatar
Xenomortis
Not actually a special flower.
Posts: 1456
Joined: Thu Oct 11, 2012 8:47 am UTC

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby Xenomortis » Thu Sep 25, 2014 3:56 pm UTC

Seems this bug is 22 years old (bash 1.13).
That's almost as old as me.
Image

User avatar
tetsujin
Posts: 426
Joined: Thu Nov 15, 2007 8:34 pm UTC
Location: Massachusetts
Contact:

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby tetsujin » Thu Sep 25, 2014 9:02 pm UTC

After taking the time to understand this bug... Man, it is just so stupid.

Bash supports user-defined functions, and it allows you to export them as part of the environment. As a result, when Bash starts up and sees a variable in the environment whose value is function syntax, it tries to interpret it as a function. I haven't even described the part that's the bug yet, and already this strikes me as incredibly hokey. Like what if I just wanted to store "() { command; }" as an environment variable and export it? Can't do it, because the next instance of Bash will think that's a function.

(That's just the "feature", of course. The bug is that when Bash sees one of those function definitions, it parses it to the end, and then executes whatever's left over...)

Combined with the fact that almost anything a shell script will ever store is likely to go straight into the environment somewhere, it's easy to see how an injection attack could work on almost anything using bash. It's kind of sad that this is likely to reflect very badly on Unix as a whole.

(I love the Unix shell, but things like this - not the bug itself so much as the feature which lead to the bug - really make me wonder about Bash sometimes.)

Derek wrote:The remarkable thing is that the exploit is just so obvious/dumb. When defining a function in an environment variable, the interpreter just keeps running after the function is over execute whatever other code there is. ... It seems remarkable that no one has ever found this before.


The trick is that, in Bash, you actually can't "define a function in an environment variable", Bash doesn't support that. But if you define a function in Bash and export it, Bash will stuff it into an environment variable in the new process. And when Bash starts a new instance, any environment variables that look like functions will become functions.
Spoiler:

Code: Select all

$ hello() {echo 'hi!'; }
$ hello
hi!
$ export -f hello   # Function hello will be made part of the environment when we launch a new process
$ bash              # Start another bash instance to see how function exporting looks:
$ hello              # Function exporting works...
hi!
$ echo $hello    # ...and $hello is not considered a variable in the current shell, however...

$ printenv hello    # Launch a new process, not Bash and print $hello from its environment to see how Bash exports the function
() {  echo 'hi!'
}
$


It is indeed somewhat troubling that nobody found this in 20 years - but even though this mechanism uses the environment, under normal circumstances Bash users wouldn't see it. Within Bash, variables and functions have separate namespaces. If you export them and start a new instance of Bash, behind the scenes they'll all be stuffed into the environment, but then in the new instance of Bash each will wind up back in its respective namespace. When the mechanism is working properly, it's invisible, until you run something that isn't Bash. I think a lot of Unix shell users aren't familiar enough with it to think about how function exports work.
Last edited by tetsujin on Thu Sep 25, 2014 9:34 pm UTC, edited 1 time in total.
---GEC
I want to create a truly new command-line shell for Unix.
Anybody want to place bets on whether I ever get any code written?

User avatar
rath358
The bone of my bone
Posts: 945
Joined: Wed Jan 14, 2009 6:02 am UTC
Location: west Camberville

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby rath358 » Thu Sep 25, 2014 9:20 pm UTC

I wonder if it would be possible to seriously make an impact by writing a worm to patch vulnerable systems.

mousewiz
Posts: 107
Joined: Wed Oct 26, 2011 6:50 pm UTC

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby mousewiz » Thu Sep 25, 2014 10:13 pm UTC

rath358 wrote:I wonder if it would be possible to seriously make an impact by writing a worm to patch vulnerable systems.

Three things:
1) I bet some malware author will do exactly that. Except that they'll be doing to stop others from interfering with their worm, and not for benevolent purposes. This is far from unheard of.
2) I bet they'll be in a better position to spread their worm than a white hat (due to spreading worms all the time)
3) That is actually a thing that people have done; I don't think it's been typically well received because: poor implementations can cause all sorts of issues, it wastes the resources of people having to confirm with certainty that your worm isn't a threat, it's easy for someone to take your worm and add their own payload to it...

Mutex
Posts: 1492
Joined: Wed Jan 09, 2008 10:32 pm UTC

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby Mutex » Thu Sep 25, 2014 10:41 pm UTC

rath358 wrote:I wonder if it would be possible to seriously make an impact by writing a worm to patch vulnerable systems.


I like the idea of a worm that updates the systems it infects so they're no longer vulnerable to the worm.

User avatar
rath358
The bone of my bone
Posts: 945
Joined: Wed Jan 14, 2009 6:02 am UTC
Location: west Camberville

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby rath358 » Thu Sep 25, 2014 10:50 pm UTC

mousewiz wrote:
rath358 wrote:I wonder if it would be possible to seriously make an impact by writing a worm to patch vulnerable systems.

Three things:
1) I bet some malware author will do exactly that. Except that they'll be doing to stop others from interfering with their worm, and not for benevolent purposes. This is far from unheard of.
2) I bet they'll be in a better position to spread their worm than a white hat (due to spreading worms all the time)
3) That is actually a thing that people have done; I don't think it's been typically well received because: poor implementations can cause all sorts of issues, it wastes the resources of people having to confirm with certainty that your worm isn't a threat, it's easy for someone to take your worm and add their own payload to it...

I know it was done in the past, but not particularly surprised that it is no longer frequently done.

Sheikh al-Majaneen
Name Checks Out On Time, Tips Chambermaid
Posts: 1075
Joined: Fri Jan 01, 2010 5:17 am UTC

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby Sheikh al-Majaneen » Thu Sep 25, 2014 11:39 pm UTC

I switched my linux computers' shells to zsh (something I intended to experiment with months ago, but hey motivation), since it appears that even after the recent patch bash can still be exploited.

Now I'd like to make bash require superuser permissions, but...not entirely sure how.

Not that I run a server. It just seems like a good idea.

User avatar
chridd
Has a vermicelli title
Posts: 846
Joined: Tue Aug 19, 2008 10:07 am UTC
Location: ...Earth, I guess?
Contact:

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby chridd » Fri Sep 26, 2014 2:31 am UTC

Sheikh al-Majaneen wrote:Now I'd like to make bash require superuser permissions, but...not entirely sure how.
...so that anyone exploiting the bug will be exploiting it when bash is being run as superuser (and thus get superuser access)?

I have no idea whether this will cause any problems (some programs, possibly important ones, might require bash), but if you want to do it anyways, I believe the command to do that would be

Code: Select all

sudo chmod go-x /bin/bash
You'll probably want to make sure that /bin/sh points to a compatible shell.

(Also, odd, and off topic: why does my computer (Mac OS X) have a separate /bin/sh executable that has a slightly different file size than /bin/bash, when both are the same version of bash according to bash --version / sh --version?)
~ chri d. d. /tʃɹɪ.di.di/ (Phonotactics, schmphonotactics) · she · Forum game scores
mittfh wrote:I wish this post was very quotable...

Mutex
Posts: 1492
Joined: Wed Jan 09, 2008 10:32 pm UTC

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby Mutex » Fri Sep 26, 2014 12:46 pm UTC

chridd wrote:(Also, odd, and off topic: why does my computer (Mac OS X) have a separate /bin/sh executable that has a slightly different file size than /bin/bash, when both are the same version of bash according to bash --version / sh --version?)


In the versions of Linux I've used, /bin/sh has been a symlink to /bin/bash or whatever shell is default (dash in Ubuntu, does Ubuntu still use dash instead of bash?).

So yeah, weird that sh is an actual executable in your OS.

gnutrino
Posts: 100
Joined: Sat Sep 06, 2008 9:02 am UTC
Location: Over the edge...

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby gnutrino » Fri Sep 26, 2014 5:36 pm UTC

Soooo.... anyone know of any good resources for someone looking to migrate to zsh?

User avatar
tetsujin
Posts: 426
Joined: Thu Nov 15, 2007 8:34 pm UTC
Location: Massachusetts
Contact:

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby tetsujin » Fri Sep 26, 2014 10:36 pm UTC

gnutrino wrote:Soooo.... anyone know of any good resources for someone looking to migrate to zsh?


What do you want to know about it exactly? Just using it, or are you looking to use it for scripting as well?

I probably won't have the answers to your zsh questions, but I'm interested in these sorts of things...
---GEC
I want to create a truly new command-line shell for Unix.
Anybody want to place bets on whether I ever get any code written?

Sheikh al-Majaneen
Name Checks Out On Time, Tips Chambermaid
Posts: 1075
Joined: Fri Jan 01, 2010 5:17 am UTC

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby Sheikh al-Majaneen » Sat Sep 27, 2014 4:18 am UTC

gnutrino wrote:Soooo.... anyone know of any good resources for someone looking to migrate to zsh?

rtfm (not that I have): http://zsh.sourceforge.net/Doc/zsh_a4.pdf

also: http://linuxg.net/how-to-install-zsh-sh ... gin-shell/

chridd wrote:
Sheikh al-Majaneen wrote:Now I'd like to make bash require superuser permissions, but...not entirely sure how.
...so that anyone exploiting the bug will be exploiting it when bash is being run as superuser (and thus get superuser access)?

What could POSSIBLY go wrong?

Actually, realizing that on the drive home is what made me reconsider.
Last edited by Sheikh al-Majaneen on Sat Sep 27, 2014 11:58 pm UTC, edited 1 time in total.

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6598
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby Thesh » Sat Sep 27, 2014 6:16 am UTC

gnutrino wrote:Soooo.... anyone know of any good resources for someone looking to migrate to zsh?


It's not that difficult. "chsh -s /bin/zsh" and then it will open a settings window. I highly recommend adding one of these to your .zshrc:

http://zshwiki.org/home/zle/bindkeys

All that said, I love zsh, but it doesn't necessarily protect you from this vulnerability; a program may explicitly invoke bash or /bin/sh, and unless you remove them and make symlinks to zsh (which may break your entire system, I do not recommend) they may cause problems. That said, you are not necessarily vulnerable to this anyway; unless you are running a service that calls the shell and passes environment variables, this really isn't that big of a deal.
Summum ius, summa iniuria.

KnightExemplar
Posts: 5494
Joined: Sun Dec 26, 2010 1:58 pm UTC

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby KnightExemplar » Sat Sep 27, 2014 3:47 pm UTC

Thesh wrote:All that said, I love zsh, but it doesn't necessarily protect you from this vulnerability; a program may explicitly invoke bash or /bin/sh, and unless you remove them and make symlinks to zsh (which may break your entire system, I do not recommend) they may cause problems. That said, you are not necessarily vulnerable to this anyway; unless you are running a service that calls the shell and passes environment variables, this really isn't that big of a deal.


All setuid Bash scripts are nasty root escalation vulnerabilities with this. It isn't a remote execution bug, but it'd be a big deal even on client systems. Root Escalations are serious business.

I don't know if any setuid bash script exists on Mac OSX, but I'd imagine that some exist on a lot of Linux systems. Rather than try and figure that out... I'd recommend that you take this seriously. Even if you aren't running a server.
First Strike +1/+1 and Indestructible.

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6598
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby Thesh » Sat Sep 27, 2014 4:08 pm UTC

I haven't seen anything about this leading to privilege escalation. The new shell would be running under the same privileges as your account.
Summum ius, summa iniuria.

KnightExemplar
Posts: 5494
Joined: Sun Dec 26, 2010 1:58 pm UTC

Re: CVE-2014-6271: Remote Exploit Vulnerability found in BAS

Postby KnightExemplar » Sat Sep 27, 2014 4:16 pm UTC

Thesh wrote:I haven't seen anything about this leading to privilege escalation. The new shell would be running under the same privileges as your account.


I didn't say all Bash scripts, there's an important word in there...

All setuid Bash scripts


http://en.wikipedia.org/wiki/Setuid

To be fair, setuid Bash scripts are considered extremely insecure already, but that doesn't change the fact that a significant number of systems have something set as setuid... and just one of those programs need to call popen, bash, or system for a major vulnerability to occur.

Code: Select all

# ls -laFh /usr/bin/sudo
-rwsr-xr-x 2 root root 111K Mar  1  2013 /usr/bin/sudo*


Oh, look at that. "sudo" is running setuid (notice the "s" in the permissions flag)... in particular all instances of "sudo" run as root. And... sudo probably opens bash... fuck.

Not that I've tested this (that'd require me to downgrade my bash to something insecure...), but you can get the gist of the issue here.
First Strike +1/+1 and Indestructible.


Return to “News & Articles”

Who is online

Users browsing this forum: No registered users and 20 guests