4 ms·

On the theory that it is more likely to help HNers than the bad guys: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html http://httpd.apache.org/docs/2.2/mod/mod

by patio11 12y ago

On the theory that it is more likely to help HNers than the bad guys: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html http://httpd.apache.org/docs/2.2/mod/mod_ssl.html . Note in particular the part about StdEnvVars. The docs say it is off by default, but it is actually on in a lot of common deployment scenarios, for example if most of your apache configs were sourced from the big "apt-get install foo bar baz" line everyone copies from a blog post to get a working LAMP installation on an Ubuntu box. I have not POCed this yet, but if I were trying to, I'd first try to make a client certificate with a highly non-standard Distinguished Name. It doesn't particularly matter if it fails validation as long as it doesn't fail in such a way that Apache dies before passing your information deeper into the guts of the web app. After that point you're just looking for e.g. any page or library in the web app you can coerce to do a system() call or similar. While I was poking around in my own apps something like system(...) in Ruby on Ubuntu actually called /bin/sh rather than bash, but I think that is probably not the case for every combination of stack and distro.

hawkice 12y ago
Slightly more precisely: /bin/sh on ubuntu points to Dash, which is substantially more minimal than bash. Probably not chosen for security (I imagine speed was on their mind), but good either way.
- stakent 12y ago
  In Debian /bin/sh points to dash too.
bch 12y ago
Re: /bin/sh versus /bin/bash (or similar) - note that many Linux systems link /bin/sh -> /bin/bash, so seeing /bin/sh, or knowing that's what system() calls, is not sufficient information on its own to determine your risk.
- patio11 12y ago
  Yep. More broadly, I think the most sensible strategy for determining whether a system is at risk is "If it has bash and isn't airgapped assume that it's vulnerable because it is highly likely someone will find the vector you overlook."
patio11 12y ago
Another thing that interested HNers can feel free to bird dog: PHP + Nginx is often deployed using fastcgi. (And, in my limited experience, far, far more likely to be deployed in greenfield development in the 2010s versus an actual CGI script. I think probably in excess of 20% of "technically savvy young software companies" I run this, the vast majority motivated by one ridiculously common piece of software that I'll refrain from naming because it suggests a trivial spray-and-pray for loop.) fascgi_params puts a lot of attacker controlled data into "environment variables", but depending on php.ini's variables_order setting those might not actually go into what the rest of the word thinks is an environment variable (and hence not get passed to subprocesses, which is the point of the exercise). If php.ini's variables_order includes an "E", then the environment variable QUERY_STRING (among other things) will include attacker-chosen data. variables_order does include E by default, but does not in the php.ini which ships with the obvious apt-get commands for e.g. Ubuntu.
- xorcist 12y ago
  I would like to reply to this but it is very hard to understand what you are alluding to. What is this software that one fifth of companies run and why is technically savvy in scare quotes, along with some veiled reference to something called spray-and-pray? It's really impossible to understand you, but fastcgi_params does not put attacker controlled data into environment variables (without the quotes). That much is clear so normal usage of fastcgi is not in danger.
  - moduloo 12y ago
    > but fastcgi_params does not put attacker controlled data into environment variables it does https://gist.github.com/anonymous/ea60dc2915eccf0b803e https://gist.github.com/anonymous/ea60dc2915eccf0b803e
    - xorcist 12y ago
      It looks like you have dumped the a PHP global variable, possibly $_ENV. Do you know of any circumstances where _ENV, or any other PHP variable with potentially untrusted data, is passed in environment variables?

by patio11 12y ago

hawkice 12y ago

Slightly more precisely: /bin/sh on ubuntu points to Dash, which is substantially more minimal than bash. Probably not chosen for security (I imagine speed was on their mind), but good either way.

stakent 12y ago
In Debian /bin/sh points to dash too.

bch 12y ago

Re: /bin/sh versus /bin/bash (or similar) - note that many Linux systems link /bin/sh -> /bin/bash, so seeing /bin/sh, or knowing that's what system() calls, is not sufficient information on its own to determine your risk.

patio11 12y ago
Yep. More broadly, I think the most sensible strategy for determining whether a system is at risk is "If it has bash and isn't airgapped assume that it's vulnerable because it is highly likely someone will find the vector you overlook."

patio11 12y ago

Another thing that interested HNers can feel free to bird dog: PHP + Nginx is often deployed using fastcgi. (And, in my limited experience, far, far more likely to be deployed in greenfield development in the 2010s versus an actual CGI script. I think probably in excess of 20% of "technically savvy young software companies" I run this, the vast majority motivated by one ridiculously common piece of software that I'll refrain from naming because it suggests a trivial spray-and-pray for loop.) fascgi_params puts a lot of attacker controlled data into "environment variables", but depending on php.ini's variables_order setting those might not actually go into what the rest of the word thinks is an environment variable (and hence not get passed to subprocesses, which is the point of the exercise). If php.ini's variables_order includes an "E", then the environment variable QUERY_STRING (among other things) will include attacker-chosen data. variables_order does include E by default, but does not in the php.ini which ships with the obvious apt-get commands for e.g. Ubuntu.

xorcist 12y ago
I would like to reply to this but it is very hard to understand what you are alluding to. What is this software that one fifth of companies run and why is technically savvy in scare quotes, along with some veiled reference to something called spray-and-pray? It's really impossible to understand you, but fastcgi_params does not put attacker controlled data into environment variables (without the quotes). That much is clear so normal usage of fastcgi is not in danger.
- moduloo 12y ago
  > but fastcgi_params does not put attacker controlled data into environment variables it does https://gist.github.com/anonymous/ea60dc2915eccf0b803e https://gist.github.com/anonymous/ea60dc2915eccf0b803e
  - xorcist 12y ago
    It looks like you have dumped the a PHP global variable, possibly $_ENV. Do you know of any circumstances where _ENV, or any other PHP variable with potentially untrusted data, is passed in environment variables?