On Wed, 2014-09-24 at 22:15 +0200, Rainer Jung wrote:
> 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.
This is a revisiting of the classic perl/cgi "untainting" problem.
Perl's solution is to require anything from an untrusted source
to match a whitelist-style pattern before the system can be
exposed to it.
mod_taint would enable us to sanitise this, while offering
sysops flexibility to vary the sanitising rules.
> The exploit is said to be any env var value looking like
>
> () { something }; problematicPart
That's a pattern that can be regexp-matched. The regexp
could be hardwired in under the name "CVE-2014-6271"
for sysops who want an easy life. This solution
also places in sysops hands the decision whether to
de-fang the attack string or just return 400.
> 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).
So make it a system-wide default, and let the sysop turn it off
if they have a use for headers legitimately matching that pattern!
--
Nick Kew
