Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Oct 2013 04:57:40 -0400 (EDT)
Subject: Re: browser document.cookie DoS vulnerability

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

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 * 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 ]
Version: GnuPG v1.4.14 (SunOS)


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.