797618 - Prevent cookie overflow + replace

Status: RESOLVED DUPLICATE of bug 607613

(Core :: Networking: Cookies, defect)

Description

[Jason Duell]

Not sure if this should be public or not (probably doesn't need to be hidden?)

We have an allegation of a cookie vulnerability:

   https://twitter.com/johnwilander/status/253137680970444801

Since we enforce cookie limits on a effective top-level domain basis (150 cookies per ETLD, aka 'foo.com' or 'foo.co.uk', etc), if someone knows the name of an httpOnly cookie, and they have access to running JS in the same ETLD they can have JS set enough cookies to evict all cookies for that ETLD and then set a cookie from JS with the same name, thus replacing the httpOnly cookie with a one set from JS.  Likewise, this also means that 'hostonly' cookies (i.e. cookies set just for 'specific-host.foo.com') can be flushed and overridden by a different site in foo.com.   And 'secure' (HTTPS-only) cookies can also be flushed and set from a non-HTTPS page in same ETLD.  Due to the beauty of the cookie spec, servers are not actually notified if the cookie they're getting was set via secure/httpOnly/hostOnly, so they can't tell the difference between their original cookie and the new cookie..

I'm not sure what security rating to give this (going with sec-moderate for now).  Note that there's no information loss in this attack--just the ability to replace the cookie.  The latest cookie spec is clear that attackers can delete cookies via overflow (see last paragraph of

   http://tools.ietf.org/html/rfc6265#section-8.6

and the ability to then set a same-named cookie is then implicit, I suppose.  But if we can think of a useful way to limit/circumvent this attack, it'd be nice.  When we thought it was just about httpOnly cookies, biesi suggested we keep a different cookie limit for httpOnly and non-httpOnly cookies.  That would work for the httpOnly case, but would only 'sort of' work for the 'secure' case (JS is allowed to set 'secure' when setting document.cookie, so an attacker couldn't flush a site's secure cookies from a HTTP page but could from an HTTPS one).  We could prioritize flushing domain cookies over hostonly ones, and/or not permit a site to flush hostonly cookies from other sites: this this would prevent the attack from a different site, but still allow JS running in the exact domain to replace hostOnly cookies.

So right now if we think this merits action, I'd propose we

1) keep separate lists of cookies per basedomain: one list contains all 'httpOnly' cookies, another contains 'secure' (but not httpOnly) cookies, and another contains all other cookies for the basedomain. 

2) When we add a cookie, if it's set from JS it can't evict cookies in the httpOnly list.  If it's not 'secure' it also can't evict 'secure' cookies.

3) We don't allow adding a cookie to evict anything but a domain cookie or a cookie from the same exact hostname.

If there's no room and no cookies can be evicted, we just drop the attempt to set the cookie.

I'm not sure I've thought of all the edge cases here... thoughts appreciated.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Jason Duell (:jduell) from comment #0)
> If someone knows the name of an httpOnly cookie, and they have access to
> running JS in the same ETLD they can have JS set enough cookies to evict all 
> cookies for that ETLD and then set a cookie from JS with the same name, thus 
> replacing the httpOnly cookie with a one set from JS.

The site should not be allowing untrusted JS to be served from its domains or subdomains, otherwise they are in for all kinds of trouble. For example, it would already be vulnerable to race conditions (some JS sets a cookie before the server sends us the httponly version of the cookie). If that is a prerequite for this kind of attack, then this isn't a moderate-severity bug in Firefox, IMO.

> Due to the beauty of the cookie spec, servers are not actually
> notified if the cookie they're getting was set via secure/httpOnly/hostOnly,
> so they can't tell the difference between their original cookie and the new
> cookie..

Interesting. We should try to change this.

> If there's no room and no cookies can be evicted, we just drop the attempt
> to set the cookie.

I don't think this would work. Then you're just opening the door to DoS.

I am tempted to say that we should:

1. Change all our "same ETLD+1" checks for resource consumption to "same scheme and same ETLD+1", to avoid the case where MitM'd HTTP traffic causes problems for secure sites.

2. Make it the website's responsibility to ensure they do not serve untrusted.

3. Do not allow any cookies to be set from a non-HTTP connection for any site that is HSTS.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Brian Smith (:bsmith) from comment #1)
> 2. Make it the website's responsibility to ensure they do not serve
> untrusted.

... content; i.e. it is the site's responsibility to ensure they never serve/run any untrusted JS code and it is their job to ensure they don't let subdomains set cookies inappropriately through HTTP headers.

Comment 3

[Josh Aas]

Jason - assigning to you for now, if you have a better assignee go for it.

Comment 4

[Jason Duell]

Sid: does this need to be hidden?  Sounds like we're arguing over whether it should be sec-mod or less.

I'm also really unclear as to how important this is to fix.  It's not likely to rise to the top of my TODO list any time soon, unless I'm misunderestimating the importance here.

Monica Chew or jdm are also possible assignees here.

Comment 5

[Sid Stamm [:geekboy or :sstamm]]

Based on how I understand this issue, it's not a super-critical problem.  I agree with bsmith in comment 2 -- but there's probably things we can do to help.

HttpOnly is supposed to prevent data leakage out of cookies and into JS, right? If so, this attack doesn't actually defeat HttpOnly, but it sounds like we could take measures to make httponly cookies stronger. If an attacker can put arbitrary JS on a site, it's probably got worse problems than cookie or session replacement/eviction.

These are my two cents.  I don't think this bug needs to be hidden, but defer to the security bug folks.

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Sid Stamm [:geekboy or :sstamm] from comment #5)
> These are my two cents.  I don't think this bug needs to be hidden, but
> defer to the security bug folks.

I agree this bug doesn't need to be hidden. It is a well-known problem.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

You don't need to overflow the cookie, do you? Couldn't you simply set a cookie with the same name to overwrite the existing one?