Paid Advertising
web application security lab

Analysis of Firefox’s Password Manager Fix

In yet another article that discusses Firefox’s password manager flaw, it appears that only a handful of variants of this bug are fixed, leaving a majority unfixed. That’s bad news for something we sort of thought was a done issue. I supposed it was possible this wasn’t fixed, but never bothered to look into it - it just goes to show that we need to keep pounding on these things until we can no longer find any way around the fixes.

As a side note, Robert Chapin is credited for the original vulnerability in this article, even though he was not the first person to think of it or even exploit it. Although I don’t get much credit for this one Secunia, at least, did update their advisory to at least point to my original post about this, although they still say the original advisory (months later) was found by Robert Chapin. Worse yet, that stupid RCSR (Reverse Cross Site Request) acronym lives on! Why wont it just die? It’s called XSS folks! I am doomed to disclosure obscurity on this one.

Update: Please read the comment by Gavin for more details about this. Apparently Robert Chapin’s analysis could be innacurate or at the very least mis-representing the issue. Thanks for the clarification, Gavin!

10 Responses to “Analysis of Firefox’s Password Manager Fix”

  1. Jack Says:

    Really, Chapin is a moron I wouldn’t pay attention to a single thing he pulls out of his ass. He’s just attempting to cash in on other people’s discoveries.
    His ‘report’ is absolute bullshit. If you look at the ‘open’ issues, you’ll see nearly all of them resolved as non-issues because he’s simply going for bug counts at this point and not even making an effort to think about how inane and so far from reality they are (likely because he doesn’t have a clue what he’s doing).

    The issue’s fixed, but Chapin’s trying to ride the wave as long as possible.

  2. RSnake Says:

    Ah, I will admit, I don’t know him or his knowledge at all. I will defer to others as to what he does or doesn’t know. Thanks, Jack!

  3. Gavin Sharp Says:

    I’d like to make a few important clarifications here. The reported bug was fixed. Firefox records a form’s action URL and uses it to determine whether the password should be filled in.

    Unfortunately, it seems as though Robert has somehow convinced you and others that it wasn’t entirely fixed. I’m not sure how he’s managed to do that, to be honest. It seems like people are just taking his word for it. You can see the supposed remaining flaws by looking at Mozilla bug 373140 ( This is a tracking bug that he filed to track all of the issues he’s found with the Firefox password manager. By looking at that bug’s dependency list (, you can see all of the remaining issues.

    Here’s a brief breakdown of the bugs on that list:
    1) 4 of the 11 bugs are already resolved either WONTFIX or INVALID. This means that they’re either not real issues, or are suggestions that are not going to be taken because they aren’t needed and would break too many existing sites.
    2) Of the other 7 bugs, 5 are valid but minor issues. None of them are exploitable in any way, and most are suggestions for improvements that don’t really have any user impact. One bug predates Robert’s involvement, and the other is a valid regression from the original fix for users with multiple passwords stored on a site. This regression fix is going to be in Firefox, which is due out shortly.

    As you can see, none of the follow up issues that Robert has reported are in any way related to the original bug (the “MySpace problem”). He seems to be treating them as a single “issue” so that he can claim that “[Firefox] has resolved approximately 24% of the security risk related to Bug #360493″. That statement is incorrect. The original issue described in bug 360493 and in Secunia advisory SA23046 is fixed.

    I would appreciate it if you would update your post after taking into consideration these facts, to prevent further misinformation.

  4. RSnake Says:

    Gavin, I would take your word over Robert Chapin’s in this regard, having not spent any time looking at the details here. Thank you for the clarification, Gavin! I’ll make a minor update in case someone fails to read the comments.

  5. kuza55 Says:


    How is not exploitable? Maybe I’m missing something, but to me the issue shows that the fix applied in did not address the threat model properly (i.e. that the attack was still possible given the ability to inject html, but not javascript)…..

  6. Gavin Sharp Says:

    Kuza55: That issue is considerably harder to exploit than the original issue, which submitted the password directly to a third party. The original issue required injecting a form anywhere on the site. That variant requires injecting a form (with the right action URL), and also an image (or other external resource) on the resulting submission page.

    We could play whack-a-mole until the end of time with these problems, but the sad reality is, if you can inject content on a site so easily, there are likely more serious issues to exploit. You need to also consider that the password manager isn’t the main problem here, it’s just a facilitator - if the page is convincing enough, the user is likely going to enter his password regardless of whether we fill it in for them. Then they’ll also blame the password manager for not working correctly.

    Now these are all mitigating factors - you’re right that that issue is similar to the original (although narrower in scope and much harder to exploit). Personally, I think too much of the onus for these bugs was put on Firefox instead of the sites which allow such content injection (e.g. MySpace), but perhaps I’m a little bit biased :).

  7. kuza55 Says:

    Gavin: I agree that it is the sites’ fault for allowing such things, but as with the Non-Alpha-Non-Digit issue, how are web developers meant to know about these things? And just like that issue and the FindMimeFromData issue in IE, and also these issues in the password manager - the browsers have to take responsibility for adding features which people do not know they need to protect against.

    P.S. I have yet to see a single filter which would allow form and input tags but not image tags, so I don’t really think this works in a much (if at all) narrower scope.

  8. kuza55 Says:

    Oh, and RSnake, I personally use the RCSR acronym to differentiate it from XSS, because RCSR is only relevant when you cannot execute (java)script, if you can execute script then its XSS, and the payload then is programmatic password theft. But if there is no scripting involved, then its easier to use a semi-known acronym rather than writing a paragraph explaining what you mean - oh and acronyms make good tags, :p

  9. Gavin Sharp Says:

    Kuza55: One of the points in my original reply to you was that the Firefox password manager isn’t a “feature [web developers] need to protect against”. Whether or not the password manager automatically fills in your password doesn’t really have any impact on the issue. Browsers without password managers are just as “vulnerable” - they’re just less useful, because they force the user to fill in the password themselves.

  10. RSnake Says:

    @kuza55 I personally think RCSR is a horrible term because it a) doesn’t describe the issue and b) is most commonly used *with* XSS not *instead* of XSS. It’s a term that needs to die.