Closed Bug 724353 (CVE-2016-1937) Opened 12 years ago Closed 9 years ago

protocol handler dialog does not resist ui timing attacks

Categories

(Toolkit :: UI Widgets, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla44
Tracking Status
firefox44 --- verified

People

(Reporter: chrometot, Assigned: Felipe)

References

Details

(Keywords: sec-moderate, Whiteboard: [sg:moderate][adv-main44+])

Attachments

(1 file, 1 obsolete file)

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
bug 162020 back to haunt us
Blocks: 162020, 385065
Status: UNCONFIRMED → NEW
Component: Untriaged → File Handling
Ever confirmed: true
Product: Firefox → Core
QA Contact: untriaged → file-handling
Whiteboard: [sg:moderate]
Version: 10 Branch → unspecified
Summary: url handle risk → protocol handler dialog does not resist ui timing attacks
Assignee: nobody → felipc
Status: NEW → ASSIGNED
Group: core-security → dom-core-security
Group: dom-core-security → toolkit-core-security
Component: File Handling → XUL Widgets
OS: Windows 7 → All
Product: Core → Toolkit
Hardware: x86_64 → All
Attached patch patch (obsolete) — Splinter Review
Attachment #8671128 - Flags: review?(dtownsend)
Comment on attachment 8671128 [details] [diff] [review]
patch

Scratch this request, a new patch will use the same code from bug 1116385
Attachment #8671128 - Attachment is obsolete: true
Attachment #8671128 - Flags: review?(dtownsend)
Using the EnableDelayHelper protects not only against the initial window open, as described in the report, but also against the refocus timeout.
Attachment #8671167 - Flags: review?(dtownsend)
EnableDelayHelper comes from bug 1116385
Depends on: CVE-2016-1941
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|?
Attachment #8671167 - Flags: review?(dtownsend) → review+
(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
https://hg.mozilla.org/mozilla-central/rev/a512e6266d05
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Group: toolkit-core-security → core-security-release
 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?
Flags: needinfo?(felipc)
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.
Flags: needinfo?(felipc)
Whiteboard: [sg:moderate] → [sg:moderate][adv-main44+]
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.
Status: RESOLVED → VERIFIED
Alias: CVE-2016-1937
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.