162518 - possible princeton-style cookie stealing exploit

Status: RESOLVED INVALID

(Core :: Networking: Cookies, defect)

Description

[Darin Fisher]

the fix for bug 161228 possibly re-introduced the princeton-style exploit for
cookies.

mitch, dveditz and i discussed this issue before choosing to go ahead with the
fix for bug 161228, which was a regression resulting from the original princeton
attack fix (bug 149943).

basically, the problem is that our DNS table now maps host:port -> ipaddress
instead of host -> ipaddress.  see bug 161228 for a description of why this was
necessary.  as a result, we may connect to a different ip node depending on the
desired port.  this is expected, but since the cookies security model is based
solely on the hostname (not including the port), we could potentially be sharing
cookies between different ip nodes.  one of the nodes might be a page with
sensitive content and the other might be an attackers webserver.

there are a few things about cookies that we might be able to leverage to fix or
at least diminish this sort of attack.

1) the Set-Cookie header may include a domain= value which can be used to verify
that the requesting hostname matches the specified domain name.  this would
prevent www.evil.com:4444 from seeing the cookies set by www.evil.com:80, in the
case that www.evil.com:80 actually mapped to www.amazon.com, for example.  i
haven't looked to see exactly what we do with the domain= parameter... morse?

2) the Set-Cookie header may also specify that the cookie is secure.  for secure
cookies, we might want to consider restricting the cookie to only the
originating server (e.g., must match protocol://host:port).  mitch suggested
that this probably would break some sites, but it might still be reasonable.

Comment 1

[Stephen P. Morse]

Unles I'm misunderstanding this, there is no problem because currently the port
is stored along with the hostname and is used by the cookie module when making
tests.

There is of course bug 142803 in which I claim that we shouldn't be testing
ports because it is violation of the cookie spec.  But I was concerned about
making such a radical change and probably breaking a few sites.  Based on what
you are saying here, there is even more reason not to fix bug 142803.

Comment 2

[Darin Fisher]

my cookies.txt file does not mention any port numbers... so how is the cookie
module able to compare ports?

Comment 3

[Darin Fisher]

or, is it that we assume port 80 when none is specified?

Comment 4

[Stephen P. Morse]

If a port is specified, it will be included with the host name in the
cookies.txt file.  If none is specified, there will be none in the cookies.txt file.

Comment 5

[Darin Fisher]

does the cookie service use the protocol's default port if none is explicitly
specified in the URL string?

Comment 6

[Stephen P. Morse]

The cookie service doesn't "use" ports.  It simply records them and tests for
them, and it records just what it is given.  That is, if it is not given a port,
it doesn't record any port.

It's the network layer that would "use" the port, and it would decide to use a
default port if none is specified.

Comment 7

[Darin Fisher]

the cookie service takes nsIURI's as input and decides what to extract from the
URL in order to determine what to record to its database.  from a quick glance
at my cookies.txt, it is apparent that the cookie service is not storing the
port along with the hostname in all cases.  that has nothing to do with
networking other than perhaps the fact that cookies is leveraging networking URL
parsing routines to access fields in the URL.

if we determine that we should be storing host:port in all cases, then the
cookie service needs to take due diligence to ensure that host:port is written
out to cookies.txt in all cases.

given that cookies does not store the port in all cases, we have to consider the
possibility of a potential princeton like exploit.

morse: can you address my original two comments?  do we check the domain= value
included in Set-Cookie headers against the hostname of the URL?  thx!

Comment 8

[Stephen P. Morse]

In a private e-mail from darin he reported:

   actually, i tried setting this up, and the exploit wasn't possible.  it turns
   out that cookies will in fact compare www.evil.com to www.evil.com:4444 before
   attempting to share cookies.  now, i wonder what would happen if i were instead
   running a HTTPS server at https://www.evil.com:443/ ... could i then steal
   cookies?  because the protocol scheme is not recorded in the cookies database,
   right?

Sounds like what I said in comment 1 and comment 4.  Closing out as invalid

Comment 9

[Darin Fisher]

steve: no i don't think this should be marked INVALID yet.  we haven't ruled out
the possibility of stealing cookies from a HTTPS site using a HTTP site.

e.g., https://www.evil.com/ and http://www.evil.com/ can see each others
cookies.  given that these may each resolve to different IP addresses, there is
the possibility of a princeton like attack.  i just haven't had the time yet to
setup a testcase.

Comment 10

[Darin Fisher]

after some more thought...

1) it would be impossible for a DNS server to make www.evil.com point at the
ip-address of another domain's HTTPS server.  that sort of thing is prevented by
SSL.

2) that means that an attackers DNS server would only be able to steal cookies
from a HTTP site using a HTTPS server under its own control.

case 2 is not very interesting, and probably doesn't correspond to any kind of
real security threat.  so, i'm going to mark this bug INVALID.