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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 15 Feb 2007 14:31:50 +0000
From: "pdp (architect)" <pdp.gnucitizen@...glemail.com>
To: "Michal Zalewski" <lcamtuf@...ne.ids.pl>
Cc: security@...illa.org, bugtraq@...urityfocus.com,
	full-disclosure@...ts.grok.org.uk
Subject: Re: Firefox: serious cookie stealing /
	same-domain bypass vulnerability

very good work

I wander whether we can execute code on about:config or about:cache.
Right now we can only modify cookies and bypass the same origin
policy. If we can get JavaScript running on about:cache or
about:config or some chrome URL, we might be able to completely hijack
the browser.

If that is possible, the severity level of this issue is more then HIGH.

On 2/14/07, Michal Zalewski <lcamtuf@...ne.ids.pl> wrote:
> There is a serious vulnerability in Mozilla Firefox, tested with 2.0.0.1,
> but quite certainly affecting all recent versions.
>
> The problem lies in how Firefox handles writes to the 'location.hostname'
> DOM property. It is possible for a script to set it to values that would
> not otherwise be accepted as a hostname when parsing a regular URL -
> including a string containing \x00.
>
> Doing this prompts a peculiar behavior: internally, DOM string variables
> are not NUL-terminated, and as such, most of checks will consider
> 'evil.com\x00foo.example.com' to be a part of *.example.com domain. The
> DNS resolver, however, and much of the remaining browser code, operates on
> ASCIZ strings native to C/C++ instead, treating the aforementioned example
> as 'evil.com'.
>
> This makes it possible for evil.com to modify location.hostname as
> described above, and have the resulting HTTP request still sent to
> evil.com. Once the new page is loaded, the attacker will be able to set
> cookies for *.example.com; he'll be also able to alter document.domain
> accordingly, in order to bypass the same-origin policy for XMLHttpRequest
> and cross-frame / cross-window data access.
>
> A quick demonstration is available here:
>
>   http://lcamtuf.dione.cc/ffhostname.html
>
> If you want to confirm a successful exploitation, check Tools -> Options
> -> Privacy -> Show Cookies... for coredump.cx after the test; for the demo
> to succeed, the browser needs to have Javascript enabled, and must accept
> session cookies.
>
> The impact is quite severe: malicious sites can manipulate authentication
> cookies for third-party webpages, and, by the virtue of bypassing
> same-origin policy, can possibly tamper with the way these sites are
> displayed or how they work.
>
> Regards,
> /mz
> http://lcamtuf.coredump.cx/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>


-- 
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

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