3 ms·
Where in the CGI spec does it say anybody has to eval anything?
by csirac2 12y ago
Where in the CGI spec does it say anybody has to eval anything?
- nailer 12y agoNowhere. Apache should have used a socket rather than the shell (which effectively evaluates data as instructions). People knew shell was insecure in the 90s, and there were malicious users back then too. I think environment variables were used either due to naivity or an ultimately mistaken concept of simplicity. Sunning up the entire thread: Apache should have used a socket, and should have known they needed to.
- quesera 12y ago> Apache should have used a socket, and should have known they needed to. Well, there's nothing inherently dangerous about setting environment values. Yes, some have special meanings in special contexts but so could data piped over a socket. So your argument boils down to: Apache should have seen the special treatment of data in this context, and used another context instead. That's fine, but it doesn't address the real problem, which is that the shell was not designed to be executed on behalf of other users. There's no spec to say that data received from the "other" channel will not be interpreted or used unexpectedly. Until you have that guarantee, you're just rearranging the problem space. There's no systemic improvement.
- nailer 12y ago> So your argument boils down to: Apache should have seen the special treatment of data in this context, and used another context instead. Yes, the behaviour of all Unix shells and their poor separation of data from instructions is well known in the 90s. > There's no spec to say that data received from the "other" channel will not be interpreted or used unexpectedly. That is true. However something specifically designed as a communications channel, such as a socket or FIFO, is generally better suited than something designed as a shell.
- clarry 12y ago> Apache should have used a socket rather than the shell (which effectively evaluates data as instructions). But the shell shouldn't evaluate data as instructions. This is the bug! Apache could have used a socket and I could write a buggy endpoint which evaluates data read from that socket as instructions. Tada, same problem, same bug.
- nailer 12y agoAll Unix shells don't really separate data from instructions. Your PS1, for example, can contain commands in backticks and subshells, it's expected to be able to do so. Shells are insecure. You could replace them with something compatible but insecure, but they wouldn't be a POSIX shell anymore. Hence the well known SetUID blocking on shell scripts, hence not letting random people on the internet set shell variables.
- clarry 12y agoWell, it's well known that being able to freely set certain environment variables is a disaster. That any variable regardless of its name should have such an effect is, however, news. You can talk all you want about unrelated gotchas in shells & security, and that's missing the point.
- nknighthb 12y agoCGI originated with NCSA. It was already a de-facto standard by the time Apache was released a couple years later. Absolutely nothing about the CGI attack vector is unique to Apache. It could occur with any webserver that supports CGI which, up until nginx, was pretty much all of them.
- vidarh 12y agoApache doesn't have the option of using a socket for implementing the CGI spec. The spec specifies environment variables. Apache could refuse to provide a mod_cgi, in which case it would never have gained the position it did, and some other server with support for CGI would have.
- nailer 12y ago> The spec specifies environment variables. If that's true, then the spec has been obviously, fundamentally broken for it's entire existence.