User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10 Using javascript it is possible to spoof the content of security and download dialogs by partly covering them with a popup window. This can lead the user to allow download and automatic execution of files (if a file extension association exists) or to grant a script local data access (if codebase principals are enabled). Reproducible: Always Steps to Reproduce: 1. Open http://www.mikx.de/firespoofing/ 2. Make sure popup blocker allows windows on click (default) 3. Maximize the browser window 2. Click on the text Actual Results: A download dialog appears and gets instantly covered by a popup window. The popup displays some dummy text that should convince the user to click on the "OK" button (which is part of the partly hidden dialog beneath). When clicked an .nfo file gets downloaded and is automaticly started in the associated application (by default Windows System Information in this case). Just an example, could also be a .key file to modify the registry or any other application associated with the file extension. Expected Results: It should'nt be possible to cover a dialog with a popup window and spoof the contents of the dialog this way. The way download dialogs are done in IE6 on Windows XP SP2 could be a solution. If you look at the javascript source code of the demo page you can find instructions on how to spoof a security dialog which appears if codebase principals are enabled (not default) and you try to access protected privelige like local file access. When a user accepts this (spoofed) dialog a remote attacker can get the same rights as a signed script (more or less full control). The file downloaded in the demo is in php to force the browser to download the file instead of displaying it using header modification. Source code: <?php header("Content-type: application/octet-stream"); header('Content-Disposition: attachment; filename="booom.key"'); ?> some reg key The popup window is only in the right place if the window is maximized. This is a limitation of my proof-of-concept code only. It would be easily possible to write scripts that calculate the position of the dialogs based on the window size/position. If you are on a slow connection timing could get an issue and the download dialog could take too long to open. An attacker could work around this by locally pre-caching the file using javascript. If you get timing problems when trying to reproduce increase the time in the setTimeout function. Using a LAN connection i was able to reduce the timeout to less than 100ms, making the dialog overlaying process unnoticable. The number of default file extensions coming with Windows XP is endless: You can open hypertext connections (.ht), remote desktop connections (.rdp), outlook (.eml) and so on. Tested on Windows XP SP1 and SP2 using Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10

Confirming. There will be an app-suite version of this bug too, no doubt. If you have disallowed sites to pop windows on top then this spoof doesn't work, and it looks odd to anyone paying attention (especially with the status bar forced on, doubly so in the app-suite with all those lower right icons). But it could probably fool enough people that we should think about how to keep our modal dialogs on top. If the user had ever moved the download dialog the spoof is destroyed. The location persists and the chances are extremely slim the user could have gotten it back exactly centered. It only takes a couple of pixels off to spoil the illusion. Maybe that could play into part of the solution, if there's no persisted location then open the dialog shifted 50 pixels in some random direction. The spoof also doesn't work if the dom.disable_window_flip pref is set to true. Not the default though, and unlikely to be changed for most people.

1. Instead of showing an "OK" button with a radio group to select the action (Open or Save), show "Open" and "Save" buttons. This would make some users suspicious of the fake EULA dialog, reduce the number of clicks needed to save a file from 2 to 1, and bring the dialog into compliance with Mac and Gnome HIGs. 2. Add the "dangerous" file types mentioned in comment 0 to our blacklist if they're not already on the list. 3. If we can't make our blacklist of dangerous file types complete enough, then use both a whitelist (.txt, .doc, .mp3) and a blacklist (.exe, .js, .key) like we do for external protocol handlers. * Whitelist: "Open" is enabled. * Unknown: "Open" is disabled until the dialog has been open (and on-top/focused) for 2 seconds. * Blacklist: "Open" is relabeled "Run". A block of bold warning text similar to the one in the XPI dialog is added. Both "Run" and "Save" are disabled until the dialog has been open (and on-top/focused) for 2 seconds. The delay would protect against race-condition attacks (described in bug 162020) in addition to dialog-covering attacks. At the same time, this solution would allow users to open uncommon types of files and run legitimate downloaded executables.

(In reply to comment #1) > If you have disallowed sites to pop windows on top then this spoof doesn't work, Tried this settings (disabled both "raise or lower" and "move or resize"). When served from mikx.de this helps, but when served from my local webserver the exploit keeps working. Maybe a timing issue. Will track that later. You can always bring the popup window to front if you raise another modal dialog inside of it (e.g. a simple alert('Sign this EULA!')) - no matter of the settings. > If the user had ever moved the download dialog the spoof is destroyed. True for download dialog, but security dialogs are always centered on screen.

This bug is now open for 30 days - can anyone give me a status update on it, or on the bug it is depending on? I have no read access to 256195.

(In reply to comment #4) > This bug is now open for 30 days - can anyone give me a status update on it, The bug is now open for more than 3 months and nobody answered to my last status request from 10(!) weeks ago. Can anyone please tell me if someone is actually taking care of this bug?

It seems nobody is taking care of this one right now. I will wait until next tuesday to make sure everybody is back from christmas holidays and had a chance to check email. If i still get no status feedback till then i see no other option than making the bug public. I don't want this bug to be fixed till then - i just want a simple feedback that some feels responsible for this bug and can tell me what's going on.

the bug is now public :( http://lists.netsys.com/pipermail/full-disclosure/2005-January/030728.html

Since this is public there does not seem much point in keeping this bug hidden - opening.

One could also make the location of such download/permission dialogs unpredictable by calculating their x-pos according to a formula involving random numbers, e.g. "center + random(-5 to 5 excluding 0)*10 - (dialogwidth/2)".

I like the idea of open and save buttons, and an XPI installer style box for downloads. Although the simpler solution would be auto-setting the open links that force new windows in tabs as true, although it could impede functionality.

so the solution discussed on drivers would be to make the position of the dialog random within some defined area, then use that postition, or the user selection position for future instances of the dialog postioning.

ben, can you have a look at this one?

There's also the possibility of making the ok button on security and download dialogs not clickable unless the dialog is in the foreground. (it would just focus the dialog)

I agree with comment #13. Another solution would be to give dialogs and always-on-top attribute. I think adding more to the UI is not the way to go.

I think making it always on top is also a bad idea, i agreee with <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=260560#c2">#2</a>, about a black/whitelist and to the on top for 2 seconds idea.

i agree with comment # 13. that sounds like the only good idea so far.

Ben, this is blocking us on 1.0.1. Can you take a look?

The fix for this is something more involved than I think should be fixed for a 1.0.1. Basically I think we want a new chrome flag for new windows - "sort-of-centerscreen" - that we can use for all dialogs that pose a spoofing risk. The right way to implement that flag is in nsXULWindow where there can be a SortOfCenter method that handles the placement appropriately.

What about a short-term fix for just these two dialogs that disables the buttons when the dialog loses focus?

I have tested this with both Firefox 1.0 and today's Firefox 1.0.1 branch build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20050217 Firefox/1.0) with the same results as originally reported. Steps: 1. remove localstore.rdf 2. enable signed.applets.codebase_principal_support pref 3. go to http://www.mikx.de/firespoofing/ 4. maximize the browser window 5. both the download and security dialogs are covered by the popup windows successfully spoofing the content During my initial test, it appeared that this was partially fixed for the tab-browser, but after more testing I can confirm that this bug is present for single browser windows AND tabbed browsing.

This makes it a little more difficult to accidentally click the OK button by disabling it when the window isn't in the foreground.

Comment on attachment 174730 [details] [diff] [review] be more discriminating about when we enable buttons >Index: toolkit/content/commonDialog.js >=================================================================== >+function commonDialogBlur() >+{ >+ gBlurred = true; >+ document.documentElement.getButton("accept").disabled = true; need to disable extra1 and extra2 here as well, and then enable in commonDialogFocus() -- or else pull those two buttons out of the if (!gBlurred) in commonDialogReenableButtons(). (I'd prefer to have all disabled/enabled, but no one really seems to use extra1 and 2 for anything dangerous) Otherwise this now works great for the security dialog. >Index: toolkit/mozapps/downloads/content/unknownContentType.xul >=================================================================== Still having a problem here -- when the dialog comes up initially the spoof still works. If I explicitly click on the already-focused fake EULA then the background buttons disable, but if my first action is to click on the land mine then the spoof works just fine. r- mainly because of the download dialog being spoofable still

This was assigned to Secunia advisory #13786 (SA13786); http://secunia.com/advisories/13786/ "Mozilla / Mozilla Firefox Dialog Overlapping Weakness" No CVE candidate available yet to use different advisory title.

Comment on attachment 174756 [details] [diff] [review] patch - works in both cases This worked great for the commonDialogs. Every once in a while if I clicked on the disabled OK button, though, the click apparently got to the button *after* the onFocus had re-enabled the button (see bug 239411 -- we should probably do that). Didn't always happen, and at least the button *appeared* disabled, but you may want to increase the setTimeout to 200 or 250 from 100. >Index: toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in >=================================================================== This one's still not working all that well. Maybe it's not getting all the blurs it should? (bug 164686). Increasing the timeout value from 100 to 500 seemed to help but made it feel sluggish. The main symptom is that the dialog still comes up with the button enabled in the spoof. It probably needs the global gBlurred state so when the initial enable timer fires it can check whether it should skip the enabling.

be more careful about enabling buttons in dl dialog increase delay slightly to 250

r=dveditz/a=drivers via IM. landed on the 1.0.1 branch and trunk.

Comment on attachment 174808 [details] [diff] [review] patch r=dveditz a=drivers from mtg On initial display of the download dialog version the button appears enabled (for me, but not for Ben). Even so, if you click on it the only effect is to bring that dialog to the top, not activate the button. For Ben the display is correctly disabled. As in the previous patch the security dialog version is working fine.

Verified Fixed on Aviary 1.0.1 branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050219 Firefox/1.0.1 The OK/Allow buttons in both the download and security dialogs are disabled when the focus is on the popup window. Bringing focus back to the dialogs, the buttons are enabled after a delay that seems long enough to prevent a user from accidently clicking twice before they realized what they are doing. A quick question: Why not disable all buttons until the dialog is focused? Or is it standard to always enable the "Cancel/Deny" buttons...regardless of focus?

Not sure if what I am seeing is a regression due to this patch or not, but if I initiate a normal download I now have to click the "OK" button TWICE in order to begin the process. Clicking it once (even after making sure the dialog is in focus) does not seem to work. Does anyone else see this behavior? Try: http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/2005-02-19-15-aviary1.0.1/ I'm going to retest with an older build to confirm this and will log a new bug.

(In reply to comment #1) > Confirming. There will be an app-suite version of this bug too, no doubt. Does a Seamonkey bug exist for that? Which bug number?

This problem does exist in Seamonkey builds. Although the Download testcase isn't as obvious since the dialog size is different than Firefox, the Security testcase is still a good spoof. Mozilla 1.7.6 branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050221 Mozilla 1.8b2/Trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050221 If there is a bug specific to Seamonkey, I haven't found it. Should we open a new one or just track the progress here?

Filed bug 283103 against the suite since this bug can't be marked blocking1.7.6. We'll need to port the patches anyway since the Suite has different UI code. For the record, the regression mentioned in comment 32 was tracked as bug 282872

Awarded a bug bounty

I tried the testcase several times. Sometimes, the "EULA" window displays on the top, but the download dialog is focused behind. It can be reproduced with Linux or Solaris. I don't know if it's metacity's bug.

(In reply to comment #37) > Sometimes, the "EULA" window displays on the top, but the download dialog is > focused behind. > It can be reproduced with Linux or Solaris. Can someone reproduce this? Should I reopen bug 283103?