lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <200511042115.50938.stefan.winter@restena.lu>
Date: Fri Nov  4 19:15:59 2005
From: stefan.winter at restena.lu (Stefan Winter)
Subject: Browser cookie handling: possible cross-domain
	cookie sharing

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ