1661333 - [local files only] Get 2 beforeunload prompts instead of 1 when the page uses `location.href` assignment to navigate from 1 file: page to another

Status: NEW

(Core :: DOM: Navigation, defect, P3)

Description

[cristobal cordova]

Attachment: Vulnerability report.pdf

Sandbox Escaping in mozilla firefox
(developer edition Version)
Technical details about environment:
-version: 81.0b2

• build ID: 20200825191644
• Update Channel: aurora
• User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0)
  Gecko/20100101 Firefox/81.0
• OS: Windows_NT 10.0 18363
• Antivirus: Windows Defender
• Firewall: Firewall de windows
  Proof of concept : This vulnerability is relationed with the javascript
  interpreter and the moment when a user leaves a page. If the page
  javascript has some specific functions that will be detailed later, then
  basically display the confirm leaves page two times with a very small
  interval between them. The interesting thing occurs the second time that
  dialog is displayed because javascript keeps running not blocking like in
  the first time. What would allow executing time delays attacks.

Comment 1

[cristobal cordova]

Attachment: index.html

The html used in the proof of concept

Comment 2

[cristobal cordova]

Attachment: script.js

the script used by the html

Comment 3

[cristobal cordova]

Attachment: exploit.js

The exploit explaining the time delay attack executed in the firefox console

Comment 4

[cristobal cordova]

Probabily this is ocurring beacause exist a memory corruption issue

Comment 5

[Daniel Veditz [:dveditz]]

This looks like the kind of DOS we've got on file, and the reference to a published handbook increases that impression. Preventing people from leaving your page is not bypassing any "sandbox", it's just preventing people from leaving your page. A bug, a denial of service, but not otherwise damaging.

Comment 6

[:Gijs (he/him)]

It's not clear to me what the issue here is supposed to be. I saved the script.js and index.html file (the HTML file doesn't reference exploit.js, so this appears unused) locally. When I click the "start" button there's an error:

Uncaught TypeError: button is null

and otherwise nothing happens, so it doesn't work. I expect you meant to include the script after the button in the DOM, so that the button variable is correctly assigned.

If I do that, after clicking the button the beforeunload ("This page is asking you to confirm that you want to leave") dialog appears. But clicking "leave page" just works (we leave the page in question), and the script is paused while the dialog is up. So it's not clear to me what the "exploit" here is supposed to be.

The PDF really doesn't help either - you talk about the window.addEventListener("onbeforeunload", ... line, apparently unaware this handler isn't executing at all because the event name is incorrect...

Comment 7

[cristobal cordova]

Attachment: indexV2.html

Comment 8

[cristobal cordova]

Attachment: scriptV2.js

Comment 9

[cristobal cordova]

First of all thanks for the comments, now in the report I was thinking in make all demostration in console and it's how I tried on the image (what sounded good for time reasons), but how have I seen interested today in the morning I have rewritten the code with some changes so that the demo process is automated with only clicks on start button the new files are called indexV2 and scriptV2.

Comment 10

[cristobal cordova]

As an additional today my firefox dev was updated but the problem continues to occur.

Comment 11

[:Gijs (he/him)]

I can't reproduce when serving the page over http. The confirm dialog doesn't show up (which is correct because dialogs aren't allowed from within beforeunload handlers) and I just get the "This page is asking you to confirm that you want to leave - data you have entered may not be saved." beforeunload prompt - but only once. If I click "leave page" then the relative path www.othersite.com tries to load.

I can only reproduce when I load the page over file:. Then I get 2 prompts, but after the second prompt it does open file:///..../www.othersite.com/. That's not really a security bug per se, and definitely not exploitable given that there's no direct way for the web to make you open file: pages anyway.

The same thing doesn't happen when linking to http pages from the file page, either.