full-disclosure - Re: Firefox: serious cookie stealing / same-domain bypass vulnerability

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] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.58.0702220151110.6282@dione>
Date: Thu, 22 Feb 2007 02:08:28 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ne.ids.pl>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Firefox: serious cookie stealing /
 same-domain bypass vulnerability

There seems to be some confusion regarding the exact impact of the
location.hostname vulnerability, and the ways to protect against it. I
wanted to offer a quick clarification.

  1) Cookie setting (session fixation) attacks can be executed universally
     and with no restrictions. This is demonstrated by the originally
     provided PoC, and is a serious security threat. A common implication
     of such a flaw is that the user can be forced to authenticate within
     attacker's session, implanted as a persistent cookie.

     WARNING: The attack does not require the browser to interact with
     the attacked site in any way. The cookie is set somewhere else and
     ahead of the visit. In other words, the fact your site runs IIS does
     not make you any more secure. The fact your servers are behind Squid
     in a reverse proxy mode has no significance.

     Vulnerable *clients* can be protected by a proxy that rejects
     requests containing a NUL character; Squid is a good example. A
     safer option is to implement the prefs.js workaround recommended on
     the test page and in Bugzilla, however... and an updated version of
     Firefox should be available tomorrow, anyway.

  2) Frame / window manipulation and cookie stealing attacks can be
     executed against sites that explicitly set 'document.domain' to an
     arbitrary value, even if this occurs only on a single sub-page. Some
     high-profile sites do that, others don't. Still, the attack is very
     much possible; I prepared a new testcase for non-believers:

     http://lcamtuf.dione.cc/ffhostname_cnn.html

  3) In my initial advisory, I mistakenly stated that XMLHttpRequest() can
     be one of attack vectors. It can't - contrary to some sources, in
     Firefox, this mechanism ignores document.domain altogether. You have
     to rely on the two methods described above - but that's quite a lot,
     anyway.

Cheers,
/mz



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/