1412559 - Malicious page can cause POSTDATA confirm dialog loop and prevent leaving / closing tab

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Andreas Jung]

The page mentioned in the bugs URL field (replace hxxp:// with http://) first asks for username / password. If you click cancel in this dialog box it will enter a loop of POSTDATA resend confirm dialogs.

It doesn't matter what you do next: clicking resend, cancel, closing the dialog, the result is the same: the dialog will open again. Any interaction with the browser UI is impossible because the dialog is modal (you can't close the tab or the browser, you have to force kill it).

It should not be possible to lock up the browser in such a way.

Comment 1

[Andreas Jung]

Attachment: Screenshot of the issue.

The screenshot shows installed addons, but I verified that the issue also exists in a profile without any addons installed.

Comment 2

[Andreas Jung]

Attachment: Main HTML (in case the website changes)

Comment 3

[Andreas Jung]

Attachment: installlistener.htm

Comment 4

[Andreas Jung]

Attachment: reloadlistener.htm

Comment 5

[Andreas Jung]

Attachment: reloadlistenerready.htm

Comment 6

[Andreas Jung]

I could reproduce the issue always on initial load, but when restoring the session with session restore after a forced quit it doesn't always occur.

Force crashing Firefox when the problem occurs:
bp-c0a927e7-d4c3-4b9c-a655-7f8280171028

Comment 7

[Andreas Jung]

Attachment: Testcase

I've created a testcase that demonstrates the problem without the need to go to the probably malicious website from comment 0.

Run the attached python script and then simply go to http://localhost:8080

When writing this testcase I also noticed the behavior of the POST-data confirm dialog is a bit different depending on the OS:
Linux (Ubuntu): The tab can't be closed via the tab close button or the Firefox windows with the window controls, but the hamburger menu can be opened and Firefox can be closed with it.
Windows: The tab and window can't be interacted with at all and the Firefox process has to be forcefully terminated.

Comment 8

[Andrew Overholt [:overholt]]

Wennie, do we have plans to limit the effects here?

Comment 9

[Wennie]

We don't have an active work item on this. Johann, please take a look at this.

Comment 10

[Johann Hofmann [:johannh]]

I wonder why we're re-sending postdata on document.location.reload(), the code says it should only happen when "the user pressed reload or shift-reload".

https://searchfox.org/mozilla-central/rev/ed212c79cfe86357e9a5740082b9364e7f6e526f/docshell/base/nsDocShell.cpp#12849

FWIW, Chrome either doesn't prompt or doesn't re-send in this scenario (though they do prompt for manual reloads on other pages), from a quick check.

Is that something we could potentially fix up? Maybe bz knows?

Comment 11

[Boris Zbarsky [:bzbarsky]]

> I wonder why we're re-sending postdata on document.location.reload()

Because historically it's supposed to do pretty much what a user-initiated reload does.  This behavior dates back to approximately forever.

> FWIW, Chrome either doesn't prompt or doesn't re-send in this scenario

The two cases are pretty different, no?

A simple test like so:

1)  Load data:text/html,<form action="http://software.hixie.ch/utilities/cgi/test-tools/echo" method=post><input type="submit" name="something" value="Submit me">
2)  Click the button.
3)  Open the web console.
4)  Type location.reload() and hit enter.

suggests that Chrome very much re-sends, no?

Of course Chrome doesn't prompt when I reload from the UI either, so the answer may well be "Chrome never prompts at all".

What we should probably do to avoid the abuse is make the postdata prompt tab-modal.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> Of course Chrome doesn't prompt when I reload from the UI either

Ah, but only after I have done a scripted location.reload().  That also breaks its session history (filed <https://bugs.chromium.org/p/chromium/issues/detail?id=782699>) and seems to put it in a bizarre state of some sort...

Comment 13

[Johann Hofmann [:johannh]]

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #11) 
> What we should probably do to avoid the abuse is make the postdata prompt
> tab-modal.

Ok, thanks for looking into it. I agree that the best solution then. This should be only a flag on nsIPrompt, right? Let me give it a try...

Comment 14

[Johann Hofmann [:johannh]]

Attachment: Bug 1412559 - Make the "confirm repost" prompt tab modal.

This is done to prevent malicious pages from abusing the feature
to lock up the browser.

Review commit: https://reviewboard.mozilla.org/r/197710/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/197710/

Comment 15

[Johann Hofmann [:johannh]]

There's a disadvantage to this approach in that it makes the repost prompt not overlap the nav toolbar, so that it's not crossing the "line of death" that marks secure browser UI.

There are long term plans for a widget that is both tab modal and overlapping chrome UI in bug 1319984, but that's really too far off for me to consider blocking this bug on it. I think we'll eventually get there as both Web Payments and WebAuth seem to want it, so we could make a follow-up bug that tracks moving the repost prompt into that potential new widget once it exists (or just make a comment in bug 1319984 about it).

I don't think it's problematic to have it show over web content in the mid term, though, compared to the detrimental effect this has on browsing.

Comment 16

[Adam Roach [:abr]]

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #11)

> What we should probably do to avoid the abuse is make the postdata prompt
> tab-modal.

One of the things to keep in mind is that this prompt is intended to prevent users from losing non-trivial data when navigating away from a page, *and* when closing a tab/window. While I agree that making it tab-modal is in general an improvement for the navigation case, we need to think about how we want to prevent losing data in the tab/window close case. Perhaps a modal dialog that requires a 5-second cooling off period, per origin, between firings, would serve the purpose.

Comment 17

[Johann Hofmann [:johannh]]

(In reply to Adam Roach [:abr] from comment #16)
> (In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from
> comment #11)
> 
> > What we should probably do to avoid the abuse is make the postdata prompt
> > tab-modal.
> 
> One of the things to keep in mind is that this prompt is intended to prevent
> users from losing non-trivial data when navigating away from a page, *and*
> when closing a tab/window.

Is it? Are you talking about the "This page is asking you to confirm that you want to leave - data you have entered may not be saved." prompt? That one is already tab-modal to my understanding. :)

We mean the prompt that comes up when you reload a page that was opened via POST.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8926463 [details]
Bug 1412559 - Make the "confirm repost" prompt tab modal.

https://reviewboard.mozilla.org/r/197710/#review203124

r=me, assuming you've tested this and it does what we expect.

Comment 23

[Johann Hofmann [:johannh]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d3426bfef38a3dba27b1d1183b5f4427cbeb7436

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/818860c42bca
Make the "confirm repost" prompt tab modal. r=bz

Comment 25

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/818860c42bca

Comment 27

[Andreas Jung]

Since this issue is still actively exploited should the patch be considered as a candidate for a dot release ride-along (if there is going to be a dot release). Leaving this exploitable until January 2018 isn't that great.

Comment 28

[Johann Hofmann [:johannh]]

I'm slightly concerned that we're missing some edge case that needs time/exposure to surface, but if more people are confident about this I wouldn't mind riding along on a dot release.

Comment 29

[Johann Hofmann [:johannh]]

Another thing to consider is that basic auth prompts can still be abused to achieve a similar effect, so I'm not sure this can be considered "fixing" the exploit.

Comment 31

[Samael Wang [:freesamael] (away for now)]

(In reply to Johann Hofmann [:johannh] from comment #29)
> Another thing to consider is that basic auth prompts can still be abused to
> achieve a similar effect, so I'm not sure this can be considered "fixing"
> the exploit.

I checked what other browsers are behaving. Chrome & Safari don't block UI on prompting basic auth, while Edge does.

Chrome puts the dialog just slightly above the web content area so web content can't make a fake dialog that looks exactly the same, and hide the dialog when user switches to other tabs. We might want to do something similar (making it nonmodal dialog and be hidden when switching to other tabs)

Comment 32

[Johann Hofmann [:johannh]]

(In reply to Samael Wang [:freesamael] from comment #31)
> (In reply to Johann Hofmann [:johannh] from comment #29)
> > Another thing to consider is that basic auth prompts can still be abused to
> > achieve a similar effect, so I'm not sure this can be considered "fixing"
> > the exploit.
> 
> I checked what other browsers are behaving. Chrome & Safari don't block UI
> on prompting basic auth, while Edge does.
> 
> Chrome puts the dialog just slightly above the web content area so web
> content can't make a fake dialog that looks exactly the same, and hide the
> dialog when user switches to other tabs. We might want to do something
> similar (making it nonmodal dialog and be hidden when switching to other
> tabs)

Yes, that's bug 613785 if I understand you correctly. There's also bug 1319984 for making a new dialog that overlaps chrome but doesn't block the browser.

Comment 40

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm confirming that bug is fixed, starting in Mozilla Firefox Nightly 58.0a1 (2017-11-10), so I'm marking this bug as VERIFIED.
Thank you very much! \o/

Tested with this URL:
> h00p://guardsurfingext.biz/ff/?_subid=1n1vnb246g6boigaj9m&_token=uuid_1n1vnb246g6boigaj9m_1n1vnb246g6boigaj9m5a43fe0c2028c0.70278801
change "h00p" part to "http"

Comment 45

[Zitronella]

with URL in Comment 40 it might be fixed. But it seems not be fixed with this URL h00p://ec2-35-166-77-50.us-west-2.compute.amazonaws.com/ge/1/66 in Firefox 58

Comment 46

[Johann Hofmann [:johannh]]

(In reply to Zitronella from comment #45)
> with URL in Comment 40 it might be fixed. But it seems not be fixed with
> this URL h00p://ec2-35-166-77-50.us-west-2.compute.amazonaws.com/ge/1/66 in
> Firefox 58

That's a different dialog which is tracked in bug 377496. There are a couple of these dialogs, unfortunately.