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 Sun, 28 Sep 2014 07:07:40 GMT
-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 <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