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

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[Jesse Ruderman]

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).

Comment 1

[Jesse Ruderman]

Attachment: 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.

Comment 2

[Jesse Ruderman]

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.

Comment 3

[Jesse Ruderman]

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.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 5

[Mitchell Stoltz (not reading bugmail)]

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?

Comment 6

[Jesse Ruderman]

> 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.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 8

[Daniel Veditz [:dveditz]]

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.

Comment 9

[Jesse Ruderman]

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.

Comment 10

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 11

[Jesse Ruderman]

I think a delay would be both more effective and less annoying than a checkbox
for fixing this security hole.

Comment 12

[chris hofmann]

looks like no patch yet, but maybe we can make some progress in 1.7beta..

Comment 13

[Jesse Ruderman]

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

Comment 14

[Jesse Ruderman]

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

Comment 15

[chris hofmann]

can someone drum up a patch with a delay?

Comment 16

[Jesse Ruderman]

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 :)

Comment 17

[Jesse Ruderman]

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

[Doug Turner (:dougt)]

My suggestion is to prevent _all_ xpinstalls from being run if they do not have
a valid signature.  

Comment 19

[Heikki Toivonen (remove -bugzilla when emailing directly)]

That still won't eliminate the problem. Crooks can start signing xpis.

Comment 20

[Jesse Ruderman]

Requiring XPIs to be signed -> bug 238960

Comment 21

[Jesse Ruderman]

(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

[Doug Turner (:dougt)]

regarding #19 -- the crooks will need to get a signing cert from a trusted CA.
self-signed certs are treated as unsigned in xpinstall.

Comment 23

[Heikki Toivonen (remove -bugzilla when emailing directly)]

(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.

Comment 24

[Jesse Ruderman]

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.

Comment 25

[Jesse Ruderman]

Attachment: 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.

Comment 26

[Jesse Ruderman]

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

[Doug Turner (:dougt)]

I would argue that an install that is from some known and verified identity is
less likely to be malicious.

Comment 28

[Jesse Ruderman]

Ccing [e-mail], QA for bug 239411, so he can see this bug too.

Comment 29

[Jesse Ruderman]

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

[Asa Dotzler [:asa]]

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?

Comment 31

[Asa Dotzler [:asa]]

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

[chris hofmann]

dougt might have a line on a fix for this.

Comment 33

[Doug Turner (:dougt)]

asa, ben's solution doesn't work.  see bug 239411.

Comment 34

[Daniel Veditz [:dveditz]]

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

[Mike Kaply [:mkaply]]

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

[chris hofmann]

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

Comment 37

[Daniel Veditz [:dveditz]]

Taking back from dougt

Comment 38

[Daniel Veditz [:dveditz]]

Attachment: 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.

Comment 39

[Mike Kaply [:mkaply]]

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.

Comment 40

[(not reading, please use [e-mail] instead)]

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

sr=sspitzer

Comment 41

[(not reading, please use [e-mail] instead)]

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?

Comment 42

[Jesse Ruderman]

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

Comment 43

[Daniel Veditz [:dveditz]]

Attachment: 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.

Comment 44

[Daniel Veditz [:dveditz]]

fixed on trunk

Comment 45

[chris hofmann]

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

a=chofmann for 1.7

Comment 46

[Daniel Veditz [:dveditz]]

Fixed on 1.7 branch

Comment 47

[Daniel Veditz [:dveditz]]

The firefox version of this bug fixed only the install dialog. FF still needs to
incorporate the security dialog fix.

Comment 48

[Daniel Veditz [:dveditz]]

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

Comment 49

[Jon Granrose]

adding dave to verify on 1.7

Comment 50

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 51

[Daniel Veditz [:dveditz]]

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

[David Epstein]

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.

Comment 53

[David Epstein]

Verified on Mozilla trunk. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.8a2) Gecko/20040623

Comment 54

[Brendan Eich [:brendan]]

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

[nrlz]

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 56

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

a=blizzard for 1.4.3

Comment 57

[Mark Cox]

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

Comment 58

[Ryan Polk (Quark)]

/toolkit version checked in ala bug 253945, trunk and branch

Comment 59

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(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.

Comment 60

[Daniel Veditz [:dveditz]]

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

Comment 61

[HyperHacker]

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.

Comment 62

[Daniel Veditz [:dveditz]]

(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)

Comment 63

[Jesse Ruderman]

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

[Cameron]

I filed bug 359475 as a follow-up to this, for those who may be interested.

Comment 65

[Jesse Ruderman]

I filed bug 363142 describing some of the shortcoming of the "delay enabling the Install button" solution and suggesting alternatives.