Date: Wed, 16 Oct 2013 04:57:40 -0400 (EDT) From: cve-assign@...re.org To: kseifried@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: browser document.cookie DoS vulnerability -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >So to confirm, this crashes just a single tab or thw whole browser? The question here doesn't seem to make sense in this context. The "browser document.cookie DoS" doesn't cause anything to crash. Our Tuesday message in this thread was addressed to Murray McAllister, who brought up the related issue of whether Firefox crashes should have CVE assignments. That message of ours apparently contributed to the mixup. Very roughly, "browser document.cookie DoS" is a behavior, found in multiple web browsers, that lets attackers perform the equivalent of a Logout CSRF attack against many web sites. In a "normal" Logout CSRF scenario, the browser sends a request to (for example) /logout.php, and the web application interprets (or "misinterprets") this to mean that the client user actually wishes to be logged out. The web application might then change the state of something on the server side to indicate that the user is logged out. In this Logout CSRF variant, the browser doesn't send a request to /logout.php and instead sends a request to someplace else, such as the / URI, with parameters to force a web application to set a malformed cookie within the response. At the web-application layer, nothing happens to log out the user. However, at the HTTP server level, the user can be effectively logged out, because the HTTP server isn't wiling to accept requests with malformed Cookie request headers. What's even worse is that this is a Persistent Logout CSRF variant, in the sense that the user cannot login again without restarting the web browser. (Yes, we realize that this isn't exactly like Logout CSRF, because the behavior also prevents visiting unrestricted static pages, which almost always would remain accessible after a "real" logout. Logout CSRF just seemed to be the simplest model for describing the problem.) It seems fairly clear that the web browsers can be blamed for the problem, because they should not be sending the malformed Cookie headers at all. When the web browser sends the malformed Cookie header, it is (in effect) enabling a Logout CSRF vulnerability on a web site that does not have any server-side Logout CSRF problem. In addition, it would sometimes also be possible to blame code on the server side, which should not be trying to set a malformed cookie. In the case of Google Analytics, maybe the server-side issue is site-specific on the *.google-analytics.com servers, and therefore outside the scope of CVE. One might also argue that an HTTP server (such as lighttpd) shouldn't completely block access to the site upon seeing a malformed Cookie header. That's not necessarily a vulnerability, though. For now, it seems simplest to assign CVEs on this basis: - at least two independently implemented web browsers are capable of sending malformed Cookie headers that trigger the lighttpd request.c "invalid char in header" code, leading to the 400 HTTP status code - yes, it can be considered an interaction error between the browser and lighttpd - however, enough blame belongs to the browser that there should be one CVE assigned per independent browser implementation - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJSXlRqAAoJEKllVAevmvmsLLgH/1YNbmFg7Wwthd0FDTco23dB 00+/rffKeR7upR4b2oVWY4lqzVvOFxsOLuZQ873aLax2qXX6cAI1RBwQfjcCa3yb Lu4fuos8VxxHrooX/uI222BBNFnAGDGesYZgT+8loQp/RhSAxSW37HLgKFCbhqSP OdR6IStENL31nYLt6B8Lw4hEPkvsiGDcmT97SEoAFDFqGObmZmuouz13wNJRAccg RUI02GmZIBDErBqu5nWTDIUVNBEvK9tzkMUYXQ8nfqQzX1KyCrrcC5DVhnSwwdMw AxjwrvDOFG2ebkTYk2fNRhI00T18PE66YPBJnh6U0woQ+7svBS8w2TMq/qJbXIQ= =yeRa -----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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ