Re: Bash CVE-2014-6271 and CGI / HTTPD
On 29/09/2014 00:00, Rainer Jung wrote:
Am 28.09.2014 um 09:07 schrieb Issac Goldstand:
-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).
Those patches were never meant to be incorporated in an httpd release.
OK - just wanted to clarify that, then :)
They can be useful though because they are a short term temporary
workaround for people who can - for whatever reason - not quickly update
their bash and at least want to close the CGI problem. Of course the
bash update is the way to go, but as we all have learned in the meantime
closing all gaps in bash is a non-trivial exercise. Filtering our
incoming data before forwarding was much easier an AFAIK is is still a
valid temporary solution to the CGI attack vector.
Oh, I absolutely agree with that sentiment. But that's with hats other
than httpd committers (which I personally don't think is the same as,
for example, your infra hat).
Real use case? As an example I deployed the two patches for HTTP header
filtering and CGI env var creation on our two most important ASF web
servers instantly after I wrote them and that was earlier than the
availability of the first official OS patches for bash.
Getting a bit off-topic here, but do we have any idea of the effect that
this had? Did the ASF have any way of noticing Suspicious traffic of
the sort either before or after the patch?
Issac
Regards,
Rainer
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.0 +
+++ server/util_script.c2014-09-24 20:35:54.952054361 +
@@ -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.0 +
+++ server/protocol.c 2014-09-24 21:46:54.858054470 +
@@ -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
Re: Bash CVE-2014-6271 and CGI / HTTPD
Am 29.09.2014 um 09:56 schrieb Issac Goldstand: On 29/09/2014 00:00, Rainer Jung wrote: Am 28.09.2014 um 09:07 schrieb Issac Goldstand: -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). Those patches were never meant to be incorporated in an httpd release. OK - just wanted to clarify that, then :) They can be useful though because they are a short term temporary workaround for people who can - for whatever reason - not quickly update their bash and at least want to close the CGI problem. Of course the bash update is the way to go, but as we all have learned in the meantime closing all gaps in bash is a non-trivial exercise. Filtering our incoming data before forwarding was much easier an AFAIK is is still a valid temporary solution to the CGI attack vector. Oh, I absolutely agree with that sentiment. But that's with hats other than httpd committers (which I personally don't think is the same as, for example, your infra hat). Agreed. Discussing workaround patches here (committer head) nevertheless has the benefit of providing users with options even if not contained in releases. Real use case? As an example I deployed the two patches for HTTP header filtering and CGI env var creation on our two most important ASF web servers instantly after I wrote them and that was earlier than the availability of the first official OS patches for bash. Getting a bit off-topic here, but do we have any idea of the effect that this had? Did the ASF have any way of noticing Suspicious traffic of the sort either before or after the patch? Not that I'm aware of and I did not add logging to the value sanitizing. Regards, Rainer
Re: Bash CVE-2014-6271 and CGI / HTTPD
-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.0 +
+++ server/util_script.c2014-09-24 20:35:54.952054361 +
@@ -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.0 +
+++ server/protocol.c 2014-09-24 21:46:54.858054470 +
@@ -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
Re: Bash CVE-2014-6271 and CGI / HTTPD
Am 28.09.2014 um 09:07 schrieb Issac Goldstand:
-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).
Those patches were never meant to be incorporated in an httpd release.
They can be useful though because they are a short term temporary
workaround for people who can - for whatever reason - not quickly update
their bash and at least want to close the CGI problem. Of course the
bash update is the way to go, but as we all have learned in the meantime
closing all gaps in bash is a non-trivial exercise. Filtering our
incoming data before forwarding was much easier an AFAIK is is still a
valid temporary solution to the CGI attack vector.
Real use case? As an example I deployed the two patches for HTTP header
filtering and CGI env var creation on our two most important ASF web
servers instantly after I wrote them and that was earlier than the
availability of the first official OS patches for bash.
Regards,
Rainer
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.0 +
+++ server/util_script.c2014-09-24 20:35:54.952054361 +
@@ -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.0 +
+++ server/protocol.c 2014-09-24 21:46:54.858054470 +
@@ -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
Re: Bash CVE-2014-6271 and CGI / HTTPD
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
Re: Bash CVE-2014-6271 and CGI / HTTPD
On Thu, Sep 25, 2014 at 10:53 AM, Nick Kew n...@apache.org wrote:
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.
The latest news on this (CVE-2014-7169) suggest that bash's function
parser has more than this single issue, so the problematic pattern is
probably something as simple as:
( ) { problematicPart
Or as a PCRE :
^\s*\(\s*\)\s*\{.*
Regards,
Yann.
Re: Bash CVE-2014-6271 and CGI / HTTPD
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
Re: Bash CVE-2014-6271 and CGI / HTTPD
On 09/25/2014 01:03 PM, Jim Jagielski wrote: 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... +1 Regards Rüdiger
Re: Bash CVE-2014-6271 and CGI / HTTPD
On Wed, Sep 24, 2014 at 1:48 PM, Paul Querna 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.
Re: Bash CVE-2014-6271 and CGI / HTTPD
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 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
Re: Bash CVE-2014-6271 and CGI / HTTPD
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
Re: Bash CVE-2014-6271 and CGI / HTTPD
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.0 +
+++ server/util_script.c2014-09-24 20:35:54.952054361 +
@@ -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().
Regards,
Rainer
Re: Bash CVE-2014-6271 and CGI / HTTPD
On Wed, Sep 24, 2014 at 11:15 PM, Rainer Jung rainer.j...@kippdata.de wrote:
A workaround like
--- server/util_script.c.orig 2013-09-14 14:12:54.0 +
+++ server/util_script.c2014-09-24 20:35:54.952054361 +
@@ -128,6 +128,12 @@
}
++whack;
}
+/* Sanitize leading () because of CVE-2014-6271 bash exploit */
+whack++;
+if (*whack++ == '(' *whack == ')') {
Don't you mean if (*++whack == '(' *++whack == ')') instead of the
2 lines above?
Otherwise the post incrementation won't be done before the second
condition, and the test always be false.
+*whack-- = '_';
+*whack = '_';
+}
++j;
}
Regards,
Yann.
Re: Bash CVE-2014-6271 and CGI / HTTPD
Am 24.09.2014 um 23:29 schrieb Yann Ylavic:
On Wed, Sep 24, 2014 at 11:15 PM, Rainer Jung rainer.j...@kippdata.de wrote:
A workaround like
--- server/util_script.c.orig 2013-09-14 14:12:54.0 +
+++ server/util_script.c2014-09-24 20:35:54.952054361 +
@@ -128,6 +128,12 @@
}
++whack;
}
+/* Sanitize leading () because of CVE-2014-6271 bash exploit */
+whack++;
+if (*whack++ == '(' *whack == ')') {
Don't you mean if (*++whack == '(' *++whack == ')') instead of the
2 lines above?
The original code works (tested with a CGI that prints env vars and
setting a custom header starting with ().
The first ++ prefix is not needed because I have a whack++ in the line
before.
Otherwise the post incrementation won't be done before the second
condition, and the test always be false.
+*whack-- = '_';
+*whack = '_';
+}
++j;
}
Thanks for double checking.
Regards,
Rainer
Re: Bash CVE-2014-6271 and CGI / HTTPD
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.0 +
+++ server/util_script.c2014-09-24 20:35:54.952054361 +
@@ -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.0 +
+++ server/protocol.c 2014-09-24 21:46:54.858054470 +
@@ -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
