Last Comment Bug 376473 - [mz2] file action dialog controls vulnerable to refocus race
: [mz2] file action dialog controls vulnerable to refocus race
Status: RESOLVED FIXED
[sg:moderate] (exfiltration of local ...
: fixed1.8.0.15, fixed1.8.1.12
Product: Firefox
Classification: Client Software
Component: Security (show other bugs)
: 2.0 Branch
: All All
: P2 normal (vote)
: Firefox 3 beta2
Assigned To: :Gavin Sharp [email: gavin@gavinsharp.com]
:
Mentors:
http://lcamtuf.coredump.cx/ffclick2/
Depends on:
Blocks: 416282
  Show dependency treegraph
 
Reported: 2007-04-04 05:09 PDT by Michal Zalewski
Modified: 2008-03-18 11:27 PDT (History)
25 users (show)
mbeltzner: blocking‑firefox3+
dveditz: blocking1.8.1.12+
dveditz: wanted1.8.1.x+
asac: blocking1.8.0.next+
dveditz: wanted1.8.0.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch for 1.8 (2.20 KB, patch)
2008-01-27 22:10 PST, Daniel Veditz [:dveditz]
gavin.sharp: review+
samuel.sidler+old: approval1.8.1.12+
asac: approval1.8.0.next+
Details | Diff | Review

Description Michal Zalewski 2007-04-04 05:09:17 PDT
Affected mechanism: as a measure to prevent malicious trickery or human errors, some controls in several security-related dialogs are disabled (grayed out) when the window first displayed or when focus is removed from the dialog; and re-enabled by a delay timer after about 1 second after focus is gained.

Attack vector: on certain file-related prompts, re-enable timer is not stopped if focus is again removed before the initial timer had a chance to expire. When this happens, controls in a blurred window are re-enabled while the dialog is hidden, only to be instantly clickable when the window emerges from underneath a programatically closed decoy. This is confirmed on Windows, and may work differently on other platforms, depending on WM focus / raise policies.

Impact: any web page that can elicit user to click a particular region in an open window, or to hit RETURN at a roughly predictable moment, can use this to run potentially dangerous files without user consent.

Test case: see URL.

To fix: be sure to remove any pending refocus timers on blur on all dialogs that implement such a mechanism.
Comment 1 chris hofmann 2007-04-04 08:14:37 PDT
when runnning the test URL dbaron's leak tool also reports

Leaks in window 0x4a42350:
[ ] [leaked object] (5550fb0) = [Object]

----------------------

I think jesse has also looked at this area and may know if we have similar bugs on file.
Comment 2 Michal Zalewski 2007-04-29 14:04:01 PDT
Guys, any plans for this? It's been almost a month now.
Comment 3 chris hofmann 2007-05-07 11:44:30 PDT
mconnor, any ideas on who should look at this?
Comment 4 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-05-09 10:19:51 PDT
I can't get the provided testcase to work, even if I download locally and change the link to a WAV to a link to a file sent with "Content-disposition: attachment" (so that it always triggers an "open/save file" dialog). I suspect it's timing-dependent; if I change the timeouts to 1000,2000,3000 (vs. 600,700,800) I see the first window pop up and then close, and then a popup-blocked warning for the second window, and then the file prompt. With the site whitelisted, the file dialog does in fact pop up with the button enabled, but I think it does that regardless of the timing.

It seems like the 250 ms delay wasn't meant to prevent the focus race issue but instead the "partially covered window" issue in bug 260560. If we think this dialog needs the same delay protection that the extension manager install dialog gets we should increase the timeout and make sure it can't be avoided, but I'm not sure that's the case.
Comment 5 chris hofmann 2007-05-25 10:06:04 PDT
I've got dbarons leak monitior installed so maybe that helps set up better timing for the auto execution to happen.

On my windows XP IBM t60 laptop I get the auto audio playing with either WMP or Quicktime set as the .wav handler.
Comment 6 chris hofmann 2007-05-25 10:15:27 PDT
also, if I run with quick time as the .wav handler it automatically loads the audio content in page.  If WMP is the handler it launches the external WMP app.  I guess its the later that we need to/can protect against, right?
Comment 7 Michal Zalewski 2007-05-25 10:17:48 PDT
Yeah, WAV file wasn't a particularly good test case to use, because it is auto-launched in some configurations; substitute it for any other potentially malicious file that usually requires a confirmation dialog to open.
Comment 8 chris hofmann 2007-05-25 11:12:55 PDT
can someone create a different test case that uses another content type?

mz,  is it just "media content types" or do you see a way to launch .exe's?
Comment 9 Mike Connor [:mconnor] 2007-05-25 11:23:09 PDT
.exe or any other executable file type can't be opened directly, the only options are Save File and Cancel.  I'd say Word is a better testcase overall, since most/all exploits against media players have been exploitable in web content as well.  There isn't a lot of .doc plugins for Firefox, so this matters more for Word.
Comment 10 Michal Zalewski 2007-05-25 11:29:21 PDT
You can open Content-Disposition: attachment HTML files in local zone / file:// context, with all security implications; or DOC files and other potentially malicious files handled by external applications in the same manner.

As Mike suggested, EXE attack is not very likely: although the dialog is vulnerable to a variant of this attack, the only option is to save the file (by default, to desktop). We could then count on the user clicking this file, but not much more.
Comment 11 Daniel Veditz [:dveditz] 2007-05-25 11:49:58 PDT
I'm pretty sure this wasn't considered a security dialog. If it was we would default to "cancel" instead of "OK" for one thing, and we'd use security.dialog_enable_delay (2s) instead of 250ms which is way shorter than people's reaction times.

IE7's equivalent dialog also does not have a delay, although for "executable" types (which apparently includes .doc but not .wav) they have something more like a popup-blocker infobar warning. For us we just remove the "Open" choice and leave only the save choice.

So the question here is really should this dialog have a security-related delay at all. We _do_ use the delay for the external protocol handler, though. How is that any different than external helper apps?

On the external protocol handler dialog we do correctly have a refocus delay, but it's extremely short, not at all the original delay.
Comment 12 Michal Zalewski 2007-05-25 12:16:24 PDT
Daniel,

It does not require a vulnerable external application, I wouldn't agree with your assessment; unless, of course, default behavior of MSIE and Firefox when opening local file:// HTML files is a vulnerability, of course. It simply requires an application that is not accustomed to handling input from the Internet saved to a local file.

Also, note that EXE open dialog does not default to 'cancel', and has no 2 sec delay either. Is vulnerable to this attack, too (but again, save to desktop only, which requires user mistake to then execute the code).
Comment 13 chris hofmann 2007-05-25 15:59:42 PDT
as an aside jesse points out the problems with timed delays in mozilla.org/show_bug.cgi?id=363142 .  

do we really need a broader solution to get at the core of the problem?
Comment 14 Daniel Veditz [:dveditz] 2007-05-25 16:50:24 PDT
(In reply to comment #12)
> It does not require a vulnerable external application, [...] It simply
> requires an application that is not accustomed to handling input from the
> Internet saved to a local file.

Tomato/tomahto, Firefox is a conduit to get data to some non-Firefox ("external") application that will not handle it nicely ("is vulnerable"). Not blaming the external app, obviously you don't want to feed arbitrary .pl scripts to perl and it's not perl's fault if you do.

My point was that we're inconsistent. We're treating external protocols as
potentially unsafe (which seems reasonable) even though some protocols like
rtsp: might feed into the same media players that can be <embed>ed in a page
without prompting (but that's OK, how would we know unless the user tells us it's OK). At the same time we're assuming helper apps are OK, when they might
not even be written with networked data sources in mind--whereas you'd hope
something that implements URI scheme has at least considered the issues.

My other point was that there's no point complaining that there's no on-refocus delay for a dialog that doesn't implement the "security delay" in the first
place -- the complaint should be that it doesn't.

(In reply to comment #13)
> in mozilla.org/show_bug.cgi?id=363142

for convenience bug 363142 will autolink
Comment 15 Michal Zalewski 2007-05-26 16:11:07 PDT
> Tomato/tomahto, Firefox is a conduit to get data to some non-Firefox

Firefox can be one of these "external" applications, as per my example with Content-Disposition: attachment HTML files (that, being opened in file:/// URI-space, can for example issue XMLHttpRequest to read local files, then send them out elsewhere).

So, if the point you're making is that the dialog has no security implications for Firefox unless a flawed external application is found, I'd say it's sort of bogus. There is no "flaw" per se required.

Here's a HTML-related demo:
http://lcamtuf.coredump.cx/ffclick2/

> My other point was that there's no point complaining that there's no
> on-refocus delay for a dialog that doesn't implement the "security delay"
> in the first place -- the complaint should be that it doesn't.

This, on the other hand, is nitpicking over naming conventions - both dialogs (save as exe / open file) are important from a security standpoint, and both implement delays, but in a manner that can be circumvented. Whether you call them "security delays" or not, it is a security problem.

/mz
Comment 16 Jesse Ruderman 2007-05-26 16:14:20 PDT
Taking advantage of bug 230606, sneaky ;)
Comment 17 Michal Zalewski 2007-05-26 17:15:51 PDT
Daniel,

Just re-read your post, see your point more clearly, sorry if I were in any way hostile. 

I think it's probably best to keep several problems separate: one is whether we want to impose more strict rules for helper applications (a good idea - perhaps starting with a predefined list of trusted helpers, and requiring user's action or explicit registration with the browser to skip additional warnings otherwise is not bad); another one is what to do with "proper" security delays as such (imposing 2-5 sec delays on more common dialogs will annoy users, and there are some good points to be made for getting rid of delays altogether); and yet another issue is how to fix current dialogs to at least give the user *some* chance of surviving an attack, and to bring Firefox in line with other browsers (both Opera and MSIE implement <=1sec delays on open/save as dialogs).

The first two problems require some brainstorming and long-term planning, as witnessed by other Bugzilla entries. The last issue can be addressed in a matter of minutes.

/mz
Comment 18 Daniel Veditz [:dveditz] 2007-07-09 11:37:28 PDT
Gavin: any progress?
Comment 19 Daniel Veditz [:dveditz] 2007-07-10 14:59:11 PDT
Can't wait for branch progress in 1.8.1.5 any longer. Picking a suitable "blocking FF3" milestone that will get this into the next branch releases.
Comment 20 Mike Connor [:mconnor] 2007-10-01 13:37:32 PDT
moving out bugs that don't need to block b1
Comment 21 Daniel Veditz [:dveditz] 2007-10-01 15:18:29 PDT
Following suit on the branch
Comment 22 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-01-11 13:39:48 PST
Looking at the testcase and the code again with current trunk, the 250ms timer *is* reactivated when the window regains focus, which seems to contradict comment 0.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in&rev=1.58&mark=591#587

Given that, it seems like a pretty safe and simple mitigation would be to increase the activation timer for the button from 250ms to something large enough for the user to notice that the dialog is now focused. Perhaps to the value of security.dialog_enable_delay, currently 2000ms? Although that might be too long, given that there's no button text countdown as with the xpinstall dialog.
Comment 23 Daniel Veditz [:dveditz] 2008-01-25 21:42:10 PST
2000 would be painfully long. 500 is enough for me, but 1000 is probably safer to catch people with slow reaction times.

What about the other 250ms timer in that file?

what other dialogs have similar behavior?
Comment 24 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-01-26 15:38:34 PST
(In reply to comment #23)
> What about the other 250ms timer in that file?

It would need to be changed too, looks like it controls the initial delay on dialog opening.

> what other dialogs have similar behavior?

As far as I can tell commonDialog's BUTTON_DELAY_ENABLE flag (used by at least the PKCS11 dialogs and the CAPS "request capability" dialogs) causes it to use security.dialog_enable_delay for the initial load (2000ms), and a hardcoded 250ms delay for subsequent blur/focus sequences [1]. The xpinstall dialog uses security.dialog_enable_delay for both the initial delay and subsequent blur/focus delays [2], although it shows a countdown on the button in 500ms intervals to mitigate confusion about the button being disabled.

[1] http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/content/commonDialog.js&rev=1.13&mark=184,224#178
[2] http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/xpinstall/content/xpinstallConfirm.js&rev=1.10&mark=127,128#113
Comment 25 Daniel Veditz [:dveditz] 2008-01-27 22:10:21 PST
Created attachment 299684 [details] [diff] [review]
patch for 1.8
Comment 26 Samuel Sidler (old account; do not CC) 2008-01-28 00:27:15 PST
Comment on attachment 299684 [details] [diff] [review]
patch for 1.8

Approved for branch landing ahead of 1.8.1.12; a=ss.
Comment 27 Daniel Veditz [:dveditz] 2008-01-28 02:53:25 PST
Fix checked into trunk and 1.8 branch
Comment 28 Al Billings [:abillings] 2008-02-05 13:02:46 PST
Looking at the test case in comment 15, I don't see a difference in behavior between 2.0.0.11 and 2.0.0.12rc4. The file download prompt is still open and waiting in both instances after the test is run. Am I misunderstanding this test case?
Comment 29 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-02-13 11:51:37 PST
(In reply to comment #28)
> Looking at the test case in comment 15, I don't see a difference in behavior
> between 2.0.0.11 and 2.0.0.12rc4. The file download prompt is still open and
> waiting in both instances after the test is run. Am I misunderstanding this
> test case?

The difference between .11 and .12 should be that the OK button takes longer to become "active" when the prompt appears, such that you'll notice the prompt before you can click the button.
Comment 30 Alexander Sack 2008-03-18 05:22:23 PDT
Comment on attachment 299684 [details] [diff] [review]
patch for 1.8

a=asac for 1.8.0.15
Comment 31 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-03-18 11:27:00 PDT
mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in 	1.32.10.3
mozilla/toolkit/content/commonDialog.js 	1.9.2.1.4.1 

Note You need to log in before you can comment on or make changes to this bug.