6 ms·

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 v

• pilif 12y ago
  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
• pquerna 12y ago
  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.
• Maken 12y ago
  If something, it's a bug in the CGI specification, since passing HTTP headers as environment variables is part of the standard.
  • mrfusion 12y ago
    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?)
    • tokenizerrr 12y ago
      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.
      • mrfusion 12y ago
        Thanks. So why isn't even being able to declare functions risky? could an attacker overwrite built in functions?
        • tokenizerrr 12y ago
          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.
      • bjornsing 12y ago
        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?!?
        • penguindev 12y ago
          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 http://www.openwall.com/lists/oss-security/2014/09/25/13
          • bjornsing 12y ago
            Thank you God! :)
• jcarreiro 12y ago
  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.
• diydsp 12y ago
  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?
  • mturmon 12y ago
    You are correct, you asked an innocent and to-the-point question.
• AgentME 12y ago
  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.