mailing list archives
Re: browser document.cookie DoS vulnerability
From: cve-assign () mitre org
Date: Wed, 16 Oct 2013 04:57:40 -0400 (EDT)
-----BEGIN PGP SIGNED MESSAGE-----
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
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
(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
- yes, it can be considered an interaction error between the browser
- 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
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)
-----END PGP SIGNATURE-----