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 (https://www.w3.org/TR/2001/CR-UAAG10-20010912/guidelines#tech-time-independent).

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:https:/// because I used enablePrivilege rather than install or install-skin.

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.

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.

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?

> 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 https://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.

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.

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.

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

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

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

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

can someone drum up a patch with a delay?

These people noticed the 2-second delay for installing Firefox extensions and weren't angry about it: https://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 :)

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

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.

Requiring XPIs to be signed -> bug 238960

(In reply to comment #17) > I think the Firefox XPI fix left open a variation of the expoit: > https://bugzilla.mozilla.org/show_bug.cgi?id=236056#c3 I filed bug 239411 for the variation.

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.

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.

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.

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

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

Ccing aebrahim@uchicago.edu, QA for bug 239411, so he can see this bug too.

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.

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?

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

dougt might have a line on a fix for this.

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

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

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.

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

Taking back from dougt

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 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 on attachment 149817 [details] [diff] [review] delay enabling buttons in XPInstall and security dialogs sr=sspitzer

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

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.

fixed on trunk

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

Fixed on 1.7 branch

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

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

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?

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.

Tested with the 1.7 branch on Win2000. When using the Nuke program, get the confirm dialog "A script from 'file:https://' 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:https://' 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.

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

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

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

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

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

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

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.

(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 https://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 https://secunia.com/secunia_research/2005-21/advisory/ (mouseclick)

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.

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

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