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
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).
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
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.
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.
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:
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
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
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
(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 :(
Since this is public there does not seem much point in keeping this bug hidden -
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.
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.
Created attachment 174657 [details] [diff] [review]
This makes it a little more difficult to accidentally click the OK button by
disabling it when the window isn't in the foreground.
Created attachment 174720 [details] [diff] [review]
also patch the security dialog (only when delay button enable is set)
Created attachment 174730 [details] [diff] [review]
be more discriminating about when we enable buttons
Comment on attachment 174730 [details] [diff] [review]
be more discriminating about when we enable buttons
>+ 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.
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);
"Mozilla / Mozilla Firefox Dialog Overlapping Weakness"
No CVE candidate available yet to use different advisory title.
Created attachment 174756 [details] [diff] [review]
patch - works in both cases
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.
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.
Created attachment 174808 [details] [diff] [review]
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]
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
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:
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)
Mozilla 1.8b2/Trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
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
Created attachment 181947 [details]
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
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?
*** Bug 407489 has been marked as a duplicate of this bug. ***