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.
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.
Guys, any plans for this? It's been almost a month now.
mconnor, any ideas on who should look at this?
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.
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.
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?
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.
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?
.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.
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.
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.
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).
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?
(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
> 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
Taking advantage of bug 230606, sneaky ;)
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
Gavin: any progress?
Can't wait for branch progress in 184.108.40.206 any longer. Picking a suitable "blocking FF3" milestone that will get this into the next branch releases.
moving out bugs that don't need to block b1
Following suit on the branch
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.
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?
(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 . The xpinstall dialog uses security.dialog_enable_delay for both the initial delay and subsequent blur/focus delays , although it shows a countdown on the button in 500ms intervals to mitigate confusion about the button being disabled.  http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/content/commonDialog.js&rev=1.13&mark=184,224#178  http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/xpinstall/content/xpinstallConfirm.js&rev=1.10&mark=127,128#113
Created attachment 299684 [details] [diff] [review] patch for 1.8
Comment on attachment 299684 [details] [diff] [review] patch for 1.8 Approved for branch landing ahead of 220.127.116.11; a=ss.
Fix checked into trunk and 1.8 branch
Looking at the test case in comment 15, I don't see a difference in behavior between 18.104.22.168 and 22.214.171.124rc4. The file download prompt is still open and waiting in both instances after the test is run. Am I misunderstanding this test case?
(In reply to comment #28) > Looking at the test case in comment 15, I don't see a difference in behavior > between 126.96.36.199 and 188.8.131.52rc4. 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 on attachment 299684 [details] [diff] [review] patch for 1.8 a=asac for 184.108.40.206
mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in 220.127.116.11 mozilla/toolkit/content/commonDialog.js 18.104.22.168.4.1