Quick notes about the bash bug, its impact, and the fixes so far | Hacker News Reader

Quick notes about the bash bug, its impact, and the fixes so far

lcamtuf.blogspot.com

164 pointsrobin_reala25 comments

This is a perfect example of why you should never, ever put special magical values in-band with a facility which has a different purpose normally.

I know it's tempting and in many cases, it will save you a lot of work, but it will eventually lead to data corruption, or, way worse, a problem like this one here.

People in the office complain about my annoyed remarks when they succumb to the dark side and use some special values. My question "but what if a real value is ever sent that looks like one of these magic values?" is usually countered with "but who's ever going to send this value?".

This bug here is providing me with a perfect answer to that question: "Security researchers, or worse, bad guys".

There are so many ways of transferring functions to subshells that don't involve magic values in a free-form key/value store, but all of them would have been more complicated, so people chose the quick hack.

And now the sh*t has hit the fan :(

Like Terminal escape sequences? ;)

(On an old SunOS machine in uni back in the day I could create files that changed the colour of ls output. The very same mechanisms sometimes also allow you to redefine keys, depending on the terminal.)

:) Years ago a colleague carefully crafted an ASCII escape sequence for VT320 terminals that would mess up the screen and program a function key to send a network-wide broadcast message.

He sent a note to an admin... something like: "This is cool. If the screen gets messed up, just hit Shift-F12." Everyone on the network received a broadcast message: "I've been had." Obviously, it could have been a lot worse.

> And now the st has hit the fan :(

And now the sh has hit the fan :(

there we go - another example of my point :p

chroot-ing your network-exposed services isn't a bad idea either. Assume they'll be exploited at some point, and contain the potential damage.

Also blocking outbound requests from publicly accessible servers (i.e. from a public web server, it should be hard to make an outbound request to fetch more stuff to install).

Probably a good idea to check that tripwire is installed/configured/monitored in all the right places.

In many ways UNIX is built on the philosophy of keeping everything in-band and leaving it up to processes what they do with their inputs. Specifically, "everything is a file" vs "everything is an API".

My question "but what if a real value is ever sent that looks like one of these magic values?" is usually countered with "but who's ever going to send this value?"

Have experienced the same situation so many times with CSV... "Who's ever going to have a doublequote in their name?" At least there is an escaping facility in most formats.

I haven't seen any "how this was discovered" for the bash bug, but my bet is that someone needed to store "() {" in an environment variable in a shell script. It's not inconceivable - the first thing that comes to mind is a shell script that generates shell script functions.

I'd say the problem is more that they chose to use the name of the function as the name of the environment variable; this would not have been an issue if it stuffed all the function definitions together in an environment variable with a special name, like BASH_FUNCS. Shells already interpret environment variables with special names in certain ways (e.g. PS1, PROMPT_COMMAND), up to and including command execution, so this way would fit with that model far better.

I was just looking at http://stackoverflow.com/a/941390/2517719 on monday, and I completely missed the implications.

Reminds me of this:

"Nobody really knows what the Bourne shell's grammar is. Even examination of the source code is little help." — Tom Duff

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41....

Sounds like a time-bomb for exploitable unexpected behavior.

It's so cute when people ridicule superior engineering like plan 9 while they wallow in the incredible quagmire of so-called pragmatic systems.

I wonder how many people are relying on this behavior for their production systems.

It can't be zero.

I wonder how many people knew about this behavior a week ago.

> Ree88. J. Reeds, ‘‘/bin/sh: the biggest UNIX security loophole,’’ 11217-840302-04TM, AT&T Bell Laboratories (1988).

Do you have a copy of or link to that article? Or are you just pasting a citation with a cute title? I have stumbled across that citation a couple of times but I have never been able to find it.

Someone really needs to interview Stephane Chazelas and ask them how the heck they found this flaw in the first place (after 15 years).

I thought the patch wasn't that effective? Is there a PoC that runs on a patched system anymore?

Edit: found one https://news.ycombinator.com/item?id=8365216

So has a new patch come out? I hacked up a temporary patch that fixes this last night after the new PoC was released, but I'd rather have something from upstream.

There is an unofficial patch that takes a much more reasonable approach:

http://www.openwall.com/lists/oss-security/2014/09/25/13

So only servers actually executing bash with input from browser (cookies etc) are affected (like CGI)?

Plus any DHCP client that runs shell scripts using parameters from The Evil DHCP Server, for example.

Could we fork bash to make this "feature" configurable?

Replying to myself just to point bash doesn't seem to be up to date in the "official" repository at gnu.org. Are distros maintaining their own forks?

Distros typically maintain a set of their own patches that go on top of the officially released source.

Reply on news.ycombinator.com