httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <mar...@beamartyr.net>
Subject Re: Bash CVE-2014-6271 and CGI / HTTPD
Date Mon, 29 Sep 2014 07:56:37 GMT
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 <paul@querna.org
>>>>>>> <mailto:paul@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


Mime
View raw message