[Full-disclosure] Browser cookie handling: possible cross-domain cookie sharing

• Previous message: zdi-disclosures_at_3com.com: "[Full-disclosure] ZDI-05-002: Clam Antivirus Remote Code Execution"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: full-disclosure@lists.grok.org.uk
Date: Fri, 4 Nov 2005 21:15:50 +0100

Hello list,

I stumbled over a rather strange behaviour in Konqueror and other browsers,
related to cookie storage and name resolution, that - I think - makes data
leakage via cookies possible. It needs a special setup, but such setups are
common (I use the trailing dot notation for FQDNs in this mail to keep clear
about what's what):
- the computer used must have a domain search-path in case the user enters a
non-FQDN
- the beginning of the hostname visited must in itself be a host or domain
name
Example: search-path==yourcompany.com., host==ap1.com.yourcompany.com.

Then let the user be entering "ap1.com" in the Location Bar, which the
resolver will - depending on its configuration - expand to
ap.1.com.yourcompany.com. . In this case, Konqueror (and others) does two
things:

1) [minor issue] it asks the user if he wants to accept cookies from the
_domain_ ap1.com (ap1.com. actually, but it doesn't display the trailing dot
and can't tell the difference between the host actually meant and the
top-level domain)
When the user sets this it will not only be valid for the host visited (i.e.
ap1.com.yourcompany.com.) but also mistakenly for the entire top-level domain
ap1.com. .
This is not really a big thing, but might fool the user to accepting cookies
he may not want when he later visits the domain ap1.com. .

2) [bigger issue] when the cookie is accepted, it gets stored in Konqueror's
cookie store as belonging to the top-level domain ap1.com. .This is a real
problem: If the user ever truly visits the domain ap1.com. then his browser
will happily send the cookie with the request, containing whatever (possibly
sensitive) information is in it (for example, if the host ap1.com is a Cisco
Access Point and the user was administering it, some of the APs settings are
contained in the cookie).

Possible solutions: Difficult to solve cleanly, since applications in general
don't have full control over the workings of the resolver. What seems to be
at least a quick-and-dirty fix is:
When the user enters something without a trailing dot in the Location Bar,
look up two hosts:
- the literal input of the user (in the example: "ap1.com")
- the input with a trailing dot added ("ap1.com.")
If the two results are different then the resolver has mangled the host name
somehow. Then cookies from the host should not be treated as belonging to a
top-level domain.
If the two results are equal then the host actually is the top-level host.
The cookie store could differentiate between the two cases by saving cookies
from hosts which pass this check _with_ the trailing dot, and all others
without the dot (which is the more correct behaviour anyway: host names
without a trailing dot are relative to some unspecified root and should never
be treated as top-level).

Not only Konqueror handles cookies this way. As far as I can tell, Mozilla and
Firefox behave the same, and I haven't checked Opera and IE yet.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche - Ingénieur de recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

• Previous message: zdi-disclosures_at_3com.com: "[Full-disclosure] ZDI-05-002: Clam Antivirus Remote Code Execution"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]