Paid Advertising
web application security lab

Firefox location.hostname Vulnerability

Michal Zalewsky has been on a role lately - this time with overwriting cookies on other people’s domains in Firefox. Yup, Jordan Wiens sent this over to me and apparently a bug has already been filed by Mozilla to fix this but this has some interesting security implications.

The trick isn’t too complex, he is essentially using a null separator which confuses Firefox, but the implications mean that you can do session fixation across domains or invalidate cookies, etc. Further there may be other nasty things you can do since Firefox may not know where it is (allowing you unrestricted XMLHTTPRequests). Think of this as the mhtml bug for Firefox. Nasty. Great work Michal!

9 Responses to “Firefox location.hostname Vulnerability”

  1. Wladimir Palant Says:

    I already played with this vulnerability a little two days ago. It doesn’t give you any cross-domain access: no XMLHttpRequest, no frames, no cookie stealing. The only thing that seems to get confused is setting of a cookie. Maybe there is something non-obvious that lets you do more interesting things but so far that hole doesn’t seem too bad - not comparable with the MHTML bug.

  2. Jordan Says:

    Wladimir — ok, so I wasn’t doing anything wrong. I was only able to get cookie writing working–I couldn’t get read access and wasn’t sure if I was doing something wrong.

    Still a problem, but not nearly as bad as it might have been.

  3. WhiteAcid Says:

    only write access.
    Well… that does allow for session fixation and some sites consider cookie variables as secure and don’t filter them, I guess they don’t think peoplep would XSS themselves. Well… now you can set those cookies to something bad.

    Great find though.

  4. anon Says:

    I also found that after the hostname had been set to “domain.tld\x00other.tld”, the page source returned the source of the root directory (”/”) of the server rather than the current page.

  5. RSnake Says:

    What do you mean the page source? The XMLHTTPRequest response?

  6. Jordan Says:

    No, if on the client that you’re testing, you view the source in the browser — I noticed the same thing when playing with it.

    It is kind of a neat trick to see one page in the browser, but viewing the source produces an entirely different page.

  7. lpilorz Says:

    Right, I’ve seen the wrong source displayed for such page too. I’m not sure if requesting the page again for viewing source is such a good idea in case of a browser…

  8. lpilorz Says:

    location.hostname bug allows full cross-site access, if the target page has document.domain set by JavaScript (document.domain=document.domain is sufficient). It’s an additional protection in Firefox, disallowing cross-subdomain access unless the document.domain is set by both sides. As Michal Zalewski pointed out, that makes a domain vulnerable if it has at least one page with document.domain set.
    The first frame is readable, the second is not.

  9. Wladimir Palant Says:

    Now I see why setting document.domain didn’t work for me - you cannot have document.domain set to “” if location.hostname is “…”. But if you put a dot before it works…