Closed Bug 252198 Opened 20 years ago Closed 20 years ago

weak XUL security allows chrome UI spoofing ("phishing" attack)

Categories

(Firefox :: General, defect, P1)

Product:
Firefox
Component:
General
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 22183

People

(Reporter: jeff, Assigned: bugzilla)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 Firefox's chrome UI is written entirely in XUL. Because of this, a website can have embedded XUL that spoofs the UI. For an example, see the demo at http://www.nd.edu/~jsmith30/xul/test/spoof.html I don't know a solution to this problem. Perhaps we can put some more limitations on remote XUL (a la the popup blocker). Or perhaps we can make the status bar always-on. For a little more discussion, see: http://forums.mozillazine.org/viewtopic.php?t=102334 Reproducible: Always Steps to Reproduce: 1. Go to any site with some deceptive XUL files 2. Enter credit card number 3. p0wnd! Actual Results: The default installation of Firefox will display a spoofed login page so real that even seasoned Firefox users will have trouble seeing the evil. Expected Results: Some sort of warning, or some behavior that prevents such a complete takeover. Firefox should be safe out-of-the-box, because people who don't know how to detect a phishing scam are the same people who don't know how to turn on security options. Note that this works in all 0.9 versions of Firefox up to today's nightly, on (probably) all platforms, with (probably) all themes. Because other websites can make use of the chrome:// protocol, the bad guy's job is made much easier; very few files are actually downloaded from the bad webserver. In addition, chrome:// allows the spoof to be "theme-aware". The "allow javascript to hide the statusbar" option is also on by default. It shouldn't be.
Confirmed, scary...
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
->IMO it's at least critical
Severity: major → critical
Flags: blocking-aviary1.0RC1?
How about a whitelist for known "good" sites (ex. mozilla.org, mozdev, paypal, ebay, amazon, etc etc.), they would be able to use the chrome:// protocol, other sites could be added by the user. Or we could follow the same route as we did with the xpi install mechanism and present the user with some sort of warning. (DNS cross reference?)
Asking the user isn't secure. How much people enables everything in IE just to be able to have access to all features? We can't count on asking users if they want a secure browser or a feature browser: they will always choose the feature browser and complain after that it isnt secure (just after beiing stoled its credit card info...) Maybe a white list could do it... It should be well hidden though. Not many people needs this.
Just to keep the bug updated with the discussion in the thread... Someone pointed out that XUL isn't necessary - the same thing can be achieved with HTML (and produced a demo at http://www.pikey.me.uk/mozilla/test/spooftest.html ). That demo uses images from chrome://, but those could of course be copied and served from the site (although you'd only be able to spoof the default theme) I don't see a solution to this, aside from making some part of the UI unhideable so spoof windows at least have a dual status bar or URL bar. I don't know if there's a bug for that yet...
What about making a location of FF transparent?? It could be a bit like those holograms on credit cards (visa). Making the spinning icon transparent? If you can see thrue, than icons would be originals...
(In reply to comment #6) > What about making a location of FF transparent?? There's a new CSS3 property called "opacity" that is supported by Moz 1.7+ and FFX 0.9+ ... Here is what the problem boils down to. The SSL architecture guarantees us that we know when we're talking with "Paypal, Inc." The problem is in Firefox indicating this to the user. Since html can also be used to do spoofing, just limiting XUL isn't enough. Here are some options: 1) Force some UI to always be present, or put it where the bad guy can't get to it. For example, put the padlock in the title bar of the app. 2) Introduce some per-user UI randomness so that a spoofer doesn't know what to spoof 3) Do some type of warning for each new domain that the user tries to sumbit a html form to "Warning - you are about to submit information to www.paypal-spammerfish.com. Make sure that you trust this domain. Do you want to continue?" (Power users will know how to turn this off; it'll be our little secret.) 4) Change the FFX logo to a spinning 'e'... Some non-solutions that would at least help the matter a lot: 1) Limit XUL some more. Put up warnings, or whitelists, or something. 2) Limit chrome:// some more. Put up warnings, or whitelists, ....
IMO, it makes more sense to keep the address bar always on than to keep the status bar always on. Status bar always on: * Web site can't spoof an encrypted connection. * Web site can't spoof update notification in order to trick you into installing malware. Address bar always on: * Web site can't make itself look like a native application. It's clear that the window is a web browser content window. * Address is visible, so you know what site you're on. This is much more important than knowing whether the connection is encrypted and/or authenticated. * Web site can't spoof an encrypted connection (Firefox only). Anyway, this is a dup of bug 22183.
If it's a dupe, then unless bug 22183 has some details which don't appear in this bug and/or the Mozillazine thread, it could be opened and this bug duped, no? For the status bar/URL bar not being hideable - that should be a separate bug. Is there one yet (I know it's been mentioned in other bugs)?
Comments 76 through 84 in bug 22183 are a debate over whether to make it public :/ > For the status bar/URL bar not being hideable - that should be a separate bug. What is this bug about, then?
(In reply to comment #10) > Comments 76 through 84 in bug 22183 are a debate over whether to make it public :/ > > > For the status bar/URL bar not being hideable - that should be a separate bug. > > What is this bug about, then? This bug is about security issue of XUL UI. If it includes non-hidding of the address bar, then I don't see why we should open another bug...
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1+
Flags: blocking-aviary1.0+
Priority: -- → P1
I don't think I've seen this idea mentioned before, so here's another way to limit the success rate for UI spoofing attacks: on installation (or first launch in new profile), create some randomness to the UI (different colors, gradients, fractal image variations of common icons etc.). That way everyone's program would look slightly different, enabling smart users to realize when they are viewing a scam. The variations should not be made available to remote chrome. Of course I'd like all my Mozilla installations to look the same, so the "randomness" could be asked from the user during installation and if you wanted the same UI mods you would supply the same information on each install.
Bug 245406 is relevant to this discussion. Gerv
Why do we allow content to window.open or otherwise use chrome: URLs? Don't we forbid file: URLs from being loaded into windows or frames from non-file: non-chrome: documents? /be
Depends on: 252811
This is pretty serious. Disallowing remote XUL by default and asking whether the user wants to enable it "for this site" and doing the same for access to the chrome: URLs seems only sensible. Also requiring the address bar and relevant chrome to be displayed ALWAYS unless the user says otherwise.
like comment #5 said: this has nothing to do with XUL in itself somebody could fake firefox , MSIE or whatever wit a little effort using plain HTML use MSIE to try the simple example at http://ja-web.de/tmp/iefake/ the UI does not work but how many unexperienced people will notice before they klick the login button?
We have a pref for not allowing js to hide the statusbar (something WinXP Sp2 will do for IE) - we could default it to true. Also, we could make non-chrome documents not be able to resize/open windows larger than the screen (to move the statusbar offscreen) - don't we have that functionality already?
Brendan: if we didn't allow non-chrome XUL to reference chrome urls, people could just hardcode the menuitems in their XUL and not use the chrome entities as they did in that spoof url.
Defaulting the pref for disallowing removal of the status bar was filed as bug 252811 (which is currently marked as blocking this bug)
*** Bug 253745 has been marked as a duplicate of this bug. ***
I think always showing the status bar is in fact the right thing to do (unless the window is using the "chrome" flag, which requires expanded priveleges to use).
Bug referenced in a Secunia Advisory: http://secunia.com/advisories/12188/
Another solution would be to manage a list of host where the user can send POSTDATA to (just like the popup host list). This would not prevent the spoofed window but it would prevent the harm from being done: when the user click on send, a windows pops up informing him of the *actual* destination of the information, all risk associated and ask him whether to allow the POSTDATA request or not. This could work for all form of phishing. Hope this help
(In reply to comment #16) > like comment #5 said: this has nothing to do with XUL in itself > The reason I see this as being more serious than spoofing the UI with a jpeg is because the result is far more realistic. Furthermore, if you know half a thing about XUL, it's actually -easy- to do this; most of the hard XUL work has already been coded for you and can be copy/pasted from the chrome folder. All you have to do is modify a couple things. (In reply to comment #23) > Another solution would be to manage a list of host where the user can send > POSTDATA to (just like the popup host list). Unfortunately, this will not work, as you can bypass the <form> tag entirely, by using some javascript to roll your own URL into a GET request. (In reply to comment #17) > Also, we could make non-chrome documents not be able to resize/open windows > larger than the screen (to move the statusbar offscreen) - don't we have that > functionality already? Is that supposed to be guaranteed? On Windows XP, I can't make a window appear partially offscreen with window.open(), but on my GNOME Linux desktop, I can.
IMO the right solution to this is to change the default so that JS popup windows must have a Location bar AND a status bar. Either of these is technically enough to make the spoof imperfect, but the two together make it *really* clear that this is a browser window. Let's be secure by default: user_pref("dom.disable_window_open_feature.location", true); user_pref("dom.disable_window_open_feature.status" , true);
The settings of comment #25 make it indeed very clear that something is wrong, however Joe User will not understand that it's in fact a malicious website trying to trick you. He will rather think that it's a kind of bug of Firefox or something like that. So these prefs are a start, but they certainly are not sufficient.
(In reply to comment #25) > IMO the right solution to this is to change the default so that JS popup > windows must have a Location bar AND a status bar. > > Either of these is technically enough to make the spoof imperfect, but > the two together make it *really* clear that this is a browser window. In addition to that the URLs in location & status bar should be syntax-highlighted, possibly warning the user if it contains any of the classic www.fake.com\cgi-bin\****@12345678/?id=123 -type URLs.
> In addition to that the URLs in location & status bar should be > syntax-highlighted, possibly warning the user if it contains any of the classic > www.fake.com\cgi-bin\crap@12345678/?id=123 -type URLs. The status bar only contains the hostname - none of the other stuff in the URL - that's the point of having that text in the status bar. Also, there is now a warning for URLs which have silly auth stuff.
Best, imo, would be to add a <groupbox> around remote XUL documents, with a <caption label="Remote Web Application">, but don't know how easy this would be to realize. Or a bar, similar to the new popup notification bar. ("This is a remote web application, blah blah...") Both seem to be more elegant than preventing from hiding the location and/or status bars.
(In reply to comment #29) > Best, imo, would be to add a <groupbox> around remote XUL documents, with a > <caption label="Remote Web Application">, but don't know how easy this would be > to realize. > Yes. A process to diffrentiate between "local chrome" and "remote chrome" and non-hideable indicators to announce "remote chrome" applications. A frame border that is yellow and black striped like warning tape coupled with a notifier box announcing the fact that the striped window is a remote application that may "look like a web page". Add to this the ability to locally store a signed copy of the remote applications chrome file similar to the extension downloads. This way remote applications can be pulled in once with proper credentials and subsequently use the downloaded, trusted local copy.
Note that AdBlock and GoogleBar go away on the demo pages (available at http://www.nd.edu/~jsmith30/xul/test/spoof.html), so it looks like someone with extensions loaded might catch on to the page being spoofed. Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7) Gecko/20040629 Firefox/0.9.1
A fwiw. The spoof doesn't work on the Sky Pilot Classic theme. The bogus toolbars appear but not the bogus locks in the URLBar nor the statusbarpanel. That theme uses a different security icon filename and statusbarpanel security lock placement, which may be the reason for its, apparent, innoculation.
I think that this can be solved the same way Java applets do when they open out of browser page windows: any non signed XUL jar application or signed jar without privileges granted, must show a warning attached below the windows notifying the user that it is a remote not signed application
Here's a (user) suggestion: By default,when trying to execute a remote XUL app, a dialog should appear warning the user that is a remote app and letting the user decide if he wants to execute it anyway. An option to allow all XUL app from that site should be available in cited dialog. Also a white list of allowed sites to execute XUL apps, would be available in Preferences/Security. This way, it's possible to mantain the same aspect and advanced features of XUL applications without compromise security. I hope this can help. Luiz
I don't know if it's significant or not, but on my version of FireFox (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2) when I run the spoof demo for .9.0-.9.2 and try to look at the bookmarks, under 'bookmark this page' the only thing there is an entry labled "manBookMarksCmd.label;(_M_ANBOOKMARKSCMD.ACCESSKEY;)" It seems strange that my real bookmarks weren't loaded, so I thought I'd mention this in case whatever bug/feature is preventing them from loading might be exploited to defeat the spoofing itself.
I'm using Firefox 0.8 and I get <key id="key_newMessage" key="&sendMessage.commandkey;" command="Browser:NewMessage" modifiers="accel"/> ----------------------------------^ when I run the demo for 0.9-0.9.2.
(In reply to comment #35) > I don't know if it's significant or not, but on my version of FireFox > (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 > Firefox/0.9.2) when I run the spoof demo for .9.0-.9.2 and try to look at the > bookmarks, under 'bookmark this page' the only thing there is an entry labled > "manBookMarksCmd.label;(_M_ANBOOKMARKSCMD.ACCESSKEY;)" > > It seems strange that my real bookmarks weren't loaded, so I thought I'd mention > this in case whatever bug/feature is preventing them from loading might be > exploited to defeat the spoofing itself. I get the exact same thing here , i think this is important to be able to verify this
(In reply to comment #35) > I don't know if it's significant or not, but on my version of FireFox > (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 > Firefox/0.9.2) when I run the spoof demo for .9.0-.9.2 and try to look at the > bookmarks, under 'bookmark this page' the only thing there is an entry labled > "manBookMarksCmd.label;(_M_ANBOOKMARKSCMD.ACCESSKEY;)" > > It seems strange that my real bookmarks weren't loaded, so I thought I'd mention > this in case whatever bug/feature is preventing them from loading might be > exploited to defeat the spoofing itself. I get the exact same thing here , i think this is important to be able to verify this
(In reply to comment #38) > (In reply to comment #35) > I get the exact same thing here , i think this is important to be able to verify > this Sorry! That's all my fault! I've been trying to make just the two demos work for an increasing number of nightly builds, and they're all slightly different. I'll try to do some debugging tomorrow.
Sorry for the double post ( something must have gone wrong) I forgot to mention that i am using -> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
(In reply to comment #34) > Here's a (user) suggestion: > > By default,when trying to execute a remote XUL app, a dialog should appear > warning the user that is a remote app and letting the user decide if he wants to > execute it anyway. I think it's a good idea. And/or use a different GUI for all XUL windows. (In reply to comment #3) > How about a whitelist for known "good" sites (ex. mozilla.org, mozdev, paypal, > ebay, amazon, etc etc.), they would be able to use the chrome:// protocol, other > sites could be added by the user. Why a whitelist or allow "good" sites ? I don't see why a "good" site would use chrome://, but we can imagine many "bad" site would try to modify the whitelist.
(In reply to comment #34) > Here's a (user) suggestion: > > By default,when trying to execute a remote XUL app, a dialog should appear > warning the user that is a remote app and letting the user decide if he wants to > execute it anyway. An option to allow all XUL app from that site should be > available in cited dialog. > Also a white list of allowed sites to execute XUL apps, would be available in > Preferences/Security. Isn't it possible to use some kind of sandbox model as it is used in java? The idea is to inform the user that a website is XUL enhanced and there might be a classification of things XUL will address, hiding Menu, statusbar etc. If that is not possible, sorry XUL, why not deactivate it completely for remote components, i've learned that mozilla/firefox... needs it for rendering, that is quite fine, great, but is there a single website that makes use of XUL? Haven't seen any lately, in the last 10 years or so ;-) </Joke> Maybe we should think about some kind of zone model the IE uses: So XUL could be enabled for local and intranet access and some selected funtions even in the internet zone.
(In reply to comment #14) > Why do we allow content to window.open or otherwise use chrome: URLs? <img> does not use checkloaduri. iirc that's because that'd break inserting images in editor... see bug 69070
*** This bug has been marked as a duplicate of 22183 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Flags: blocking-aviary1.0PR+
Flags: blocking-aviary1.0+
You need to log in before you can comment on or make changes to this bug.