Firefox 27/Chrome 28 document.cookie DoS vulnerability

2013-04-05 / 2014-02-15
Risk: Medium
Local: No
Remote: Yes
CWE: N/A

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

References:

http://seclists.org/oss-sec/2013/q2/12
https://bugzilla.mozilla.org/show_bug.cgi?id=858215
http://www.openwall.com/lists/oss-security/2013/04/03/10
http://seclists.org/oss-sec/2013/q4/121
http://seclists.org/oss-sec/2013/q4/117
http://redmine.lighttpd.net/issues/2188


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top