Hacker News Reader

Comment by diydsp | Hacker News Reader

I think I have the same question.. why is this called a "bash" bug? Is it not a webserver bug? Why does the webserver send data to bash through environment variables? Is there no better way to do it?

View on HN

CGI is an interface first defined 1993, 21 years ago. No one thought setting user data in environment variables was a risky thing at the time.

More modern interfaces between dynamic code and webservers, like even FastCGI or SCGI or dozens of others do not pass user data over Environment variables, and instead pass data in various protocols over a socket.

It's a bash bug because the bug is ultimately in how bash parses environment variables. My understanding is quite limited, but IIUC, after the invalid function definition, the bash parser simply stops trying to parse the environment, and the remaining input tokens get used as arguments to the next command executed by the shell.

That's how Unix works. Subprocesses by default inherit the parents environment. And the http headers end up there because the CGI spec says so

Wow, thanks for the downvotes, everyone!

I wonder how that is justified, since my question generated 10 informative replies, five levels deep.

Does anyone dare to tell me why they downvoted my comment?

You are correct, you asked an innocent and to-the-point question.

If something, it's a bug in the CGI specification, since passing HTTP headers as environment variables is part of the standard.

Sort of I guess, but why does bash need to loop over all of the env variables and execute them? I don't think CGI had any reason to think that would ever happen?

(I guess that's basically what it's doing?)

Bash is a shell, part of it's purpose is to deal with enviroment variables. The bug here is that the parser is getting confused, the feature being abused here is being able to declare functions as part of an enviroment variable, which is used to transfer functions to subshells in bash. Now this itself is fine, but since the parser gets confused it also executes commands after the function definition.

Thanks. So why isn't even being able to declare functions risky? could an attacker overwrite built in functions?

They could, you can try for yourself:

    git='() { echo hello; }' bash -c git

but it's generally understood that attackers should not be able to provide enviroment variable names. If the attacker can do that, they can also provide an alternative LD_PRELOAD variable.

Though IMO, yes this is risky.

I honestly can't see why this is "fine"... I understand it's not the security critical bug, but feeding all environment variables into some sort of interpreter...?!?

Ok, bash needs to transfer function definitions to child processes in order to implement something called inherited functions, and I guess you could argue that an environment variable is a reasonable place to store them. But WHY THE HELL does bash have to use the function name as the variable name?!? That's just insane to me...

Any sane programmer would store that shit in an environment variable with a known name (e.g. "BASH_INHERITED_FUNCTIONS"). Why doesn't bash do that?!?

It appears they are talking about requiring prefixes for these vars (finally). Still, you look at the c code / macros that parse this shit and have to shake your head. This is what they mean by "attack surface". http://www.openwall.com/lists/oss-security/2014/09/25/13

Thank you God! :)

There's nothing wrong with putting arbitrary data inside an environment variable that other programs don't assign meaning to.

The issue is that bash takes it upon itself to parse all environment variables for functions, and accidentally executes some of them.

Reply on news.ycombinator.com