4 ms·

> if Apache/dhclient wants to put things into environment variables... it absolutely should ... take into account all possible contexts Sorry if I'm picking on

> if Apache/dhclient wants to put things into environment variables... it absolutely should ... take into account all possible contexts Sorry if I'm picking on you too much, but I noticed this and thought of an even better counterexample. By this logic, it's Apache's job to prevent SQL injections. It should know that a single quote, in one possible context, can terminate an SQL string, popping the SQL parser into a state that allows for arbitrary statement injection. It also needs to know about any other database language that could ever possibly be invented, now and for eternity, because we can't know how long any given version of Apache will remain in use.

andy_ppp 12y ago
The analogy is very weak, SQL injection should be prevented in your application. Does Apache need to set global environment variables, it seems pretty extreme that it just takes all the user input and makes it available to the underlying shell, there will be a whole class of bad stuff that comes from this!
- masklinn 12y ago
  > Does Apache need to set global environment variables Apache? No. mod_cgi? Yeah, because that's its fucking job because that's how CGI works http://tools.ietf.org/html/rfc3875 http://tools.ietf.org/html/rfc3875
  - andy_ppp 12y ago
    Er... Well it's one way of it working, from the spec: 'meta-variable' A named parameter which carries information from the server to the script. It is not necessarily a variable in the operating system's environment, although that is the most common implementation. I suppose the authors of bash know that most of the implementations of CGI do this so they should be preventing bugs like this. Thanks for your clarification. I still maintain that this sounds like a very insecure mechanism for passing information from Apache to your application.
    - nknighthb 12y ago
      Keep reading. Use of environment variables is specified for Unix. (And, actually, for all other systems which the RFC provides a specification, differing only in minor detail.) http://tools.ietf.org/html/rfc3875#section-7.2 http://tools.ietf.org/html/rfc3875#section-7.2 For UNIX compatible operating systems, the following are defined: Meta-Variables Meta-variables are passed to the script in identically named environment variables. These are accessed by the C library routine getenv() or variable environ. This is how CGI works. This is how CGI has always worked. NCSA HTTPd was built on and for Unix, and was the origin of what we now call CGI. This is the interface to which CGI-compliant scripts and webservers have always adhered. > I suppose the authors of bash know that most of the implementations of CGI do this 1) I don't know why you would suppose the authors of Bash would know how CGI works. Nothing about writing a shell implies knowledge of the intricacies of web technologies. Certainly many of the people on HN so eagerly looking to blame either Bash or Apache don't seem to know how it works. If they did, they might have realized what quesera so astutely observed earlier today[0]: "This is neither a bug in bash, nor a bug in Apache, etc. It's an integration bug between two complex systems that were designed with zero-to-poor knowledge of each other." 2) I don't know when this particular Bash feature originated, but Bash as a whole pre-dates CGI by about five years. > I still maintain that this sounds like a very insecure mechanism I don't know of anyone who has looked at CGI and thought the use of environment variables was a good idea in the face of the 21st century's security landscape. This mess was more than two decades in the making. It is the collision of two entirely unrelated courses plotted by two entirely unrelated parties, neither of whom could have been expected to know what the other was doing, and neither of whom could have foreseen how yet more unrelated parties would (in some cases unknowingly!) combine their works into a time bomb. [0] https://news.ycombinator.com/item?id=8376914 https://news.ycombinator.com/item?id=8376914
      - scintill76 12y ago
        > "This is neither a bug in bash, nor a bug in Apache, etc. It's an integration bug between two complex systems that were designed with zero-to-poor knowledge of each other." Which makes OP's comparison to Ariane 5, a spacecraft with an infamous bug that could be described as an "integration bug" (between older and newer parts of the software), even funnier. Hopefully the development teams of a rocket were a bit more in-sync than those of Apache, bash, distribution maintainers (some of whom have made /bin/sh link to bash), and CGI programmers.
claudius 12y ago
> Sorry if I'm picking on you too much Don’t worry. > By this logic, it's Apache's job to prevent SQL injections. Curiously, I’d call this an example for my position, not yours: It is not the job of the SQL server to prevent SQL injections, quite the contrary, it is the job of the calling application to ensure that the things it tells the SQL server to do are actually safe. Similarly, it is the job of Apache to ensure that the things it tells its child processes to do are safe. … Actually, you’re probably right – if I’m guessing correctly that all the "CGI" standard does is to say "These user-supplied values go into these environment variables", then it is not the job of Apache to sanitise them. It merely means that Bash is an unsuitable choice for an environment with untrusted environment variables, i.e. as a CGI script or even for use as /bin/sh if you cannot trust environment variables. It gets a bit messier with dhclient, because that explicitly calls a Bash script and hence definitely should know about the issues Bash might have with environment variables.
- nknighthb 12y ago
  There's no need to guess. The relevant RFC sections are easily located. http://tools.ietf.org/html/rfc3875#section-3.4 http://tools.ietf.org/html/rfc3875#section-3.4 http://tools.ietf.org/html/rfc3875#section-4.1.18 http://tools.ietf.org/html/rfc3875#section-4.1.18 http://tools.ietf.org/html/rfc3875#section-7.2 http://tools.ietf.org/html/rfc3875#section-7.2 http://tools.ietf.org/html/rfc3875#section-9 http://tools.ietf.org/html/rfc3875#section-9 HTTP header values have some limited formatting requirements[0], but are otherwise arbitrary. There is no general way for the server to know which values are safe and which are not. That would require the server to know how the script would respond to any particular input. If that were the case, the script would be superfluous, and the server could simply respond to the client with the result it already knows the script would return! [0] https://tools.ietf.org/html/rfc2616#section-4.2 https://tools.ietf.org/html/rfc2616#section-4.2
- adekok 12y ago
  > It is not the job of the SQL server to prevent SQL injections True. But perfectly valid SQL shouldn't cause the SQL server to be exploitable. And the application has no idea which SQL statements are exploitable. > Similarly, it is the job of Apache to ensure that the things it tells its child processes to do are safe. True. But the unsaid assumption is "safe from the point of Apache". Not "safe from the point of some unknown exploit". So it's reasonable for an application to sanitize what it passes to the shell, by dealing with known and documented issues. e.g. Don't pass "$FOO" in a string to system() and expect it to be treated as the literal "$FOO" string. It's unreasonable to expect that the application know everything about the attack surface of everything it uses. Maybe there's a bug in an SQL library which causes the application to crash when a SELECT statement contains the text "crashme". This text is valid SQL, and it is entirely unreasonable to expect that the application "sanitize" such text. In the same way, environment variables are strings. It's a bit surprising to discover that bash will execute code contained in random environment variables.

andy_ppp 12y ago

The analogy is very weak, SQL injection should be prevented in your application. Does Apache need to set global environment variables, it seems pretty extreme that it just takes all the user input and makes it available to the underlying shell, there will be a whole class of bad stuff that comes from this!

masklinn 12y ago
> Does Apache need to set global environment variables Apache? No. mod_cgi? Yeah, because that's its fucking job because that's how CGI works http://tools.ietf.org/html/rfc3875 http://tools.ietf.org/html/rfc3875
- andy_ppp 12y ago
  Er... Well it's one way of it working, from the spec: 'meta-variable' A named parameter which carries information from the server to the script. It is not necessarily a variable in the operating system's environment, although that is the most common implementation. I suppose the authors of bash know that most of the implementations of CGI do this so they should be preventing bugs like this. Thanks for your clarification. I still maintain that this sounds like a very insecure mechanism for passing information from Apache to your application.
  - nknighthb 12y ago
    Keep reading. Use of environment variables is specified for Unix. (And, actually, for all other systems which the RFC provides a specification, differing only in minor detail.) http://tools.ietf.org/html/rfc3875#section-7.2 http://tools.ietf.org/html/rfc3875#section-7.2 For UNIX compatible operating systems, the following are defined: Meta-Variables Meta-variables are passed to the script in identically named environment variables. These are accessed by the C library routine getenv() or variable environ. This is how CGI works. This is how CGI has always worked. NCSA HTTPd was built on and for Unix, and was the origin of what we now call CGI. This is the interface to which CGI-compliant scripts and webservers have always adhered. > I suppose the authors of bash know that most of the implementations of CGI do this 1) I don't know why you would suppose the authors of Bash would know how CGI works. Nothing about writing a shell implies knowledge of the intricacies of web technologies. Certainly many of the people on HN so eagerly looking to blame either Bash or Apache don't seem to know how it works. If they did, they might have realized what quesera so astutely observed earlier today[0]: "This is neither a bug in bash, nor a bug in Apache, etc. It's an integration bug between two complex systems that were designed with zero-to-poor knowledge of each other." 2) I don't know when this particular Bash feature originated, but Bash as a whole pre-dates CGI by about five years. > I still maintain that this sounds like a very insecure mechanism I don't know of anyone who has looked at CGI and thought the use of environment variables was a good idea in the face of the 21st century's security landscape. This mess was more than two decades in the making. It is the collision of two entirely unrelated courses plotted by two entirely unrelated parties, neither of whom could have been expected to know what the other was doing, and neither of whom could have foreseen how yet more unrelated parties would (in some cases unknowingly!) combine their works into a time bomb. [0] https://news.ycombinator.com/item?id=8376914 https://news.ycombinator.com/item?id=8376914
    - scintill76 12y ago
      > "This is neither a bug in bash, nor a bug in Apache, etc. It's an integration bug between two complex systems that were designed with zero-to-poor knowledge of each other." Which makes OP's comparison to Ariane 5, a spacecraft with an infamous bug that could be described as an "integration bug" (between older and newer parts of the software), even funnier. Hopefully the development teams of a rocket were a bit more in-sync than those of Apache, bash, distribution maintainers (some of whom have made /bin/sh link to bash), and CGI programmers.

claudius 12y ago

> Sorry if I'm picking on you too much Don’t worry. > By this logic, it's Apache's job to prevent SQL injections. Curiously, I’d call this an example for my position, not yours: It is not the job of the SQL server to prevent SQL injections, quite the contrary, it is the job of the calling application to ensure that the things it tells the SQL server to do are actually safe. Similarly, it is the job of Apache to ensure that the things it tells its child processes to do are safe. … Actually, you’re probably right – if I’m guessing correctly that all the "CGI" standard does is to say "These user-supplied values go into these environment variables", then it is not the job of Apache to sanitise them. It merely means that Bash is an unsuitable choice for an environment with untrusted environment variables, i.e. as a CGI script or even for use as /bin/sh if you cannot trust environment variables. It gets a bit messier with dhclient, because that explicitly calls a Bash script and hence definitely should know about the issues Bash might have with environment variables.

nknighthb 12y ago
There's no need to guess. The relevant RFC sections are easily located. http://tools.ietf.org/html/rfc3875#section-3.4 http://tools.ietf.org/html/rfc3875#section-3.4 http://tools.ietf.org/html/rfc3875#section-4.1.18 http://tools.ietf.org/html/rfc3875#section-4.1.18 http://tools.ietf.org/html/rfc3875#section-7.2 http://tools.ietf.org/html/rfc3875#section-7.2 http://tools.ietf.org/html/rfc3875#section-9 http://tools.ietf.org/html/rfc3875#section-9 HTTP header values have some limited formatting requirements[0], but are otherwise arbitrary. There is no general way for the server to know which values are safe and which are not. That would require the server to know how the script would respond to any particular input. If that were the case, the script would be superfluous, and the server could simply respond to the client with the result it already knows the script would return! [0] https://tools.ietf.org/html/rfc2616#section-4.2 https://tools.ietf.org/html/rfc2616#section-4.2
adekok 12y ago
> It is not the job of the SQL server to prevent SQL injections True. But perfectly valid SQL shouldn't cause the SQL server to be exploitable. And the application has no idea which SQL statements are exploitable. > Similarly, it is the job of Apache to ensure that the things it tells its child processes to do are safe. True. But the unsaid assumption is "safe from the point of Apache". Not "safe from the point of some unknown exploit". So it's reasonable for an application to sanitize what it passes to the shell, by dealing with known and documented issues. e.g. Don't pass "$FOO" in a string to system() and expect it to be treated as the literal "$FOO" string. It's unreasonable to expect that the application know everything about the attack surface of everything it uses. Maybe there's a bug in an SQL library which causes the application to crash when a SELECT statement contains the text "crashme". This text is valid SQL, and it is entirely unreasonable to expect that the application "sanitize" such text. In the same way, environment variables are strings. It's a bit surprising to discover that bash will execute code contained in random environment variables.