I agree, but one-off, specific-case hacks like that are usually more trouble then they are worth, imo at least. What if we find another attack vector? Then we add another special case, etc...
IMO, this is outside of httpd's realm to "deal with"... Just my 2c On Sep 24, 2014, at 4:21 PM, Rainer Jung <rainer.j...@kippdata.de> wrote: > Am 24.09.2014 um 22:15 schrieb Rainer Jung: >> Am 24.09.2014 um 20:20 schrieb Eric Covener: >>> >>> On Wed, Sep 24, 2014 at 1:48 PM, Paul Querna <p...@querna.org >>> <mailto:p...@querna.org>> wrote: >>> >>> Thoughts? Is it reasonable to do something in mod_cgi{d} to improve >>> the situation? >>> >>> >>> I don't think so, even if we tried to figure out the interpreter, it >>> could run _anything_ else that is interpreted by bash. >>> >>> But an announcement might be helpful to users. >> >> One could try to sanitize env var contents in ap_create_environment() >> though. Currently we do sanitize variable names there. But there's no >> generally good pattern for the value sanitizing. >> >> There's just a known one for this specific vulnerability, which might >> break CGIs expecting content which is only problematic for broken bash. >> So the sanitizing would be a workaround patch, which would only be >> useful for people who can not quickly update their bash but can update >> their web server. Not very likely but also not unthinkable of. >> >> The exploit is said to be any env var value looking like >> >> () { something }; problematicPart >> >> So for instance optionally removing any semicolon from values would >> help, but also likely break common values. I don't know, whether >> removing "()" would suffice, or if an exploit could also contain >> whitespace or even other chars between "(" and ")". Otherwise optionally >> removing "()" would help. > > The common recipes only work with a leading "()" in the variable value. So > removing "()" from the variable value if it starts with these two chars would > stop the problem. > >> The problem might also apply to SSI and other interfaces that can set >> environment variables, like maybe FCGI and SCGI (if they later trigger >> bash calls). > > Regards, > > Rainer
