260560 - security and download dialogs can be spoofed by covering them partially using popup windows

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Michael Krax]

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

Comment 1

[Daniel Veditz [:dveditz]]

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.

Comment 2

[Jesse Ruderman]

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.

Comment 3

[Michael Krax]

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

Comment 4

[Michael Krax]

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.

Comment 5

[Michael Krax]

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

Comment 6

[Michael Krax]

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.

Comment 7

[Michael Krax]

the bug is now public :(

http://lists.netsys.com/pipermail/full-disclosure/2005-January/030728.html

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 9

[Jens Bannmann]

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

Comment 10

[alex]

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.

Comment 11

[chris hofmann]

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.

Comment 12

[chris hofmann]

ben, can you have a look at this one?

Comment 13

[Mike Kaply [:mkaply]]

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)

Comment 14

[Adam]

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.

Comment 15

[alex]

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.

Comment 16

[Grayson Mixon (ColdFusion650)]

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

Comment 17

[Asa Dotzler [:asa]]

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

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 19

[Daniel Veditz [:dveditz]]

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

Comment 20

[Jay Patel [:jay]]

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.

Comment 21

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

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 22

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: also patch the security dialog (only when delay button enable is set)

Comment 23

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: be more discriminating about when we enable buttons

Comment 24

[Daniel Veditz [:dveditz]]

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

Comment 25

[Juha-Matti Laurio]

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 26

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch - works in both cases

Comment 27

[Daniel Veditz [:dveditz]]

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.

Comment 28

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

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

Comment 29

[Ben Goodger (use ben at mozilla dot org for email)]

r=dveditz/a=drivers via IM. 

landed on the 1.0.1 branch and trunk. 

Comment 30

[Daniel Veditz [:dveditz]]

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.

Comment 31

[Jay Patel [:jay]]

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?

Comment 32

[Jay Patel [:jay]]

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.

Comment 33

[OstGote!]

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

Comment 34

[Jay Patel [:jay]]

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?

Comment 35

[Daniel Veditz [:dveditz]]

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

Comment 36

[Daniel Veditz [:dveditz]]

Awarded a bug bounty

Comment 37

[Ginn Chen]

Attachment: sometimes it still can be spoofed in metacity

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.

Comment 38

[Ginn Chen]

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