Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Bugtraq
[Top] [All Lists]

Re: [Full-disclosure] Firefox: serious cookie stealing / same-domain byp

Subject: Re: [Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability
Date: Thu, 15 Feb 2007 14:31:50 +0000
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@dione.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

<Prev in Thread] Current Thread [Next in Thread>