pop up XPInstall/security dialog when user is about to click

RESOLVED FIXED

Status

()

Core
Security
--
major
RESOLVED FIXED
15 years ago
3 years ago

People

(Reporter: Jesse Ruderman, Assigned: dveditz)

Tracking

(Depends on: 1 bug, {fixed-aviary1.0, fixed1.4.3, verified1.7})

Trunk
x86
Windows 2000
fixed-aviary1.0, fixed1.4.3, verified1.7
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7b -
blocking1.7 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix])

Attachments

(3 attachments, 1 obsolete attachment)

3.73 KB, text/html
Details
879 bytes, text/html
Details
11.23 KB, patch
Christopher Aillon (sabbatical, not receiving bugmail)
: approval1.4.3+
chris hofmann
: approval1.7+
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
If I can control or predict when and where a user will click, I can get them to
install software.  That's not surprising, but it didn't seem to be in Bugzilla.
 It probably hadn't been filed because most of possible fixes suck and/or
because nobody had come up with a good exploit.

How can I control or predict when and where a user will click?

1. A game.
  1a. Make the player "pick up" items by clicking them.  Measure the speed with
which the player moves the mouse and clicks, and once the speed stabilizes, pop
up an install dialog just before the player clicks.
  1b. Force the player to click at exactly the right time: a reaction-time test,
shoot the monkey, etc.
  1c. Convince the player to double-click an object whose location I control.
  1d. Tell the player that he has infinite ammo and can shoot by pressing or
holding the 'i' button on the keyboard.  Pop up an install dialog when the
player runs out of ammo.

2. Pop-up hell.
  2a. Make the 'x' for the pop-up ad appear just where a security dialog will
appear.
  2b. Make fake pop-ups out of images so you can measure the victim's reaction
time, average mouse acceleration, etc.  Get them on the fifth "pop-up".

I will attach a demo of 1c, a game that involves double-clicking.


Possible fixes, all of which suck:

A) When a site tries to install software or calls enablePrivilege, display a
status bar message, "This page would like to install software on your computer".
 Only display the dialog after the user clicks the status bar message.  (Err,
how do you click a status bar message with the keyboard?)

B) Add a one-second delay between when the dialog gets focus and when the
Install/OK button becomes enabled.  I say "gets focus" rather than "appears"
because a site could hide an install dialog as a modal dialog of a background
window for a minute and then bring the dialog to the front at a convinient time
by closing the window in front.

C) If the total time to decide to install and download the xpi are less than
five seconds, stall installation (with the "downloading..." dialog still up)
until five seconds are up so the user has an extra chance to cancel.  I'm
worried that users might not know to cancel because they do not realize that
they accidentally clicked "install" in a dangerous dialog.

B and C both involve timers, which might be bad for accessibility
(http://www.w3.org/TR/2001/CR-UAAG10-20010912/guidelines#tech-time-independent).
(Reporter)

Comment 1

15 years ago
Created attachment 94712 [details]
demo: double-click game

Demo for 1c on Windows 2000 (classic or modern skin).  The third time you play
this game, it pops up an enablePrivilege dialog on the first click of a
double-click.  You have to load this demo from file:/// because I used
enablePrivilege rather than install or install-skin.
(Reporter)

Comment 2

15 years ago
Of the possible solutions I mentioned in comment 0, I prefer B, disable the
Install/Ok button for about a second when the dialog gains focus.
(Reporter)

Comment 3

15 years ago
Dveditz suggested:

D) Open confirm dialogs in a random spot on the screen.

That would not be a complete solution.  It would introduce randomness instead of
making the exploit impossible, and it would not fix keyboard versions of the
exploit ("hold i to fire your weapon", "how quickly and accurately can you
delete hotmail spam? try using tab and space instead of the mouse", etc).  I'm
also not convinced that opening a dialog in a random location (making Mozilla
look buggy) is better UI for non-malicious sites than disabling the Install
button for a second (making Mozilla look slow).

I don't think it's possible to fix this hole without introducing some kind of
delay (B or C), reserving space or shortcuts for making a dangerous dialog to
appear (A), or reserving space or shortcuts for the Install button.
I like the delay solution.

I'm not sure that this bug needs to be closed. The issue applies to all
browsers, is not trivial to exploit, requires user interaction so it's not
wormable, and requires the user to visit an evil HTML page. Wider feedback on
possible solutions would also be useful.
Whiteboard: [sg:openended]
OTOH, this is exactly the sort of thing that gives bad people bad ideas. Let's
keep it private for now, and move further public/private discussion to the
security group mailing list. There's definitely some fixes we could pursue here.

Can someone check IE's behavior and see if they do anything to mitigate this? Jesse?
(Reporter)

Comment 6

15 years ago
> requires user interaction so it's not wormable

A mail worm/virus (?) exploiting this hole would not spread as effectively as
one exploiting a hole that requires no user interaction, but it could still
infect a large number of computers.

> Can someone check IE's behavior and see if they do anything to mitigate this?

The Teoma search bar can be uninstalled and reinstalled quickly.  I tried the
following at http://sp.ask.com/docs/teoma/toolbar/index.php:

a) Press "y" on the keyboard as quickly as I can react after the dialog appears.
b) Click "Yes" as quickly as I can react after the dialog appears.
c) Click repeatedly where the "Yes" button will appear and *stop* clicking if I
notice the dialog before I've already accepted it.

In all three cases, the Teoma search bar was installed.  So IE doesn't seem to
do anything to mitigate this kind of attack beyond requiring ActiveX code to be
signed.
Let's add a checkbox to the XPInstall dialog, essentially saying "yes, I really
want to do this." That way, initiating an install is a two-click process. 

Over to Dan for comment.
Assignee: mstoltz → dveditz
(Assignee)

Comment 8

15 years ago
Sorry, I'll take dancing pigs over a checkbox.

I like the delay idea better, or opening the dialog in a random spot on the
screen. When Dougt lands signed XPI support soon he'll be effectively adding the
delay while we download enough of the archive to see if it's got a signature.
Would that be good enough? Perhaps not on a fast connection, but let's land that
first and see.
(Reporter)

Comment 9

15 years ago
Adding a checkbox would not fix the keyboard variant of the exploit from comment
3: "how quickly and accurately can you delete hotmail spam? try using tab and
space instead of the mouse".

The delay introduced by "signed XPI" will vary between computers, so I don't see
why we're waiting for that to be fixed before fixing this security hole.
We're not going to achieve a perfect solution here that doesn't seriously hamper
usability or just make us look dumb. Let's not reject a reasonable 80% solution
simply becasue it isn't 100%. I still think an additional checkbox will go a
long way towards preventing accidental installs and is not as annoying as a
delay, but maybe we should get the input of a UE person.
(Reporter)

Comment 11

15 years ago
I think a delay would be both more effective and less annoying than a checkbox
for fixing this security hole.
(Reporter)

Updated

14 years ago
Summary: pop up install dialog when user is about to click → pop up XPInstall dialog when user is about to click
(Reporter)

Updated

14 years ago
Flags: blocking1.7a?

Comment 12

14 years ago
looks like no patch yet, but maybe we can make some progress in 1.7beta..
Flags: blocking1.7b?
Flags: blocking1.7a?
Flags: blocking1.7a-
(Reporter)

Comment 13

14 years ago
Ben (mostly?) fixed this for Firefox's XPI dialog in bug 236056.
(Reporter)

Comment 14

14 years ago
I reported similar bugs to Opera and Microsoft (for IE).

Comment 15

14 years ago
can someone drum up a patch with a delay?

Updated

14 years ago
Flags: blocking1.7b?
Flags: blocking1.7b-
Flags: blocking1.7?
(Reporter)

Comment 16

13 years ago
These people noticed the 2-second delay for installing Firefox extensions and
weren't angry about it: http://bugzilla.mozilla.org/show_bug.cgi?id=229600#c34.
 They also didn't figure out the exact security hole -- they thought the purpose
of the delay was to encourage users to start reading the text in the dialog
before clicking.  I guess that's a good side effect of the fix :)
(Reporter)

Comment 17

13 years ago
I think the Firefox XPI fix left open a variation of the expoit:
http://bugzilla.mozilla.org/show_bug.cgi?id=236056#c3

Comment 18

13 years ago
My suggestion is to prevent _all_ xpinstalls from being run if they do not have
a valid signature.  
That still won't eliminate the problem. Crooks can start signing xpis.
(Reporter)

Comment 20

13 years ago
Requiring XPIs to be signed -> bug 238960
(Reporter)

Updated

13 years ago
Depends on: 239411
(Reporter)

Comment 21

13 years ago
(In reply to comment #17)
> I think the Firefox XPI fix left open a variation of the expoit:
> http://bugzilla.mozilla.org/show_bug.cgi?id=236056#c3

I filed bug 239411 for the variation.

Comment 22

13 years ago
regarding #19 -- the crooks will need to get a signing cert from a trusted CA.
self-signed certs are treated as unsigned in xpinstall.
(In reply to comment #22)
> regarding #19 -- the crooks will need to get a signing cert from a trusted CA.
> self-signed certs are treated as unsigned in xpinstall.

Ok, thanks for the clarification. I thought it would present the user with the
normal "unrecognized certificate, do you want to trust it" dialog.

Getting a certificate from a trusted CA certainly raises the bar to make an
exploit using signed XPI, although there have been cases in the past where
people have fooled the CAs to give certificates they shouldn't have. We can't
really do anything about that, though.
(Reporter)

Comment 24

13 years ago
CAs verify your identity, not your trustworthiness.  It's very hard to get a
CA-signed certificate saying that you're Microsoft, but it's easy to get a
CA-signed certificate saying that you're you, which is sufficient for getting
around a fix for bug 238960 in order to exploit this bug.  Therefore, bug 238960
is orthogonal to this bug.
(Reporter)

Comment 25

13 years ago
Created attachment 145416 [details]
demo: fake captcha

Like attachment 94712 [details], this attacks the script-permissions dialog, so you must
enable codebase principles or save to disk to test.  A real attacker would sign
the script, serve it from https, or attack the XPI dialog instead.
(Reporter)

Comment 26

13 years ago
I plan to disclose this security hole soon after both Mozilla 1.7 (~May 12) and
Firefox 0.9 have been released.

Recap:
* Impact: Arbitrary code execution.
* Ease of exploitation: Must convince visitor to do one of the following:
    o Click at specific place, time   [game: shoot the monkey]
    o Double-click at specific place  [game: clicking speed, attachment 94712 [details]]
    o Press tab-space                 [game: spam deletion]
    o Hold down 'y'                   [game: shooting]
    o Type a word containing 'y'      [captcha, attachment 145416 [details]]
* Affects: Seamonkey and Firefox (script permissions), Seamonkey (XPI), IE
(ActiveX), Opera.

I think all that remains to be done to fix the security hole is:
* Prevent a variation in the attack that Ben Goodger's fix for Firefox XPIs
missed (bug 239411).
* Make script-permission dialogs and Seamonkey XPI dialogs have the same delay
behavior as Firefox XPI dialogs (this bug).

Comment 27

13 years ago
I would argue that an install that is from some known and verified identity is
less likely to be malicious.
(Reporter)

Comment 28

13 years ago
Ccing aebrahim@uchicago.edu, QA for bug 239411, so he can see this bug too.
(Reporter)

Comment 29

13 years ago
Doug: that strategy (require installable code to be signed but don't do much
else to prevent malicious code from being installed) didn't work for IE.  Lots
of spyware is distributed through ActiveX.  Even if bug 238960 were fixed (I
think it shouldn't be), not fixing *this* bug would mean leaving open an
arbitrary code execution hole to anyone with a CA-signed certificate.

Comment 30

13 years ago
I think we should work to get, at minimum, the "solution" that firefox has
implemented ported to SeaMonkey for 1.7. Who can help add the delay and timer
countdown UI to seamonkey's dialog?
Flags: blocking1.7? → blocking1.7+

Updated

13 years ago
Flags: blocking1.7a-

Comment 31

13 years ago
firefox work is available at:
http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/xpinstall/content/xpinstallConfirm.js
http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/xpinstall/locale/xpinstallConfirm.properties

Comment 32

13 years ago
dougt might have a line on a fix for this.
Assignee: dveditz → dougt

Comment 33

13 years ago
asa, ben's solution doesn't work.  see bug 239411.
(Assignee)

Comment 34

13 years ago
One comment about the "Firefox solution". We could do that with the Suite
XPInstall dialog since it's also XUL, but if you look at the actual test cases
here you can see that the security dialogs are just as big a problem, if not
bigger. Those dialogs are brought up using the frozen nsIPromptService interface
which is not as easy to address.

CC'ing mkaply who was recently talking about ConfirmEx()

Comment 35

13 years ago
There are enough bits in the ConfirmEx code that we could add one to enable this
behavior and put the change in commondialog.js. That's assuming people want this
behavior for all security related dialogs.

XPI dialog has always been its own XUL.

Comment 36

13 years ago
time is short for 1.7.  we need to figure out what to do here.

Updated

13 years ago
Whiteboard: [sg:openended] → [sg:openended] still evaluating
(Assignee)

Comment 37

13 years ago
Taking back from dougt
Assignee: dougt → dveditz
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
Whiteboard: [sg:openended] still evaluating → [sg:fix]
(Assignee)

Comment 38

13 years ago
Created attachment 149817 [details] [diff] [review]
delay enabling buttons in XPInstall and security dialogs

This patch causes a 2 second delay before the security and xpinstall dialog
buttons are enabled. The delay time is pref-adjustable. This does not address
the attack described in bug 239411

Firefox appears to have its own copy of the commonDialogs which will need to be
patched.
(Assignee)

Updated

13 years ago
Attachment #149817 - Flags: superreview?(sspitzer)
Attachment #149817 - Flags: review?(mkaply)

Comment 39

13 years ago
Comment on attachment 149817 [details] [diff] [review]
delay enabling buttons in XPInstall and security dialogs

r=mkaply

We need to update the IDL to document these new attributes, though, for
embeddors.
Attachment #149817 - Flags: review?(mkaply) → review+
(Assignee)

Updated

13 years ago
Whiteboard: [sg:fix] → [sg:fix] need sr=
Comment on attachment 149817 [details] [diff] [review]
delay enabling buttons in XPInstall and security dialogs

sr=sspitzer
Attachment #149817 - Flags: superreview?(sspitzer) → superreview+
because we are talking about 1.7, can we ask jesse to also review and test?

also, does this mean we have to change the iids for those interfaces, or am I
not understanding darin's recent suggestions?
(Reporter)

Comment 42

13 years ago
Comment on attachment 149817 [details] [diff] [review]
delay enabling buttons in XPInstall and security dialogs

"Disabled by default" should be something like "disabled initially".

It looks like this patch also disables the cancel button.  The cancel button
should always be enabled.

The first parameter to setTimeout should be reenableInstallButtons, not the
string "reenableInstallButtons()".

security.dialog_focus_delay should be security.dialog_enable_delay
Whiteboard: [sg:fix] need sr= → [sg:fix] have r/sr, need to address review comments from jesse
(Assignee)

Comment 43

13 years ago
Created attachment 150067 [details] [diff] [review]
Address Jesse's comments for check-in

This version incorporates Jesse's comments. The changes are trivial enough that
I'm not going to seek re-review but I wanted to attach it to make it easier for
someone other than me to land this correctly on the AVIARY branch.
Attachment #149817 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #150067 - Flags: review?(jruderman)
Attachment #150067 - Flags: approval1.7?
(Assignee)

Comment 44

13 years ago
fixed on trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Whiteboard: [sg:fix] have r/sr, need to address review comments from jesse → [sg:fix] need a=

Comment 45

13 years ago
Comment on attachment 150067 [details] [diff] [review]
Address Jesse's comments for check-in

a=chofmann for 1.7
Attachment #150067 - Flags: approval1.7? → approval1.7+
(Assignee)

Comment 46

13 years ago
Fixed on 1.7 branch
Keywords: fixed1.7
Whiteboard: [sg:fix] need a= → [sg:fix]
(Assignee)

Comment 47

13 years ago
The firefox version of this bug fixed only the install dialog. FF still needs to
incorporate the security dialog fix.
Summary: pop up XPInstall dialog when user is about to click → pop up XPInstall/security dialog when user is about to click
Whiteboard: [sg:fix] → [sg:fix] needed-aviary1.0
(Assignee)

Comment 48

13 years ago
Adding Jon Granrose to CC list to help round up QA resources for verification

Comment 49

13 years ago
adding dave to verify on 1.7
I landed this patch on the Aviary 1.0 branch, but do there still need to be
additional changes needed to files that Firefox forked?
Whiteboard: [sg:fix] needed-aviary1.0 → [sg:fix] needed-aviary1.0?
(Assignee)

Comment 51

13 years ago
One of the files patched is mozilla/xpfe/global/resources/content/commonDialog.js

I think this would need to go into mozilla/toolkit/content/commonDialog.js
instead, assuming from the name that that's the equivalent spot.

Comment 52

13 years ago
Tested with the 1.7 branch on Win2000. When using the Nuke program, get the
confirm dialog "A script from 'file://' has requested UniversalXPConnect
privileges ... Do you wish to allow these privileges?" If Yes, then we get
[object nsXPCComponent_Classes] each time clicking the target. There is a delay
when the Yes button is enabled again. If No, get "A script from 'file://' was
denied UniversalXPConnect privileges" each time. This is working correctly.

Similar thing when testing Captcha independently. After two letters of the word
is entered in the verification screen, get the same confirm dialog. If No, get
"privilege not granted". But regardless of whether Yes or No is selected, once
the entire word is entered, and pressing the button, get the security warning
dlog: "The information you have entered is to be sent over an unencrypted
connection and could easily be read by a 3rd party? Continue or Cancel." Sound
correct?

The "remembering the decision" setting works fine.

Updated

13 years ago
Keywords: fixed1.7 → verified1.7
(Reporter)

Updated

13 years ago
Group: security

Comment 53

13 years ago
Verified on Mozilla trunk. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.8a2) Gecko/20040623
BTW, JS tip o' the day.  From the game in the first attachment:

function setResults(a,b,c,d)
{
    results = document.getElementById("results");
    results.rows[0].cells[1].innerHTML = a ? a : "You call that a double-click?";
    results.rows[1].cells[1].innerHTML = b ? b : "Dud";
    results.rows[2].cells[1].innerHTML = c ? c : "Undamaged";
    results.rows[3].cells[1].innerHTML = d ? d : "$50";
}

Those ?: expressions should just use ||, which like && in JS preserves deciding
operand value (after Perl).

/be

Comment 55

13 years ago
I see this bug has recently been unhidden. To thwart the "keep pressing the 'I'
key..." attacks, how about making the XPI dialog non-modal and keeping the focus
on the parent window even after the XPI dialog has popped up? So in effect, any
keystrokes would remain being sent to the HTML window. The only way to bring
focus to the XPI dialog would be to click on it or to ALT+TAB to it.
Comment on attachment 150067 [details] [diff] [review]
Address Jesse's comments for check-in

a=blizzard for 1.4.3
Attachment #150067 - Flags: approval1.4.3+
Keywords: fixed1.4.3

Comment 57

13 years ago
Note: The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0762 to this issue.

Comment 58

13 years ago
/toolkit version checked in ala bug 253945, trunk and branch
Keywords: fixed-aviary1.0
Whiteboard: [sg:fix] needed-aviary1.0? → [sg:fix]
(Assignee)

Updated

13 years ago
Attachment #150067 - Flags: review?(jruderman)
(In reply to comment #42)
> security.dialog_focus_delay should be security.dialog_enable_delay

Jesse, your mentioned pref doesn't work for AVIARY builds. You can set any value
you want but there is an delay of three seconds every time. I've opened bug
245737 a time ago which handles the not working pref setting for Firefox.
Blocks: 245737
(Assignee)

Comment 60

13 years ago
The firefox security dialog does respect the delay pref. Firefox fixed their
version of the install dialog in bug 236056 before we created the delay pref.

Bug 245737 is an appropriate firefox bug, but it doesn't depend on this one. The
"fixed-aviary1.0" keyword refers to the security dialog change since, as
mentioned, Firefox had already fixed bug 236056
No longer blocks: 245737

Comment 61

12 years ago
I know this is rather old, but I thought I should add my 2 cents. Randomizing the access keys and ensuring the dialog isn't placed under the mouse cursor would essentially prevent this, except for "see how fast you can close popups" sort of games where the popups have the same layout as the install dialog. However, more importantly, on the off chance the user is tricked into installing something, the extension is disabled until FF is restarted - simply keeping the dialog on the screen with an option to uninstall immediately would allow the malicious extension to be removed without ever being executed.
(Assignee)

Comment 62

12 years ago
(In reply to comment #61)
> Randomizing the access keys and ensuring the dialog isn't placed under the
> mouse cursor would essentially prevent this,

Unless the attacker is doing keystroke games as in the similar just-patched Explorer vulnerability http://secunia.com/secunia_research/2005-7/advisory/

> However, more importantly, on the off chance the user is tricked into
> installing something, the extension is disabled until FF is restarted -
> simply keeping the dialog on the screen with an option to uninstall
> immediately would allow the malicious extension to be removed without ever
> being executed.

Attacker could (and therefore would) get around that by using an old-style .xpi which executes install.js immediately.

For essentially the same thing in Explorer see
http://secunia.com/secunia_research/2005-21/advisory/ (mouseclick)
(Reporter)

Comment 63

12 years ago
IE6 in WinXP SP2 now disables the "Run" button for about a second when you click a link to download an exe file.  It isn't visibly disabled, and it even depresses if you click it, but it isn't active during that period.

Comment 64

11 years ago
I filed bug 359475 as a follow-up to this, for those who may be interested.
(Reporter)

Comment 65

11 years ago
I filed bug 363142 describing some of the shortcoming of the "delay enabling the Install button" solution and suggesting alternatives.
(Reporter)

Updated

6 years ago
Depends on: 616100
(Assignee)

Updated

5 years ago
Depends on: 724353
(Assignee)

Updated

3 years ago
Depends on: 1003674
(Assignee)

Updated

3 years ago
Depends on: 998873
You need to log in before you can comment on or make changes to this bug.