Hacker News Reader

Comment by pilif | Hacker News Reader

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 :(

View on HN

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.

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

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".

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.

Reply on news.ycombinator.com