-0
While I love the code that's been come up with, this would be akin to
trying to have patched httpd to deal with Heartbleed.
I can't see any real use-case where a user would get a patched httpd
without getting a patched bash, too. Either they'll know, or they'll be
getting this from their distro's package manager (and we know how long
that'll take to propagate anyway).
Just my $0.02
Issac
On 9/25/14 12:55 AM, Rainer Jung wrote:
Am 24.09.2014 um 23:15 schrieb Rainer Jung:
Am 24.09.2014 um 22:21 schrieb Rainer Jung:
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.
A workaround like
--- server/util_script.c.orig 2013-09-14 14:12:54.000000000 +0000
+++ server/util_script.c 2014-09-24 20:35:54.952054361 +0000
@@ -128,6 +128,12 @@
}
++whack;
}
+ /* Sanitize leading "()" because of CVE-2014-6271 bash
exploit */
+ whack++;
+ if (*whack++ == '(' && *whack == ')') {
+ *whack-- = '_';
+ *whack = '_';
+ }
++j;
}
seems to work.
It is not a general purpose fix though, because it will break CGI apps,
that actually use env vars with values starting with "()".
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 somewhere down their handling chain).
These are *not* handled by the above patch, because they don't use
ap_create_environment().
And the more general workaround would be:
--- server/protocol.c.orig 2014-03-10 13:04:03.000000000 +0000
+++ server/protocol.c 2014-09-24 21:46:54.858054470 +0000
@@ -848,6 +848,13 @@
*tmp_field-- = '\0';
}
+ /* Sanitize leading "()" because of CVE-2014-6271
bash exploit */
+ tmp_field = value;
+ if (*tmp_field++ == '(' && *tmp_field == ')') {
+ *tmp_field-- = '_';
+ *tmp_field = '_';
+ }
+
apr_table_addn(r->headers_in, last_field, value);
/* reset the alloc_len so that we'll allocate a new
Essentially the same code, but now when parsing the http headers. So
this would sanitize them even for proxy use (FCGI, SCGI, ...), SSI,
CGI etc. Again this might break specific use cases, but in general
header values starting with "()" should be rare.
Regards,
Rainer
