650704 - Document can be navigated under a modal dialog

Status: RESOLVED FIXED

(Toolkit :: General, defect)

Description

[Michal Zalewski]

Hi folks,

This probably should not be possible:

http://lcamtuf.coredump.cx/ffnavaway.html

(That is, I should not be able to navigate a document that has a modal dialog opened while that dialog stays visible. Seems like a great way to phish.)

The problem is more pronounced in 3.6, where this works for a number of more ambiguous modal dialogs (alert, onbeforeunload, etc). Since you reduced the number of modal dialogs in 4, it's less of a deal there, but it's probably still rather undesirable / confusing.

Comment 1

[Daniel Veditz [:dveditz]]

The dialog in this particular example would be good to phish credentials for any site that uses HTTP auth. Open attacker.com page requesting HTTP auth and nav to the expected domain: user will likely fill in the values when they see the correct site appear without noticing the prompt itself says the wrong site.

Comment 2

[Justin Dolske [:Dolske]]

Started looking at this...

First was the embarrassing realization I had forgotten how even just clicking the back button made the tab-modal prompt go away. Turns out that's sorta the important part.

Since people can interact with browser chrome UI for such prompts, there's explicit code [in tabprompts.xml] to listen for TabClose, unload (of browser window), and pagehide (of content window). Noting,

    // We need to remove the prompt when the tab or browser window is closed or
    // the page navigates, else we never unwind the event loop and that's sad times.

Turns out the old-style, not-tab-modal prompts just don't bother to deal with this at all. After all, you can't interact with the window so how could anything possibly happen. *sigh* This issue probably dates back to when nsIThreadManager was introduced and modal prompts no longer completely froze things until they were dismissed.

The fix here should probably be straightforward... Make commonDialog.js hookup event listeners for TabClose/unload/pagehide, and have those events abort the prompt. May need a little thought around how to abort the prompt, since commonDialog doesn't currently have any such notion. [But it should basically do what tabprompts.xml does.]

Should also probably take a look at how the window-modal prompts are currently dealing with quitting the app. How's that working now? I guess something's just walking windows and .close()ing each one?

Comment 3

[Jesse Ruderman]

> Should also probably take a look at how the window-modal prompts are currently 
> dealing with quitting the app. How's that working now?

Not very well. See bug 398103, bug 715398, and bug 624061.

Comment 4

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Tested; this is still applicable. I stuck an <img> tag that references somethig behind basic auth, then did a simple setTimeout(function() { document.location="http://nytimes.com"; }, 1000);

Comment 5

[:Gijs (he/him)]

(In reply to Tom Ritter [:tjr] (ni? for response to sec-[advisories/bounties/ratings/cves]) from comment #4)

Tested; this is still applicable. I stuck an <img> tag that references somethig behind basic auth, then did a simple setTimeout(function() { document.location="http://nytimes.com"; }, 1000);

The original testcase has gone away, and I don't have a quick way of reproducing the test you describe. However, I suspect this was fixed by bug 613785 and co. Can you confirm?

Comment 6

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

This has been fixed (test case at https://ritter.vg/misc/private/650704.html ) - maybe when we made the basic auth prompt tab-modal...