[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5163198A.6060105@redhat.com>
Date: Mon, 08 Apr 2013 13:24:58 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Stefan Bühler <stbuehler@...httpd.net>
Subject: Re: browser document.cookie DoS vulnerability
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In general the web browser vendors are CNAs (CVE Numbering
Authorities) so they would handle this on their own end. You should
probably email this to the various web browser security teams/etc.
On 04/03/2013 09:58 AM, Stefan Bühler wrote:
> Hi,
>
> Chromium 25.0.1364.160 (debian testing), Iceweasel/Firefox 19 and
> probably many other browsers allow javascript to set broken cookie
> values, leading to possible permanent "400 Bad Request" responses.
> The broken value might be set by 3rd party libraries.
>
> For example the google analytics code is vulnerable, as it sets
> cookie values based on parameters in the referer query string.
> lighttpd does not allow control characters in http header values,
> so any lighttpd site using google analytics is vulnerable if you
> can get the user to follow a link (img tag for example) to that
> site like this:
>
> http://www.example.com/?utm_source=test&utm_medium=test&utm_campaign=te%05st
>
>
>
> Afaik apache doesn't check the cookie values (or perhaps removes
> the broken characters). Imho they are responsible for this mess :)
>
> To be clear: the bug is in the browser / javascript
> implementation:
>
> document.cookie MUST NOT allow cookie values which include certain
> control characters. Javascript applications should not use 8-bit
> characters.
>
> (If browser vendors want to allow broken cookie values to be
> stored, they MUST NOT send them to the server; in this case
> javascript applications can still read the broken values. But I
> don't think this is a good idea.)
>
> The safe character set for HTTP header values is: %x20-7E; %x80-FF
> is obsoleted by the current draft.
>
> "A recipient MAY replace any linear white space with a single SP
> before interpreting the field value", so horizontal tabs are not
> "safe" - they might get converted to a space, but are not forbidden
> (also multiple spaces can get replaced by a single one).
>
> I think this could use a CVE.
>
> The problem was reported in our lighttpd bug tracker:
> http://redmine.lighttpd.net/issues/2188
>
> Kind regards, Stefan
>
>
> Testing the bug:
>
> Try one of the listed urls in the ticket (the error should trigger
> after a reload). If you have noscript, request policy, referer
> control or similar stuff running you are probably safe; to test the
> bug in this case you need a Javascript console on a lighttpd site
> (http://lighttpd.net for example), and enter:
>
>> document.cookie = "foo=bar\x05test"
> Try to reload the page - it should return a 400 Bad Request page
> now.
>
>> document.cookie = "foo="
> And it should work again.
>
>
> HTTP references:
>
> http://tools.ietf.org/html/rfc2616
>> message-header = field-name ":" [ field-value ] field-name =
>> token field-value = *( field-content | LWS ) field-content =
>> *TEXT | *(token | separators | quoted-string) LWS =
>> [CRLF] 1*( SP | HTAB )
>>
>> # TEXT is superset of (token | separators | quoted-string) TEXT =
>> LWS | %x21-7E | %x80-FF
>
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22
>> header-field = field-name ":" OWS field-value BWS field-name
>> = token field-value = *( field-content / obs-fold )
>> field-content = *( HTAB / SP / VCHAR / obs-text ) obs-fold
>> = CRLF ( SP / HTAB )
>>
>> # obsolete text obs-text = %x80-FF
>
> Basic definitions:
>> # horizontal tab HTAB = %x09 # space SP = %x20 # visible ASCII
>> VCHAR = %x21-7E # carriage return + line feed CRLF = %0x0D %0x0A
- --
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAEBAgAGBQJRYxmJAAoJEBYNRVNeJnmTUqMP/3RPIw70vTnpffLk5/dPHhRV
NWNEL8hShnBEr3ZdL29SG8GimmR/cdkuWvj9hAAQljUVBuzBTrpl2u/sf4X5KDfF
VFmGppv3lP7JBJzAquS1W/68P7tjC4UDCLKFlIH7Om3QeDCR7XlKzaK5+RKO6JWw
pe+B+g+ZkbIGlbgQdHUnFyWqRUqSCX/Kal7tOsvf3Z0x8uDyqFID+nBs0rYeycHH
8g3TbYVKAr0jBsOcFYESPPo9otoIaZ1q4uA8hAltktgNw+/PNNuRfZc3fhdC7YiE
17z3z06/ScLc+MvDTviVic7uJnyMyJjjyjHFfcHrdA7m8ua/d+BEI3gPijs40Srj
8uvPpgjqyDd4yPZwprc81+Ab6KWdMU1/wNB9X9AxnImYref0wBpYpQTjlWLh/2wd
jwFpzCcm8eydAUkUShDTwvSRk5zZxuWGoFu4GReVx2Tg6kmQrtcmj/5W5ejhiTNb
6x+HfM7HwWzm5kDaSfy7kQ6GtwLEOsoNiQl1V6Pf2PM6Bazo3c/QE0BHeESPemE8
5WBA7I2rcfFi7/HSqz6QiV06s9LqIB46ObDQ0ZyG+WEY/dA1b/15795GM/ewL0dR
pMrAEiGNL+znEI/jRlGFZWL3nPyb79lO9nHaa+QzM67HHfcpTMrJgQtahwdGlmX5
YIDpnJ/yk2LYBL0vUDI3
=cdby
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
