14 ms·

Your response sounds like blaming the world's oldest webserver for being the world's oldest webserver. CGI sucks, but telling the 1990s to go home and not come

by csirac2 12y ago

Your response sounds like blaming the world's oldest webserver for being the world's oldest webserver. CGI sucks, but telling the 1990s to go home and not come back until it has a secure mechanism of IPC just isn't helpful: this seriously isn't an Apache (or other CGI httpd) problem. As someone else said, traditionally only the names of shell variables have mattered, not the content. Apache exports most of its envars named HTTP_* as an attempt to somewhat de-fang them. That some crusty CGI app spawned a bash process which then chose to do something outrageous with the content of HTTP_COOKIE really isn't Apache's fault. Seriously.

nailer 12y ago
Unix domain sockets existed in the 90s and would have done the job adequately without evaling anything in transit. Apache transmitting data created by random people to CGI processes using environment variables is most definitely Apaches fault. It was a dumb idea in the 90s and it's a dumb idea now.
- csirac2 12y ago
  Where in the CGI spec does it say anybody has to eval anything?
  - nailer 12y ago
    Nowhere. 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 ago
        All 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 ago
        Well, 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 ago
      CGI 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 ago
      Apache 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.
- csirac2 12y ago
  There's a lot of Apache hate here but I have to wonder if you've actually used it. Anyone stuck running cgi stuff with apache invariably goes to fastcgi or mod_fcgid for performance reasons, which already uses a unix domain socket. That shellshock exploits will still be possible in this configuration is once again, not Apache's problem.
  - nailer 12y ago
    Pointing out that people from the internet shouldn't be able to set shell variables isn't 'hate' - it's basic security and knowledge that alternative, more secure transport systems exist. Saying that Apache (and other apps) passing data from random people on the internet to a known insecure environment like a shell, that was known to be insecure in the 90s, is 'not Apache's problem' doesn't actually absolve Apache of responsibility for its own programming.
    - csirac2 12y ago
      1) Since the mid-90s Apache and similar http servers have offered fastcgi as a way of communicating with processes with sockets. So you can understand why hearing you single out apache to "use a more secure IPC like sockets" detracts from the main argument which I'd otherwise agree with. 2) I'd wager that the people who came up with CGI initially had expected that the process apache spawns would be anything but a shell. 3) Non-shell CGI processes happily deal with all manner of binary, back-ticks, dollar signs etc. in their HTTP_ envars all day and have done so for nearly 20 years. It's not a huge leap in logic then that these envars should be considered capable of holding arbitrary data without exploding. 4) You make it sound like nobody has considered environment variables a problem before, but sanitizing the environment before spawning a process from the CGI was already a well-established best-practice way before this bug came along. That process looks like - whitelist of envar names, remove all others; check PATH/LD_LIBRARY_PATH/etc sanity; command string parameters use specialized token substitution (eg. "echo %{integer}%" where some bespoke code throws an error if %{integer}% is interpolated to anything other than an integer), etc. 5) Despite the insanity of running CGI stuff which I would generally agree isn't a great idea, I'm pretty sure I'm allowed to be surprised that the mere content of an environment variable, whose job it is is to contain arbitrary data to be passed on to the CGI app should cause things to explode.
- mcguire 12y ago
  You realize that this isn't just an Apache problem. It's a problem with any network-accessible program, directly or indirectly.
arielby 12y ago
Environment variables are not supposed to be "evaling options in transit". They are a decent method for passing small amount of data to a program you start.

by csirac2 12y ago

nailer 12y ago

Unix domain sockets existed in the 90s and would have done the job adequately without evaling anything in transit. Apache transmitting data created by random people to CGI processes using environment variables is most definitely Apaches fault. It was a dumb idea in the 90s and it's a dumb idea now.

csirac2 12y ago
Where in the CGI spec does it say anybody has to eval anything?
- nailer 12y ago
  Nowhere. 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 ago
      All 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 ago
        Well, 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 ago
    CGI 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 ago
    Apache 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.
csirac2 12y ago
There's a lot of Apache hate here but I have to wonder if you've actually used it. Anyone stuck running cgi stuff with apache invariably goes to fastcgi or mod_fcgid for performance reasons, which already uses a unix domain socket. That shellshock exploits will still be possible in this configuration is once again, not Apache's problem.
- nailer 12y ago
  Pointing out that people from the internet shouldn't be able to set shell variables isn't 'hate' - it's basic security and knowledge that alternative, more secure transport systems exist. Saying that Apache (and other apps) passing data from random people on the internet to a known insecure environment like a shell, that was known to be insecure in the 90s, is 'not Apache's problem' doesn't actually absolve Apache of responsibility for its own programming.
  - csirac2 12y ago
    1) Since the mid-90s Apache and similar http servers have offered fastcgi as a way of communicating with processes with sockets. So you can understand why hearing you single out apache to "use a more secure IPC like sockets" detracts from the main argument which I'd otherwise agree with. 2) I'd wager that the people who came up with CGI initially had expected that the process apache spawns would be anything but a shell. 3) Non-shell CGI processes happily deal with all manner of binary, back-ticks, dollar signs etc. in their HTTP_ envars all day and have done so for nearly 20 years. It's not a huge leap in logic then that these envars should be considered capable of holding arbitrary data without exploding. 4) You make it sound like nobody has considered environment variables a problem before, but sanitizing the environment before spawning a process from the CGI was already a well-established best-practice way before this bug came along. That process looks like - whitelist of envar names, remove all others; check PATH/LD_LIBRARY_PATH/etc sanity; command string parameters use specialized token substitution (eg. "echo %{integer}%" where some bespoke code throws an error if %{integer}% is interpolated to anything other than an integer), etc. 5) Despite the insanity of running CGI stuff which I would generally agree isn't a great idea, I'm pretty sure I'm allowed to be surprised that the mere content of an environment variable, whose job it is is to contain arbitrary data to be passed on to the CGI app should cause things to explode.
mcguire 12y ago
You realize that this isn't just an Apache problem. It's a problem with any network-accessible program, directly or indirectly.

arielby 12y ago

Environment variables are not supposed to be "evaling options in transit". They are a decent method for passing small amount of data to a program you start.