Mozilla caught napping on URL protocol handling flaw

Mozilla caught napping on URL protocol handling flaw

Summary: It turns out that Mozilla's Firefox is just as guilty Microsoft's Internet Explorer when it comes to passing dangerous data to third party applications.

SHARE:
67

Uh-oh. The latest twist in the URL protocol handling vulnerability saga has left eggs on the faces of the security folks at Mozilla.

It turns out that Mozilla's Firefox is just as guilty Microsoft's Internet Explorer when it comes to passing dangerous data to third party applications.

Over the last two weeks, Mozilla has steadfastly pinned the blame on the URL protocol handling bug on Microsoft, insisting there's a critical IE flaw that remains unfixed but, as a Windows internals expert discovered yesterday, Mozilla might want to be careful about throwing stones.

"Firefox is subject to the exact same flaw that they blame on IE," says Jesper Johansson, a former Microsoft security strategist who has been tracking this bug closely.

Johansson has published proof that Firefox also does not escape quotes in URLs before it passes them on to protocol handlers, a dangerous situation that could lead to code execution attacks.

Interestingly, Johansson does not view this as a browser vulnerability, insisting that the onus is on the application receiving the data to properly validate inputs.

Mozilla's security chief Window Snyder has fessed up to the gaffe exposed by Johansson:

Over the weekend, we learned about a new scenario that identifies ways that Firefox could also be used as the entry point. While browsing with Firefox, a specially crafted URL could potentially be used to send bad data to another application.

We thought this was just a problem with IE. It turns out, it is a problem with Firefox as well. We should have caught this scenario when we fixed the related problem in 2.0.0.5. We believe that defense in depth is the best way to protect people, so we’re investigating it now.

More information on Mozilla's investigation at this Bugzilla entry.

Topics: Security, Browser, Microsoft

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

67 comments
Log in or register to join the discussion
  • Alun Jones insight

    Alun Jones has posted an illuminating piece on this topic here:
    http://msmvps.com/blogs/alunj/archive/2007/07/22/firefoxurl-url-vulnerability.aspx
    and in a comment here:
    http://msinfluentials.com/blogs/jesper/archive/2007/07/10/blocking-the-firefox-gt-ie-0-day.aspx#6570
    Highly recommended reading.
    Aaron_Margosis
    • Message has been deleted.

      Giorgio Maone
  • I'll hold Mozilla to the same standard as MS

    [B]We thought this was just a problem with IE. It turns out, it is a problem with Firefox as well. We should have caught this scenario when we fixed the related problem in 2.0.0.5.[/B]

    It sure looks like they will address the problem. At least they acknowledge the need to do something, "technical foul" or not. Once the Mozilla teams finds a way to protect/mitigate this flaw, I doubt that MS will still be able to claim that there is nothing to be done about it because it is too difficult.

    Keep on this story please.

    TripleII
    TripleII-21189418044173169409978279405827
    • Agreed...at least they acknowledge it. Let's see...

      ....if they do anything about it. If they do, ball...MS's court....squarely.

      If not...they probably have the same reason MS has for not fixing it that MS has.
      mdsmedia
      • hmmm....

        ...sort of double dutch, but you get the idea :)
        mdsmedia
      • If Mozilla doesn't fix it ....

        .... then No_Ax won't be able to criticise them for not fixing it. After all, he's already stated categorically as he said here

        http://talkback.zdnet.com/5208-12691-0.html?forumID=1&threadID=36434&messageID=670660&start=-9891

        [i]"How could MS (or anyone) quantify all the possible arguments that millions of coders can come up with? I mean think about it, there is no way that is possible."[/i]

        Should be interesting ..... :-)
        bportlock
    • Of course they do!

      Mozilla would look even more foolish if they said, "Oh yeah, I guess Microsoft was right all along. Our bad." The ball is squarely in their court and they have to show that Microsoft was wrong by providing a fix and good luck with that.
      RocketEater
      • Mozilla has no choice...

        now. By pushing their non-sense response to this thing in the first place and shovelling blame to where any respectable software engineer knows it DOES NOT belong (Microsoft), Mozilla has reaped its just rewards.

        Bravo that the hypcrisy gods are watching over us.
        BFD
    • Message has been deleted.

      Giorgio Maone
      • It isn't fixed and is only being investigated.

        Your saying so doesn't make it real. There has been no announcement of anymore then just looking into it.
        ShadeTree
        • Check the Bugzilla link in the article.

          The status is listed as "RESOLVED FIXED"
          Letophoro
          • Until they post the patch it is not fixed.

            It doesn't matter what Bugzilla says! What did the Mozilla spokesman say?
            ShadeTree
          • Message has been deleted.

            Giorgio Maone
        • Message has been deleted.

          Giorgio Maone
          • Double encoding?

            How do you ensure you're not causing double-encoding? The browser is an intermediary in this case. See Alun's post:
            http://msmvps.com/blogs/alunj/archive/2007/07/22/firefoxurl-url-vulnerability.aspx
            Also this one:
            http://msmvps.com/blogs/alunj/archive/2007/07/23/firefoxurl-part-ii.aspx
            Aaron_Margosis
          • No double encoding here

            Did you notice my reply to Alun's first post?
            http://msmvps.com/blogs/alunj/archive/2007/07/22/firefoxurl-url-vulnerability.aspx#1052883

            These are the patches:
            https://bugzilla.mozilla.org/attachment.cgi?id=273434 (trunk)
            https://bugzilla.mozilla.org/attachment.cgi?id=273501 (branch)

            They're both equivalent to NoScript's fix, i.e.:

            [pre]uri = uri.replace(/[ "]/, encodeURIComponent);[/pre]

            There's no "double encoding" danger here, because the percent sign is left alone (which is the danger against which the RFC 3986 warned).
            Actually we escape just space and double quote, which prevents this kind of exploitation.
            I agree with Alun's second post when it suggests that treating these two characters as a "special case" is not the safest approach, but it suffices for the general Windows command line case we're discussing here.
            As a matter of fact, I'd go further (and probably will do in the next NoScript release) by encoding everything but alphnum, delim and sub-delim: if some protocol handler chokes on a legal fully encoded URL that will be a good marker for a poorly written recipient.

            That said, I understand Microsoft's concern: if they admitted that encoding the outgoing URI does actually reduce the attack surface, implement a fix and some poorly written recipient actually breaks, they're likely to be blamed anyway (by the other application vendor, at least) because the whole URI handlers mechanism is a Windows feature and they "broke the backward compatibility".
            Giorgio Maone
  • A little off topic...

    The first time I saw her name, I thought it was so ironic that someone with the name [b]Window[/b] would be employed by a competitor of one of Microsoft's prodcucts. I later found out that she also used to work for Microsoft.

    OK, that's it for Today's Useless Facts. ;-)

    MGP
    MGP2
    • You're quick on the uptake ;) nt

      nt
      mdsmedia
      • Yes, Mozilla's security rides on

        the shoulders of a Microsoftie. How about that. I'll bet that kept many a zealot up at night with internal conflicts.
        xuniL_z
  • True or false?

    True or false?

    This could be mitigated by the receving application validating the data it accepts.
    Real World