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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 03 Feb 2006 14:57:32 +0100
From: "Yngve Nysaeter Pettersen" <yngve@...ra.com>
To: "Michal Zalewski" <lcamtuf@...ne.ids.pl>,
	bugtraq@...urityfocus.com
Subject: Re: Cross Site Cooking


On Sun, 29 Jan 2006 01:50:23 +0100, Michal Zalewski <lcamtuf@...ne.ids.pl>
wrote:

>     Problem #1 - trouble with these pesky foreigners
>     ------------------------------------------------
>
>     The mechanism for preventing overly relaxed cookie domain
>     specification seems to be broken in all major browsers. Some ancient
>     documents invoke the following flawed but reasonable rule:
>
>      "Two dots are required if the top level domain is: .COM, .EDU, .NET,
>       .ORG, .GOV, .MIL, or .INT. Three dots are required for any other
>       domain. This is to prevent the subdomain from being set to  
> something
>       like .COM, the subdomain of all commercial machines."
>
>       [ http://www.ciac.org/ciac/bulletins/i-034.shtml ]
>
>     This is repeated ad nauseam in various cookie tutorials and FAQs,
>     but my initial tests indicate that the rule is quite simply not true.
>     Both MSIE and Firefox seem to be perfectly happy with two-period
>     ccTLDs domain cookies (.xxx.xx).
>
>     In other words, one can set a cookie for *.com.pl or *.com.fr, and
>     override or corrupt credentials or other parameters on hundreds of
>     thousands e-commerce websites in that country. It will be also
>     possible to plant attacker's session ID on visitor's computer,
>     and effectively, steal his credentials when he decides to sign in
>     on the target site.

When this problem was (to my knowlegde) first published in December 1998,  
this was called the "Cookie Monster Bug". See  
http://help.netscape.com/kb/consumer/19981231-1.html (the original  
advisory page is gone).

The problem about the two internal dot rule for ccTLDs is that many ccTLDs  
are using a flat structure similar to the generic .com TLD, not a  
hierarchical structure like the one used by the .UK domain. To make  
matters worse, many ccTLDs are actually using a combination of the two  
structures.

As far as I know there is no reliable algorithmic way to determine if a  
domain name is a valid domain (like company.tld) or a subTLD (like co.uk).  
One method could be a blacklist for common subTLDs like co.tld, com.tld,  
ac.tld, etc., but it is dificult to make such a list complete, and some  
ccTLDs also have multilevel subTLDs and also uses geographic names in such  
second level domains, e.g. city.state.us, and many countries have national  
names for their subTLDs. Last time I checked http://www.govcom.org/  
indicated that at least half of the ccTLDs had some form or hierarchical  
structure, but an unknown percentage of these are using a hybrid structure.

Opera's current approach (which is not perfect) is to use a DNS lookup for
non-generic (only those in Netscape's original list are considered generic  
in this context) that are either second level domains or two levels up  
 from the server setting the cookie. If there is an IP address defined for  
the domain name, the cookie is accepted for the domain, otherwise it is  
only accepted for the server
setting the cookie.

We are investigating ways to improve on this method, but as far as I can  
tell, any improvement will require a coordinated effort by all the gTLD  
and ccTLD registries.


>     Problem #2 - these cursed periods
>     ---------------------------------

>     One can set a cookie for ".com.", then bounce the visitor to
>     http://www.victim.com./ . This address differs from the "real" one,
>     and thus, unlike with #1, planted cookies would work only for this
>     visit - but the trailing "." is not an alarming pattern for most

In Opera this domain would be handled as described above, with a DNS  
lookup, and since ".com." will not resolve the cookie will only be  
accepted for the server setting the cookie.

> Solution
> --------
>
>   Problem #1: There is no sane solution, other than altering HTTP cookie
>   format so that the server gets a chance to figure out who issued that
>   cookie in the first place. Workarounds by listing ccTLDs that use
>   .xxx.xx/.xx.xx subdomains in the browser are better than nothing
>   at all.

RFC 2965, which is supported by Opera, already specifies such an extension  
to the cookie format. See http://www.ietf.org/rfc/rfc2965.txt for more  
details.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer		             Email: yngve@...ra.com
Opera Software ASA                   http://www.opera.com/
********************************************************************


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ