Hey. In the wake of httpoxy[0] shouldn't suexec also block the problematic HTTP_ env vars from being passed on? Right now it seems that anything starting with HTTP_ or SSL_ is passed through which doesn't seem particularly trustworthy at a first glance. Cheers, Chris. [0] https://httpoxy.org/
It's designed to run CGI scripts, and CGI scripts have expect headers communicated this way -- so I am not seeing a good case to strip them in them in suexec. Leaving PR open for other opinions.
Well, AFAIU, you're anyway going to block at least the Proxy header in httpd completely, now, aren't you? 1) has anyone checked whether such naming collisions occur on other HTTP_* names (which suexec would let pass all)? 2) Could it be that people use suexec (i.e. the binary) outside of Apache (e.g. behind some other webserver) and would thus benefit from blocking the env_var at that level as well? Cheers, Chris.
(In reply to Christoph Anton Mitterer from comment #2) > Well, AFAIU, you're anyway going to block at least the Proxy header in httpd > completely, now, aren't you? The proposed change for httpd is to not copy this specific header into the child processes environment with the HTTP_ prefix. > 1) has anyone checked whether such naming collisions occur on other HTTP_* > names (which suexec would let pass all)? I haven't seen any findings in that area. > > 2) Could it be that people use suexec (i.e. the binary) outside of Apache > (e.g. behind some other webserver) and would thus benefit from blocking the > env_var at that level as well? It's possible, and it's possible they'd benefit from removing HTTP_PROXY in suexec. If we removed more variables, it's possible they'd be adversely affected. I'd be +0.5 on removing just HTTP_PROXY from suexec. This already happens on trunk and is just a partial backport.
That was basically my thought… if it's probably anyway going to be removed from the httpd itself (I mean the Proxy header) then the only other way it could make it to suexec would be by some SetEnv or so… not sure if anything requires this, but I'd be tempted to say that such programs should anyway rather use proper config files ;)
Hmm I just re-thought the whole thing... Isn't the problem below httpoxy actually "much" bigger, at least in principle? Who says that there aren't any further scripts out there (which are run from webservers, which export HTTP_<header> vars), which make use of such names? HTTP_* is pretty generic and by no means anything one would need to assume that "belongs" to CGI, or to webserver-set variables that aren't to be trusted. There could be a HTTP_MODE variable which takes e.g. "plain" or "ssl" and causes the program in question to make further connections plain (and possibly insecure) when the attacker can overwrite it with an Header. Not sure if this breaks many scripts, but it rather seems to me, as if webservers should per default not export *any* untrusted HTTP request headers as envvars, at least as long as this doesn't happen below a sufficiently obvious namespace (e.g. SET_BY_WEBSERVER_AND_INSECURE_<header name> or so ;-) ... What do you think?
(In reply to Christoph Anton Mitterer from comment #5) > Hmm I just re-thought the whole thing... > > Isn't the problem below httpoxy actually "much" bigger, at least in > principle? > > Who says that there aren't any further scripts out there (which are run from > webservers, which export HTTP_<header> vars), which make use of such names? > HTTP_* is pretty generic and by no means anything one would need to assume > that "belongs" to CGI, or to webserver-set variables that aren't to be > trusted. > > There could be a HTTP_MODE variable which takes e.g. "plain" or "ssl" and > causes the program in question to make further connections plain (and > possibly insecure) when the attacker can overwrite it with an Header. > > > Not sure if this breaks many scripts, but it rather seems to me, as if > webservers should per default not export *any* untrusted HTTP request > headers as envvars, at least as long as this doesn't happen below a > sufficiently obvious namespace (e.g. SET_BY_WEBSERVER_AND_INSECURE_<header > name> or so ;-) ... > > > What do you think? I don't agree, maybe someone else will. Better odds if you take it to a mailing list as an improvement rather than further complicate this report.