Firefox: serious cookie stealing / same-domain bypass vulnerability



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/



Relevant Pages

  • [Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability
    ... There is a serious vulnerability in Mozilla Firefox, tested with 2.0.0.1, ... Doing this prompts a peculiar behavior: internally, DOM string variables ... cookies for *.example.com; he'll be also able to alter document.domain ... malicious sites can manipulate authentication ...
    (Full-Disclosure)
  • Re: Automating a POST request
    ... The way you are creating your payload string is nuts. ... Look at the cookies. ... Most sites handle login by sending a cookie on the login form. ... The cookie needs to come back on the Post request. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: FormsAuthentication and Redirection fails
    ... I've figured the reason why this behaviour is happening. ... and it seems that it blocks cookies from http://localhost ... > public static string Authenticate(string EmailAddress, ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: authentication ticket expiring too soon
    ... public static int SignIn(string email, ... string UserID = DReader.GetInt32.ToString; ... The cookies are not being properly set. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: upload xml to https with certificate?
    ... CookieContainer cookies = new CookieContainer; ... // cast the WebRequest to a HttpWebRequest since we're using HTTPS ... //add secure certificate ... string postHeader = sb.ToString; ...
    (microsoft.public.dotnet.framework.aspnet)

Quantcast