Am 26.09.2014 um 16:41 schrieb Nick Kew:
I've revisited mod_taint this morning, and made some updates:
a bugfix, a new option to apply an untainting rule to all headers.
But topically, a canned configuration option to protect
against shell-shock patterns:
LoadModule modules/mod_taint.so
Untaint shellshock
Untaint works in a directory context, so can be
selectively enabled for potentially-vulnerable apps
such as those involving CGI, SSI, ExtFilter,
or (other) scripts.
This goes through all Request headers, any PATH_INFO
and QUERY_STRING, and (just to be paranoid) any
other subprocess environment variables. It untaints
them against a regexp that checks for "()" at the
beginning of a variable, and returns an HTTP 400 error
(Bad Request) if found.
Feedback welcome, indeed solicited. I believe this
is a simple but sensible approach to protecting
potentially-vulnerable systems, but I'm open to
contrary views. The exact details, including the
shellshock regexp itself, could probably use some
refinement. And of course, bug reports!
Builds and runs with httpd 2.2 and 2.4. Very limited
testing verifies that it catches a shellshock attack
in a request header.
http://people.apache.org/~niq/mod_taint.html
Note: cross-posting, with followup-to set to dev@.
If you're following up to report a critical bug,
adding users@ will ensure widest exposure!
IMHO it is a useful approach. Whan I looked at the CGI topic, I noticed
that the safest thing is cleaning up in ap_create_environment(), because
you can be sure to get every env var in your hands there, not only the
ones coming from headers. Unfortunately that's not an extensible part of
code (no hook). Furthermore cleaning the env vars only works for CGI,
but not e.g. for FCGI, SCGI proxying etc. Sometimes it would be
convenient to sanitize data on e.g. a revproxy and not on every internal
web server maybe doing CGI. So I'd say mod_taint is a good compromise
between the slightly higher safety of directly sanitizing the env vars
and compatibility with current hooks.
I haven't looked at your updated code yet (only at the old one that
didn't easily allow to untaint all headers), but could it be helpful to
allow narrowing down which headers and vars to untaint? Like e.g. with a
regexp against the header/var name? Something between listing individual
headers und untainting all headers? Or is there no real use case for this?
Some headers have a more complex internal structure. Cookies come to
mind. There one might want to untaint using a regexp against the cookie
values, not the cookie header value.
Regards,
Rainer