4 ms·

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

by pilif 12y ago

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

ygra 12y ago
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.)
- cleaver 12y ago
  :) 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.
minikomi 12y ago
> And now the st has hit the fan :( And now the sh has hit the fan :(
- pilif 12y ago
  there we go - another example of my point :p
ams6110 12y ago
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.
- bsaunder 12y ago
  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.
jl6 12y ago
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".
userbinator 12y ago
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. 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. 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.
- Floegipoky 12y ago
  I was just looking at http://stackoverflow.com/a/941390/2517719 http://stackoverflow.com/a/941390/2517719 on monday, and I completely missed the implications.

by pilif 12y ago

ygra 12y ago

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

cleaver 12y ago
:) 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.

minikomi 12y ago

> And now the st has hit the fan :( And now the sh has hit the fan :(

pilif 12y ago
there we go - another example of my point :p

ams6110 12y ago

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.

bsaunder 12y ago
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.

jl6 12y ago

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

userbinator 12y ago

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

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