LWN: Comments on "A remotely exploitable hole in bash"

A remotely exploitable hole in bash

k8to — Sun, 05 Oct 2014 04:39:10 +0000

Yeah I was thinking of AIX where there is no unsetenv.

A remotely exploitable hole in bash

mathstuf — Mon, 29 Sep 2014 17:05:38 +0000

> …a decent unsetenv.

FTFY :) . Apparently some implementations just unset the first instance of the variable in the environment, not all of them.

A remotely exploitable hole in bash

k8to — Mon, 29 Sep 2014 11:08:19 +0000

good thing you're on a platform that supports unsetenv :-D

A remotely exploitable hole in bash

nye — Mon, 29 Sep 2014 10:55:37 +0000

>> There is no other interface that is anywhere near as easy to use.
>There is no doubt that insecure is always more convenient, actually most of the time insecure is *much* more convenient. The question was: how many more security scandals are required before secure coding starts being seriously rewarded and laziness punished by the market place? No simple answer I'm afraid.

Imagine the alternative: that there is no standardised way to pass variables across processes and every program needs to implement its own custom parser. That would be a nightmare, and you'd be making pretty much the same complaint, probably suggesting that the only sensible thing to do is to have it done exactly as it is now, so that the parsing is implemented in one shared implementation.

You're a very judgemental person, but in the real world it's likely that anyone reading code you've written would be bitching just as much about your scandalous laziness.

A remotely exploitable hole in bash

nye — Mon, 29 Sep 2014 10:34:59 +0000

>$ export A='() { echo "My func"; }'
>$ bash
>$ A
>My func
>$ echo $A
>[nothing here]

$type A
A is a function
A ()
{
echo "My func"
}

>Thus make me think that way of the storage is implementation detail

Almost certainly. This behaviour looks exactly like if the function had been defined in the subshell in the traditional way - functions aren't variables, so variable substitution isn't a meaningful thing to do, but 'type' knows exactly what's up, and so does 'set'.

The implementation leaks slightly though, in that the definition is visible in the environment unlike a locally defined function.

A remotely exploitable hole in bash

mathstuf — Sun, 28 Sep 2014 18:29:37 +0000

> Stuff like FastCGI has traction in certain areas, but it's already much more complicated.

I've found using spawn-fcgi works really nicely for keeping CGI services in a separate jail from the webserver itself. So you can write your CGI program then just use the wrapper.

A remotely exploitable hole in bash

marcH — Sun, 28 Sep 2014 16:09:01 +0000

> There is no other interface that is anywhere near as easy to use.

There is no doubt that insecure is always more convenient, actually most of the time insecure is *much* more convenient. The question was: how many more security scandals are required before secure coding starts being seriously rewarded and laziness punished by the market place? No simple answer I'm afraid.

> Offhand I can't think of any other case of something being executed out of an environment variable. Most programs just look at the variables they're interested in and ignore the rest.

"Most" does not work a security perspective. All details here:
http://www.dwheeler.com/secure-class/Secure-Programs-HOWT...

A remotely exploitable hole in bash

kleptog — Sun, 28 Sep 2014 14:29:49 +0000

The CGI interface is still around because it happens to work really really well. It's allows the webserver to be flexible about which parameters it sends. The CGI script doesn't have to do any fancy parsing, because every parameter is just a getenv() away. It's supported by every programming language.

Offhand I can't think of any other case of something being executed out of an environment variable. Most programs just look at the variables they're interested in and ignore the rest. What bash is doing here (looping over variables to find those whose *value* match a particular pattern) is I think pretty rare.

There is no other interface that is anywhere near as easy to use. Stuff like FastCGI has traction in certain areas, but it's already much more complicated.

A remotely exploitable hole in bash

bronson — Sun, 28 Sep 2014 07:25:18 +0000

Not sure what you're arguing... Don't you remember all the breakage reports caused by the devfs removal? And Greg KH's unapologetic emails? (IMO rightfully so, good times) If not, no big deal, there are other user-visible deprecations to be found in feature-removal-schedule.txt.

Linux's backward compatibility is nothing short of stellar. It's part of what makes using Linux such a pleasure. But, on the rare occasion that a mistake is made, we don't have to live with it forever. It can be fixed.

A remotely exploitable hole in bash

raven667 — Sun, 28 Sep 2014 04:25:23 +0000

devfs may not be there but /dev certainly is which is the user facing API. There is no attempt at internal kernel API stability so how things get done are constantly in flux (devfs vs. udev vs. static /dev) but the syscall interface and even /proc and /dev are maintained so that old software can continue to run.

A remotely exploitable hole in bash

bronson — Sat, 27 Sep 2014 23:28:05 +0000

Nah, features get removed after deprecation periods, even in the Linux Kernel. Can you imagine being burdened with devfs forever?

A remotely exploitable hole in bash

marcH — Fri, 26 Sep 2014 23:51:15 +0000

After 5 seconds googling:

http://www.dwheeler.com/secure-class/Secure-Programs-HOWT...

A remotely exploitable hole in bash

sitaram — Fri, 26 Sep 2014 23:04:01 +0000

Yes it's blocking more than needed, but I don't see any of the needlessly blocked variants as being useful in real life so it doesn't matter.

A remotely exploitable hole in bash

foom — Fri, 26 Sep 2014 21:24:03 +0000

There is no way anyone would expect that passing arbitrary user data in the VALUE of controlled environment-variables would cause arbitrary code execution.

It is not "drunk" to expect that passing arbitrary values in controlled names is a perfectly reasonable thing to do.

I mean, same issue occurs with SSH -- it sets SSH_ORIGINAL_COMMAND to the command that the remote user presented to a restricted command. How could that be insecure?

*Clearly* nothing would be trying to eval that as code! That'd be insane!

A remotely exploitable hole in bash

raven667 — Fri, 26 Sep 2014 21:00:37 +0000

> had people generally realized that some people on the Internet were not going to be nice

That viewpoint was out there but wasn't a widely heeded, what we consider normal security engineering today would be considered high paranoia at the time. Packet-filtering firewalls were a new technology at the time and adding DMZs to networks was a radical new thing that people argued about. Having open SMTP relays was considered good form as well 8-)

> feedback I usually get to "get it done"

Yep.

Also passing data in environment variables is a very UNIX-y way to do things which was dominant at the time.

A remotely exploitable hole in bash

mpr22 — Fri, 26 Sep 2014 18:06:19 +0000

Remote exploits were (in principle) already a known thing, since the Morris worm was unleashed in 1988.

A remotely exploitable hole in bash

marcH — Fri, 26 Sep 2014 17:36:45 +0000

> It's easy to point fingers and say that they were stupid or did a bad job in retrospect with 20+ years of experience behind us

I think it all comes down to this: when CGI was invented (20 years ago already?!) had people generally realized that some people on the Internet were not going to be nice? This is a genuine question.

(Answering it might reveal your age, sorry)

> but it's harder to say that given the constraints of the system and the knowledge of the time that you wouldn't have made the same decisions given the same inputs.

Based on the beat... feedback I usually get to "get it done" I could still be reasonably optimistic :-)

More revelant: why the hell is CGI still in use in the same sorry state 20 years and a millions of (not related) security scandals later? OK: now I guess I just need to google "Worse is Better" and do some reading.

A remotely exploitable hole in bash

raven667 — Fri, 26 Sep 2014 17:03:20 +0000

This is the application of the "Worse is Better(tm)" principal, CGI is a very simple interface that existing systems of the day could easily support. It's easy to point fingers and say that they were stupid or did a bad job in retrospect with 20+ years of experience behind us but it's harder to say that given the constraints of the system and the knowledge of the time that you wouldn't have made the same decisions given the same inputs.

A remotely exploitable hole in bash

raven667 — Fri, 26 Sep 2014 16:59:52 +0000

> I don't see any way the benefit of the feature can outweigh all this effort.

This is an instance of what is a hard and fast rule in the kernel, "Don't Break Userspace(tm)" It doesn't matter how dumb the feature is in retrospect, it has to continue working even after you refactor the implementation, someone out there could be depending on it, probably without even being aware of it.

A remotely exploitable hole in bash

cesarb — Fri, 26 Sep 2014 16:35:06 +0000

That regexp seems underconstrained. From what I've read, the condition to trigger the vulnerability is the precise four characters "() {" at the beginning of the environment variable; any extra whitespace and bash treats it as a normal environment variable.

So it should probably be (untested): /^ \{/.

A remotely exploitable hole in bash

bronson — Fri, 26 Sep 2014 16:32:01 +0000

Still trying to fix it... First two fixes failed, this third one is in a gray area.

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

I don't see any way the benefit of the feature can outweigh all this effort.

A remotely exploitable hole in bash

marcH — Fri, 26 Sep 2014 15:08:35 +0000

So the CGI guys were even drunker.

A remotely exploitable hole in bash

gb — Fri, 26 Sep 2014 14:15:27 +0000

So bash, by putting multiple instances of the variable with same name into environment of the programs it run, forces that programs into undefined behavior state. Hm...
$ bash
$ f() { aaa; }
$ export -f f
$ export f=3
$ ksh
$ cat /proc/$$/environ |xargs -0 -n1|grep -w f
f=3
f=() { aaa
$ echo $f
3

For Debian users

dskoll — Fri, 26 Sep 2014 13:53:15 +0000

Debian users may be slightly better off than other distros if they've kept the default /bin/sh => dash symlink.

Also, the fix in DSA-3032 was not complete. New update is DSA-3035.

A remotely exploitable hole in bash

niner — Fri, 26 Sep 2014 11:41:16 +0000

It's not only running bash script through CGI. It's also every other CGI script that uses system() which may end up running bash.

A remotely exploitable hole in bash

marcH — Fri, 26 Sep 2014 11:30:12 +0000

> The CGI specification maps all parts to environment variables.

So, they were drunk.

Security rule number 1: sanitize your inputs. CGI's interpretation: let's dump all this random and unfiltered input into the highly sensitive process environment.

Like most accidents this is not caused by just one mistake but a combination of them. I'm still not convinced bash is the most to blame. People running bash scripts through CGI should definitely blamed too.

A remotely exploitable hole in bash

marcH — Fri, 26 Sep 2014 11:05:44 +0000

> Cool - hidden environment variables. Nice implementation detail.

Just found this in the standard:

http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html

"If more than one string in a process' environment has the same name the consequences are undefined."

A remotely exploitable hole in bash

sitaram — Fri, 26 Sep 2014 08:46:29 +0000

I took David Wheeler's quote to heart and added one more layer of indirection while the big boys figure out what is the correct patch.

Copy /bin/bash to /bin/oldbash, put this script in as /bin/bash, and fix up permissions:

    #!/usr/bin/perl
    # env safe bash
    use strict;
    use warnings;

    for (keys %ENV) {
        delete $ENV{$_} if $ENV{$_} =~ /^\s*\(\s*\)\s*\{/;
    }
    exec "/bin/oldbash", @ARGV;

A remotely exploitable hole in bash

gb — Thu, 25 Sep 2014 20:31:01 +0000

Thank you for the explanation... Just never thought about it.

A remotely exploitable hole in bash

proski — Thu, 25 Sep 2014 18:55:14 +0000

I would not say the patch for the original issue is buggy. It's a separate issue that requires a separate patch. The new issue doesn't involve passing functions through the environment. It is the parser recovery after invalid function definitions.

A remotely exploitable hole in bash

madscientist — Thu, 25 Sep 2014 18:15:48 +0000

The "environment" is just an array of nul-terminated strings. Each string is expected to have the form "NAME=VALUE"; so the name of an environment variable is the characters up to and not including the first equals sign. There's no reason that more than one of these strings can't have the same "NAME" part.

The typical functional API to the environment provided by C and other languages treats the environment as a set of key/value pairs, so using those functions it's usually not possible to have two variables with the same name. But, if you start a program with execve() for example you give your own list of strings as the environment for the child process, and the members of that list can be whatever you want.

A remotely exploitable hole in bash

gb — Thu, 25 Sep 2014 17:52:20 +0000

I reached full stop here. Never knew that it's possible to have two environment variables with same name.

A remotely exploitable hole in bash

gb — Thu, 25 Sep 2014 17:43:58 +0000

Cool - hidden environment variables. Nice implementation detail.

$ cat /proc/$$/environ |xargs -0 -n1|grep -w A
A=() { echo "My func"

$ env|grep -w A
A=3
A=() { echo "My func"

Means that if someone sets such function in HTTP or something.. you would never see it if you just do $ABCD, only if you do env|grep ABCD

A remotely exploitable hole in bash

raven667 — Thu, 25 Sep 2014 16:25:54 +0000

I'm not sure about that, you can instantly get a shell as the httpd user on any system running CGI that ever executes a sub-process. That's ripe for a worm. Additionally dhcpclient shells out to apply config statements received in a dhcp response, so if you can get in and run a rogue dhcp server, you can take over the workstations in a network as well.

A remotely exploitable hole in bash

raven667 — Thu, 25 Sep 2014 16:23:27 +0000

> this is only an issue if your CGI script is actually written as a bash shell script, right?

No, the way that the httpd passes any variables to the CGI is through the environment, which is inherited across sub-processes, so a CGI in any language that forks a shell due to running system() or `backticks` or implicitly as part of file globbing, even if you are just running a fixed command, is vulnerable.

A remotely exploitable hole in bash

gb — Thu, 25 Sep 2014 16:21:08 +0000

A funny thing that you can't detect this variables in your subshell:

$ export A='() { echo "My func"; }'
$ bash
$ A
My func
$ echo $A
[nothing here]
$ bash
$ A
My func [still???]
$ export A=3
$ bash
$ A
My func
$ echo $A
3

Thus make me think that way of the storage is implementation detail and it _may be_ backdoor since day 1 15 years ago.
And how does bash passed both A and My func to subshell here?

A remotely exploitable hole in bash

cortana — Thu, 25 Sep 2014 15:57:19 +0000

AIUI this allows anyone on the internet to inject code into the environment of any CGI script with something like:

> curl -H 'foo: () { evil; }' http://foo.example/cgi-bin/somebashscript

Now somebashscript has an attacker-supplied shell function, HTTP_foo. I am deeply uncomfortable with the fact that the script is only one typo away from running it. I would prefer this feature to be ripped out entirely, or at least disabled unless a script runs 'shopt -p terrifying_code_injection'.

A remotely exploitable hole in bash

foom — Thu, 25 Sep 2014 15:51:30 +0000

This feature should not exist. It's insane to be inspecting the values of arbitrary env vars for a special starting string.

If one actually WANTS to eval code from an env var, it's trivial to do so, either by setting BASH_ENV to point to a file you want run, or by starting your subscript with a call to 'eval "$BASH_EVAL_ME_FIRST"'. There's no need for it to be part of bash at all.

I'd really vote for simply killing this misguided "export -f" feature entirely.

But if not, the best way to implement this feature is probably to have bash itself call 'eval "$BASH_EVAL_ME_FIRST"' at startup, and have "export -f" simply append all exported functions into a shell script fragment in that one variable.

Then at least it's clear that allowing that variable to be set allows arbitrary code execution (like BASH_ENV being set to a filename does). Don't need to worry about parser vulnerabilities, or potentially overriding existing functions/binaries.

And it's unlikely that remote users will be able to set such a varible.

A remotely exploitable hole in bash

cortana — Thu, 25 Sep 2014 15:48:09 +0000

Out of interest--what do you use it for?

A remotely exploitable hole in bash

thedevil — Thu, 25 Sep 2014 15:28:00 +0000

I use it. Please do not remove it 8-0

If "sounds dangerous" was a reason not to use something, I don't think I'd be typing this now on my computer ...