724353 - (CVE-2016-1937) protocol handler dialog does not resist ui timing attacks

Status: VERIFIED FIXED

(Toolkit :: UI Widgets, defect)

Description

[window]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.3 Safari/535.19

Steps to reproduce:


<a href="telnet://127.0.0.1" style="postion:somewhere">Double-clicking me</a>


http://www.opera.com/support/kb/view/823/

Links in Web pages only require a single click. When a user double-clicks on a Web link, that action is taken as two separate clicks: One to follow the link, and the other to any dialog that might appear where the link was.

you did not do the url-handle UI same as download UI


Actual results:

telnet: is allowed


Expected results:

disabled the button for seconds

Comment 1

[Daniel Veditz [:dveditz]]

bug 162020 back to haunt us

Comment 2

[:Felipe Gomes (needinfo for replies!)]

Attachment: patch

Comment 3

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 8671128 [details] [diff] [review]
patch

Scratch this request, a new patch will use the same code from bug 1116385

Comment 4

[:Felipe Gomes (needinfo for replies!)]

Attachment: part 3 - handlingdialog-new

Using the EnableDelayHelper protects not only against the initial window open, as described in the report, but also against the refocus timeout.

Comment 5

[:Felipe Gomes (needinfo for replies!)]

EnableDelayHelper comes from bug 1116385

Comment 6

[Dave Townsend [:mossop]]

Comment on attachment 8671167 [details] [diff] [review]
part 3 - handlingdialog-new

Review of attachment 8671167 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/mozapps/handling/content/dialog.js
@@ +86,5 @@
>  
>      // UI is ready, lets populate our list
>      this.populateList();
> +
> +    this._delayHeler = new EnableDelayHelper({

s/delayHeler/delayHelper/

Also do you actually need to retain this on |this|?

Comment 7

[:Felipe Gomes (needinfo for replies!)]

(In reply to Dave Townsend [:mossop] from comment #6)
> Also do you actually need to retain this on |this|?

I think it's not actually necessary due to the event listeners holding to the object, but it's the kind of thing that when testing it's hard to guarantee that it worked not just on coincidence.. So I'm playing it safe

Comment 8

[:Felipe Gomes (needinfo for replies!)]

https://hg.mozilla.org/integration/fx-team/rev/aaade64d3f28

Comment 9

[Phil Ringnalda (:philor)]

Backed out in https://hg.mozilla.org/integration/fx-team/rev/9fce08491c53 for the Linux-only https://treeherder.mozilla.org/logviewer.html#?job_id=5091855&repo=fx-team

Comment 10

[:Felipe Gomes (needinfo for replies!)]

https://hg.mozilla.org/integration/fx-team/rev/a512e6266d05

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/a512e6266d05

Comment 12

[Mihai Boldan, Desktop QA [:mboldan]]

 I've tested this issue on Windows 10 x86, using the STR form Comment 0 and as an actual result, two 'Launch Application' popups are displayed.
I think that this is not the expected behavior.
Also, the STR from Comment 0 are not applicable on Ubuntu 14.04 x64 OS(an error is displayed after clicking the Double-click link) and the issue is not reproducible on Mac OS X 10.10.5, using FF 5.0 and FF 44.0b8. 
Can you please give me more information about this issue if I misunderstood it?

Comment 13

[:Felipe Gomes (needinfo for replies!)]

I think that the opening of two popups is fine, it depends on whether the speed of the two clicks (whether it was considered a double click or not).

The issue here was the following: when you click that link on a webpage, the Launch Application dialog appears.  When the dialog shows up, if the mouse cursor falls exactly on top of the OK button from the dialog, a user who clicks quickly again might not realize that they will click the OK button, the dialog will quickly disappear and the application will launch.

So the solution was to show the "Launch Application" dialog initially with the OK button disabled, and only enable it after a delay time.

Comment 14

[Mihai Boldan, Desktop QA [:mboldan]]

I managed to reproduce this issue on Firefox 42.0a1 (20150802030218) and on Windows 10 x86.
Verified fixed on Firefox 44.0 RC and on Firefox 46.0a1 (2016-01-19), using Windows 10 x86 and Mac OS X 10.10.5.