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

Reply via email to