Race conditions in security dialogs
I discovered arbitrary code execution holes in Firefox, Internet Explorer, and Opera that involve human reaction time. One version of the attack works like this:
The page contains a captcha displaying the word "only" and asks you to type the word to verify that you are a human. As soon as you type 'n', the site attempts to install software, resulting in a security dialog. When you type 'y' at the end of the word, you trigger the 'Yes' button in the dialog. I made a demo of this attack for Firefox and Mozilla.
Another form of the attack involves convincing the user to double-click a certain spot on the screen. This spot happens to be the location where the 'Yes' button will appear. The first click triggers the dialog; the second click lands on the 'Yes' button. I made a demo of this attack for Firefox and Mozilla.
These types of attack work on any security dialog that can be triggered by untrusted content. The attack is most useful in a dialog where one of the buttons means "Yes, let this untrusted content run arbitrary code". Firefox has such a dialog in the form of the extension installation (XPI) dialog. Similarly, Internet Explorer has the ActiveX installation dialog and Opera has an "Open" button for downloaded executables. Programs other than browsers might also be vulnerable.
Firefox's solution, from bug 162020, is to delay enabling the "Yes"/"Install" buttons until three seconds after the dialog appears. I believe that this is the only possible fix other than completely denying untrusted content the ability to pose the dialog. Unfortunately, this fix is frustrating for users who install extensions often.
Some users have been intentionally lowering the delay to 0 seconds, which frustrates me. These users think the delay was added merely to force everyone to read the dialog. It surprises me that these users were not able to figure out the security hole given the fix. Ironically, advanced users are the most susceptible to these attacks, because they type and double-click faster than they react to unexpected stimuli.
It might be possible to lower the delay to less than three seconds, making it less annoying, without jeopardizing security. Designing experiments to determine the minimum "safe" delay would be tricky. You would want to do everything an attacker could do to increase participants' reaction time: give them a complicated task, make new rectangles appear every second to make the dialog less unexpected, etc.
It might make sense to make the dialog appear only after the user clicks a statusbar indicator that means "This web site wants to install software". This would get rid of the problem of choosing a delay, and it wouldn't require users who want to install extensions to wait.
July 1st, 2004 at 7:56 pm
What if the “Yes” and “Cancel” buttons showed up reversed based on a random number? would that not fix it?
July 1st, 2004 at 8:01 pm
Reversed or not, if “y” is still the access key, it’ll still accept the prompt.
However, on the linked bug, when I try the demo in Firefox, I don’t get a window that accepts a “y” but instead just says that a script was denied permissions with an Ok button.
July 1st, 2004 at 8:09 pm
Magus: you have to save the demo and load it from disk or use about:config to set signed.applets.codebase_principal_support to true. A real attack would use ActiveX or XPIs instead of pure JavaScript and would not be subject to that restriction.
July 2nd, 2004 at 12:11 am
WinZip randomises both the order of the OK/Cancel buttons and the accesskeys used. Or at least it used to.
July 2nd, 2004 at 12:20 am
Randomizing the order of buttons wouldn’t help much, since it would only protect users 50% of the time. The shareware version of WinZip just did that to be annoying.
July 2nd, 2004 at 4:51 am
Doesn’t the whitelisting of xpinstall solve this?
July 2nd, 2004 at 6:34 am
I’d say the best solution would be to do like what Apple does on installers: Limit keyboard shortcuts.
If you want to agree to the License in apple installers, you need to click with a mouse.
Click to Install
Then show a confirmation dialog “Are you sure”?
And get rid of that silly ability to disable the wait.
July 2nd, 2004 at 7:56 am
“If you want to agree to the License in apple installers, you need to click with a mouse.”
Unfortunately, that would render the dialog inaccessible to those who can’t use mice.
July 2nd, 2004 at 11:22 am
Did whitelisting make it into 0.9/0.9.1? I’m not sure. What is the advanced pref “allow websites to install software”?
July 2nd, 2004 at 4:46 pm
Whitelisting made it into 1.7 but was disabled in 0.9. I think Ben intends to make UI for the whitelist before enabling it.
July 2nd, 2004 at 4:49 pm
IMO, whitelisting is not a substitute for secure installation UI.
July 3rd, 2004 at 12:52 am
WTF is this alert doing with …
1. Buttons labelled “Yes” and “No”? Don’t do that. http://mpt.phrasewise.com/stories/storyReader$4 Use “Install” and “Cancel” instead.
2. … An accesskey for a button that’s already activated with the Enter key? Sloppy. You shouldn’t have two similarly accessible methods (e.g. keyboard combos) for doing the same thing, because people will waste time dithering wondering which one to use.
3. … Text that talks about “file://” in a localization other than xx-geek?
4. … Text that talks about “UniversalXPConnect privileges” in a localization other than xx-geek?
5. … A “Remember this decision” checkbox that doesn’t tell you whether the remembering would be just for this script, just for this page, just for this host, or for any host at all?
Granted, none of those would solve this bug. (Even if the accesskey was removed, the alert would still be accepted if the user pressed Enter, which the attacker could force by removing the submit button from the page.) But there’s little point in worrying about preventing people from accepting the alert accidentally, if its incomprehensibility means *they’d accept it unquestioningly even if they were looking straight at it*.
July 6th, 2004 at 11:41 pm
I posted an edited version of this blog post on http://lists.netsys.com/pipermail/full-disclosure/2004-July/023550.html
July 7th, 2004 at 8:42 am
Secunia posted this vulnerability: http://secunia.com/advisories/11999/
They summarized the problem as “it may be possible to trick users into typing or clicking on a XPInstall / Security dialog box, using various interactive events, without the user noticing the dialog box”.
But they listed it as only affecting Mozilla (except for 1.7), when they should have listed it as affecting Mozilla, IE, and Opera.
July 8th, 2004 at 6:27 pm
Actually, the answer is in two steps. Both require you to ignore the existance of the dialog box helper thing built into the GUI and, instead, open the “dialog box” as a full-fledged application window. Having done that, treat the window thusly:
1) If the mouse happens to be over/within the extent of the window as it is realized on the screen, any existing mouse events and move the mouse pointer to a control-nutral location. I normally dispise any control that moves my mouse, but the ever-so-slight nudge required to place the mouse in the “nutral territory” between the buttons would be imperceptable to most of us, and helpful to those other of us who know why it is happening.
2) Do *NOT* have the applicaiton transfer (Grab) focus in to the “dialog box”. I hate “always on top” “focus grabbers” anyway. Ever have your PGP pass phrase end up in some form that popped up on you? Very anoying. Very unsafe. The reach-for-the-moust set will never know that you didn’t grab the keyboard focus. They moused-over and clicked a button. End of story.
3) If you *must* grab the focus, don’t bind the buttons so that “y” triggers “yes” etc. This is an important box protecting a significant system action. Require, at least, an alt-Y for the shorcut or something equally impressive like decoding [pause]”yes”[enter] and then put that right there on the screen in a message. And then beep and clatter when un-menaingful keystrokes come into context.
The simple and obvious truth is that “pretty” isn’t “safe” and one-keystroke-install is just a bad idea from head to foot. Modal dialog boxes are a bane to human existance. Focus stealing is usually painful and unhelpful. Things that are not the “the thing that you are actively doing” should never, ever, own your keyboard nor “inherit” your mouse events.
(If the Windows GUIs were not so lame, every click event would be attachd to the window instead of being queued and then resolved to a window “later”.)
But now I rant.
July 9th, 2004 at 8:59 pm
Clever find, Jesse. Did you actually find this in the wild, or just realize it yourself? “Discovered” is vague.
Anyway, as one of the many users that you were “surprised” to see unable to figure out the purpose of the delay, I must say in my defence that it does definitely resemble features found in a lot of annoy-ware. I assumed some even-more serious attack was found with malicious XPIs, and the warning dialog was strengthened with the time delay. Just speaking of my own impressions, I think it was the actual display of the countdown, “(3), (2), (1)” that made me assume it was there to tell me “stop looking at this button and go back and read the warning, dummy”. But I suppose it would be even worse UI to have the Install button greyed-out, even for 2 seconds, with no indication as to why.
This popup-window reaction-time race-condition reminds me of my personal annoyance with IM programs. If I’m logging into a server with SSH, and someone messages me just as I’m about to type the password, they could very well end up receiving it. Perhaps IM programs should consider a few second delay before you are able to reply to new conversations. Or better yet, come up with a less obtrusive incoming message display than a focus-stealing pop-up window.
July 9th, 2004 at 9:46 pm
“Did you actually find this in the wild, or just realize it yourself?”
I realized it myself.
July 19th, 2004 at 8:45 pm
How about using a bar at the top of the web page (like the pop-up window warning bar) that prompts to install extensions, etc.
Advantages: Doesn’t get in the way like a modal dialog
No keyboard focus so can’t grab keypresses
Disadvantages: Leaves keyboard users in the lurch.
Spoofable through html imitation?
August 14th, 2004 at 8:37 am
ZoneAlarm provides similar security with its shutdown confirmation dialog box. The yes/no buttons require a mouseclick. They will not depress with a Y or N keystroke.
August 26th, 2004 at 4:31 am
Idea: why not combine the security alert and the download? So it would come up with:
“Do you want to install blah blah?
Downloading [XXXX–]
[Install] [Cancel]
where Install was only ungreyed when the download had finished (minimum 3 seconds), but the process could be cancelled at any time.
This would a) get them their software faster if they wanted it, and b) provide a good reason for the delay.
August 26th, 2004 at 11:01 am
Showing a progress bar might make users think it was something Firefox chose to install, thereby causing users to select Install when they shouldn’t. Starting to download the XPI in the background sounds like a good idea, though — it would speed up legit downloads and waste the bandwidth of malware servers.
October 1st, 2004 at 3:40 pm
[ At http://taint.org/2004/09/24/194902a.html ] I suggested that another good way to deal with this problem, would be to add a tickbox that must be ticked before the extension is installed. IMO, that’s a cleaner solution…
July 3rd, 2004 at 6:54 am
Captcha, Flycon, Gmail, Projector, Tricorder
Race conditions in security UI: devious – “As soon as you type ‘n’, the site attempts to install software, resulting in a security dialog. When you type ‘y’ at the end of the word, you trigger the ‘Yes’ button in the dialog.” Wireless devices off plea…
July 6th, 2004 at 7:12 pm
Premature Release
Well, things are pushing towards 1.0. Especially in a note by Ben Goodger today. Note, this isn’t in any way meant, to start a flame war, or a “Ben Goodger$oft is evil” rant… so if your going to comment along…
July 10th, 2004 at 5:32 pm
“These users think the delay was added merely to force everyone to read the dialog. It surprises me that these users were not able to figure out the security hole given the fix.”
Um, I’m one of those users. Please keep in mind that us users don’t know that the countdown is a “fix”, and don’t read Mozilla bug reports (especially when there are more than 100,000 of them). The most reasonable explanation for why a dialog has a countdown is that the author of the dialog wants to harass you into paying money to make the delay go away, or force you to read something you would skip.
A line of text explaining why the countdown would go a long way. “Counting down to prevent double-click security threat” would have done it. Plus, it would give me something to read during the delay. :-)
Frankly, I think one-click software install is almost impossible to lock-down from a security standpoint. If there’s a user-entered name of the package, just name it whatever action you want the user to take. “Click yes to install free porn utility.xpi” The Flash plug-in does this. “You must install this free software to correctly view the page (Flash)” is the gist of the message.
Suggestions like “make the security window not take focus” break the consistency of the window manager and in my opinion are not acceptable. If you think people have trouble figuring out why there’s a countdown in the security dialog, try to get them to explain to you why the window doesn’t take focus.
The double-click issue is interesting because many people double-click on links to follow them, rather than single click. This is, of course, due to inconsistency between the file manager “open folder/file” double-click and the web browser “open page” single-click. And it ain’t gonna change any time soon, I suspect.
James