[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201310160857.r9G8vedS008699@linus.mitre.org>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
