1549834 - External protocol dialog should be closed on navigation

Status: RESOLVED FIXED

(Firefox :: File Handling, defect, P3)

Description

[James Lee]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36

Steps to reproduce:

We are able to run arbitrary URI Scheme by tricking users with additional bug.

We are able to trick user to run URI which allows arbitrary command such like jarfile://, Python.File:// etc.

Test on: http://pwning.click/ffredir.php

Actual results:

Firefox allows to run arbitrary URI with command, we could trick users with additional bug.

Expected results:

Firefox does not allow to run arbitrary URI with command. Link with URI should be disappeared after site is redirected to Cross-Origin site, so attackers can not trick user to run arbitrary URI by nearly no user interaction. (pressing on Enter key)

Comment 1

[:Gijs (he/him)]

Sorry, how is the enter keypress relevant here compared to bug 1549833 ?

Comment 2

[James Lee]

the prompt will not close even after Cross-Origin redirection, neither URI link opener "Launch Application". I just used this bug as an additional trigger to minimize user interaction.

Comment 3

[:Gijs (he/him)]

For context:

(In reply to James Lee from bug 1549834 comment #3)

Chrome allows to open res:// but prompts opener which has default on set on "cancel" but not open button. Also, Chrome's URI opener disappears when page is redirected to Cross-Origin site, while Firefox's Launch Application opens normally with default set on "open link" button after Cross-Origin redirection.

For me, the button is disabled for a second or two when the dialog opens. Are you not seeing that? Or does [enter] accept the dialog in spite of the button looking disabled? Or something else?

Comment 4

[James Lee]

After the dialog opened, prompt covers the dialog in chrome. Please have a test on following url for chrome: https://pwning.click/chromeres.php

the default set is not on "Open Internet Explorer" but "Cancel" so enter won't let IE to run.

Comment 5

[Daniel Veditz [:dveditz]]

I'm not even getting a dialog from the testcase, I just go to Google.com. Did the testcase change?

Comment 6

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #5)

I'm not even getting a dialog from the testcase, I just go to Google.com. Did the testcase change?

At least for me it still has:

<script>setTimeout(function(){window.open("res://ieframe.dll/navcancl.htm#javascript:alert(1)", "_self");}, 900);</script>

If you're not on an OS that has a res: handler (ie windows), nothing might happen, and if you're on today's nightly, bug 1549833 being fixed blocks that completely.

The general issue remains though - we could improve the protocol handling stuff.

Comment 7

[James Lee]

(In reply to Daniel Veditz [:dveditz] from comment #5)

I'm not even getting a dialog from the testcase, I just go to Google.com. Did the testcase change?

Please test on Firefox stable release but not nightly or beta.

Comment 8

[James Lee]

Attackers are able to convince user to click enter which results to run URI schemes, could allow privileged command execution without knowing. I believe this is different issue to https://bugzilla.mozilla.org/show_bug.cgi?id=1549833

Comment 9

[:Gijs (he/him)]

I think this is fixed on nightly and beta through bug 1552627. Can you re-test beta/nightly and see how you feel about the mitigations?

Comment 10

[James Lee]

Hi, I just changed the source code of ffredir.php for this test case since res:// is blocked after update. I tested on nightly but it seems like explained behavior is not fixed yet. Test on: http://pwning.click/ffredir.php

URI confirmation pop-up is still present after redirecting to google site. Besides, I can not view bug 1552627.

Comment 11

[:Gijs (he/him)]

(In reply to James Lee from comment #10)

Hi, I just changed the source code of ffredir.php for this test case since res:// is blocked after update. I tested on nightly but it seems like explained behavior is not fixed yet. Test on: http://pwning.click/ffredir.php

URI confirmation pop-up is still present after redirecting to google site. Besides, I can not view bug 1552627.

OK, this wasn't what I understood this issue to be about - I thought the "point" was how easy it was to trick users into accepting the dialog by pressing enter and/or starting to keypress before the dialog showed up (irrespective of whether there was a navigation to another site). Both of those should be fixed now.

We can morph this to be about closing the dialog on navigation, but frankly that seems less important. It also has web compatibility implications...

Comment 12

[James Lee]

yes, this issue was about that too. I included this since combining with this behavior would be more convincing. Is this issue assigned as sec-low? do I also get credit for this bug since I reported earlier? (assuming this from bug id)

Comment 13

[James Lee]

as the initial report says, I used svg prompt bug to convince user to click Enter button.

Comment 14

[James Lee]

I just confirmed that clicking Enter from http://pwning.click/ffredir.php doesn't open URI handler anymore. This issue has been fixed in Nightly / Beta.

Comment 15

[:Gijs (he/him)]

(In reply to James Lee from comment #13)

as the initial report says, I used svg prompt bug to convince user to click Enter button.

None of the comments here mention SVG so I don't know what this means...

Comment 16

[James Lee]

https://bugzilla.mozilla.org/show_bug.cgi?id=1539757

original source of ffredir.php is saved at ffredir2.php:

<script>setTimeout(function(){location='//google.com'}, 1000);</script>
<script>setTimeout(function(){window.open("res://ieframe.dll/navcancl.htm#javascript:alert(1)", "_self");}, 900);</script>
<svg onload="prompt('Keep the Enter key pressed down to close this message')"/><svg onload="prompt('Keep the Enter key pressed down to close this message')"/>

Comment 17

[James Lee]

So apparently no one other than me tested / reproduced this report when bugs were alive :-(

I should have added more specific details on this report but I forgot to do so.

Comment 18

[:Gijs (he/him)]

(In reply to James Lee from comment #17)

So apparently no one other than me tested / reproduced this report when bugs were alive :-(

No, lots of people did.

I should have added more specific details on this report but I forgot to do so.

But this was the problem. I assumed that however you chose to pop up alert dialogs to convince the user to press enter wasn't relevant. while (true) { alert(...) } would have done the trick just as well - or a textarea overlaid with a custom message to encourage the user to keep holding down enter, or...

Do you believe the svg onload behaviour is a separate bug? If so, please file it separately (probably not really a security bug).

Comment 19

[James Lee]

that bug is fixed on stable ff. About clicking enter, (ok is on default on ff but cancel is on default on chrome) I mentioned on https://bugzilla.mozilla.org/show_bug.cgi?id=1549833#c3

Comment 20

[:Gijs (he/him)]

(In reply to James Lee from comment #19)

that bug is fixed on stable ff.

Sorry, what bug is this? The svg onload thing? Are you saying this got fixed in Firefox 67 and was broken on 66? Is it also fixed on current nightly?

At the moment, I'm still not clear on what the SVG onload issue even is, so I can't check if/how it was fixed, nor ensure it doesn't regress in future...

Comment 21

[James Lee]

yes, svg script bug is fixed in all ff. I described on https://bugzilla.mozilla.org/show_bug.cgi?id=1549833#c3 about the ff's default is open link problem

Comment 22

[James Lee]

also mentioned https://bugzilla.mozilla.org/show_bug.cgi?id=1539757 for fixed svg bug.

Comment 23

[Daniel Veditz [:dveditz]]

Nominating for a security bug bounty at the reporter's request

Comment 24

[Daniel Veditz [:dveditz]]

This sec-low bug does not qualify for a bounty award.

Comment 25

[:Gijs (he/him)]

I fixed this in bug 1606797.