Slashdot Mirror
Mozilla UI Spoofing Vulnerability
Short Circuit writes "Secunia has issued a security advisory for Mozilla and Firefox. Apparently, remote web sites can spoof the user interface using XUL. (See the Firefox proof of concept.) Of course, that won't stop me from using Firefox."
except it has been a known issue since 1999...
I had the same opinion initally, but if you check out the spoofed Mozilla window you have to admit this could prove to be dangerous..
Having said that, I'll stick to Firefox nonetheless - let's just hope the Firefox team will find a way to fix it soon.
Bear in mind that this spoof only looks convincing if you haven't changed your Firefox toolbar at all, ie. you haven't switched to smaller icons or added/removed/moved buttons.
It also fails to appear properly on the Macintosh.
If someone wanted to make some kind of exploit with this, they'd want to target a specific platform and Firefox revision. (eg. 0.9 on Windows) Since Firefox is in constant development, it could well change between revisions and render these spoofs obsolete.
I don't really see this as a Firefox vulnerability. Use any browser without a popup blocker, and you'll see a lot of popup ads pretending to be legitimate OS windows and dialogs. This is really just a variation of that.
Without disabling XUL, I mean it's the equivilent of using images and text forms to spoof the IE menu bar, it just so happens that Firefox gives you tools that can be used to do a better job of it.
At any rate this can be overcome quite easily by changing the javascript prefs so that sites can't hide things like the status bar and menus.
The real problem here is not so much XUL, but Javascript!
Why does the browser even allow Javascript to create popup windows without toolbars, menu bars and status bars? This has to be one of the most annoying features of any web browser, I can't for the life of me understand why anyone would think up or need such a feature.
Without this Javascript, you couldn't turn the real menubars and toolbars off, and the problem would be much less severe since although you'd have a second set of interface controls within the browser window, the real status bar would be at the bottom, and the real menubar would be at the top.
Firefox already has a way to block JS from doing this and using several other of its most annoying features, and indeed I personally have these limits switched on already. Put about:config in the address bar, and change these entires to the following values (or look up how to make a user.js file on Google):
dom.disable_window_move_resize = true
dom.disable_window_open_feature.close = true
dom.disable_window_open_feature.directories = true
dom.disable_window_open_feature.location = true
dom.disable_window_open_feature.menubar = true
dom.disable_window_open_feature.minimizable = true
dom.disable_window_open_feature.personalbar = true
dom.disable_window_open_feature.resizable = true
dom.disable_window_open_feature.scrollbars = true
dom.disable_window_open_feature.status = true
dom.disable_window_open_feature.titlebar = true
dom.disable_window_open_feature.toolbar = true
dom.disable_window_status_change = true
Now try the example given in the summary again.
The grandparent was being funny and the following posts mistook mild humour for a troll.
The issue is that Firefox/gecko is advertised as a way to make a popup look and act like a real app : if you don't allow scripts to remove the browser part, a xul application wouldn't look like a real application anymore, would it ?
At work, I have managed to convince my bosses to use xul/php/postgres/soap instead of java/.net for our core project partly because of that (though i don't really care about that, portability and ease of devellopment is the main reason i pushed xul).
If you remove that, I don'think xul really stands out as a framework ; it would be too much tied to a browser.
Some site authors may say "but I really want to author a popup that doesn't have all that crap etc," but I don't see how it can be that important, especially given all the consequent badness. The only case I can see for this is that sometimes you do trust the content author--that there is a notion of Mozilla as a platform for application development. And, hey, ok, code reuse is good, but using Mozilla as a platform for a company-internal application is a totally different scenario; can't we recognize that as a different scenario and give it different rules instead of using one browser to rule them all?
Now, without being able to disable the location bar, you can't spoof the location bar trivially. You could put up a second one and hope people don't notice, and yeah, some people won't. Unfortunately, as pointed out on bugzilla, there's a case that this won't stop: you create an entire faux window, one that appears to be in front of the main one, but is actually just a part of it. So in the middle of your page you have a seeming popup window with a seeming location bar with a faux address. It wouldn't be draggable outside of the client area of the main window, but some people wouldn't notice it.
It's hard to see how to defend against that, although I am a wacky retro guy who thinks all of this DHTML stuff has given content creators way more power than they really need, and there would be nothing wrong with just pushing back on the standards until things weren't spoofable. (Remember when standards meant you wrote an RFC about something you had already implemented and figured out really worked; it didn't become a standard until people had exercised it in the field? Whatever happened to that?) Or maybe Ian Hickson is right and we're all just raving paranoic nutjobs. But it seems like exactly the sort of 'power before security' attitude that's gotten MS in a lot of trouble.
An entirely different way of looking at the problem of spoofing is that we transmit our secrets "in the clear" to the remote site. (Obviously encrypted by https or whatever.) If the remote site is spoofing, they get our password (and can maybe even open a connection to paypal or whatever and pass through everything so we don't know it's been spoofed). There's no need for us to give the secret to the remote site, though; just prove that we know it. For example, the server can give us some random data, and we use a non-reversible encryption algorithm to combine the random data and the password, and return the result of that. The server can verify that it's the right result without anyone transmitting the actual password (though the server must store the actual password, and not a hash of it). If this were the technology we were using, a spoofer wouldn't be able to use the password, unless the spoofer DID open a connection to the real site first, and get the challenge; then it could pass it through, but then the spoofer would have only this one chance to make use of the spoofed data, since the next time the real site challenged, the spoofer is stuck; whereas currently a spoofer just captures the user/password combo and keeps it around for later processing. This would raise the complexity bar for making effective use of spoofing (including email phishing!), although I don't know if it's high enough. But good luck getting it into browsers AND making it impossible for spoofers to create what looks like a login prompt of this kind but actually is just a plain old plaintext submit.
If a fix would be hard and/or time consuming to create then isn't it fairer for the majority of users that it isn't known outside the development group rather than having them rush out a kludge that may introduce more bugs.
That said, five years is a long time.
Either a reporter can mark his own bug confidential or a member from the security group can mark it confidential (or remove that flag). The members can be found here. Those are either members of the Mozilla Foundation, people who have done coding for Mozilla for many years now or were in any other way involved for a long time in the security of Mozilla. Or earlier (like one year ago) it were also people from Netscape, but i don't know how many people from Netscape actually had access to those bugs.
Use link to get the pretty green colors back.
"Exactly - furthermore, you can easily do exactly the same with IE. You just create a new window, with the fullsize property set, then set the dimensions (so you then have a blank window with no chrome at all - not even a title bar) - after that it's simply a matter of adding your spoofed interface using DHTML... Game over."
This hasn't worked since Internet Explorer 6.0SP1. You can no longer resize a fullscreen window.
As of 6.0SP2 (due out soon, hopefully) you can no longer create a window without a statusbar.
Moreover, it is difficult to "fake out" the UI using DHTML. You may be able to fool inexperienced users, but it is much harder than doing the same thing using Mozilla's XUL.
I do support for about 150 users, most of whom are programmers. I'm starting to have to clean spyware out of three or four computers a week, and a couple of times I've seen "spoofs" that looked like they were trying to trick people into allowing the bogus code to run, and none of them look like exactly like "real" IE or other application windows to my eye.
Yet, based on their track record, they do the job.
So an exploit that does a better job than that, well, it's a problem. The problem should be blocked at the source... starting with removing the ability to change the browser window decorations even if you DO still allow popups.
You can put this right next to the section where you disable blinking text and other stupidities.
:)
Really, there should be a single preferences option that turns all this off though. Of course when Netscape does their re-release of Mozilla *their* version won't have that option.
What it does is mimic the interface of an UNMODIFIED Firefox. Install ANY exension that changes the menubar or toolbar and you'll notice all that gone in the new window.
Heck, you don't even need to install any extensions...just customize your toolbar a little...place ANY icon after the help menu and try the proof of concept...it doesn't work - the difference is too obvious.
Neat trick, definitely, but I don't see it as much more.
Find a job you like and you will never work a day in your life.
That didn't prevent the statusbar hack, but it made everything else *really* obvious.
Have a look at about:config. There's a lot of useful stuff in there.
...
If a person, or group, can't be mature enough to admit a big, "oops, I/we made a really big design mistake. We'll fix it because many people are depending on us," then that person or group has no business working on such a fundamentally important piece of software as a web browser.
A workable solution to this kind of problem has been around for many years. Java applets, when run from appletviewer, display a very prominent notice telling the user that very thing.
The sad this about all this is that it's not even a fundamental design problem. Firefox has configuration options to eliminate this problem:
All you need to do is put something like this in your user.js file:
In Firefos, that would be Tools->Options->Web Features, and under the Javascript box use the Advanced tab.
If my answers frighten you, stop asking scary questions.
Okay, so somebody essentially builds a Javascript replica of the Firefox browser which activates as a popup when somebody clicks on a link. For this, the Mozilla folks are being raked over the coals. This is like saying a bank vault is insecure because it can be breached with explosives. Any browser could be spoofed this way and this has been going on with IE for a long time ("Your computer is infected with spyware, click OK to install more spyware^W^Wour software.")
Granted, I'd like to see it more secure by default , e.g., it doesn't install software by default, Javascript disabled, etc. This also isn't uniquely a Mozilla problem as the first versions of Red Hat shipped with telnet and rlogin ports open by default. It all goes back to the age old debate about security versus functionality.
As others have mentioned, you can change the Javascript behaviour to ensure that all new windows will always retain their title and control bars. Consequently it is amtter of configuring your browser properly.
The FF team made an admirable effort to come up with a default configuration in prefs.js that mostly works and adding a few lines to it is a matter of concientious system administration.
My son told me he did a screen capture on the computer of his comp sci teacher, then installed it as a background and had the poor guy futz around for a long time trying to figure out why all his icons and taskbar is dead - we cannot honestly say that such an exploit is a bug in Windows now can we?
Oh well, what the hell...
Try this, it mostly works:t ion", true);
b ar", true);
m izable", true);
z able", true);
l lbars", true);
u s", true);
./.mozilla/firefox/default.flc/prefs.js
user_pref("dom.disable_window_open_feature.loca
user_pref("dom.disable_window_open_feature.menu
user_pref("dom.disable_window_open_feature.mini
user_pref("dom.disable_window_open_feature.resi
user_pref("dom.disable_window_open_feature.scro
user_pref("dom.disable_window_open_feature.stat
It is only the last line that seems to be buggy, since the status bar still gets overloaded.
Oh well, what the hell...
I just tested this attack in Opera. You're right, Opera does two things that make this kind of spoofing attack a little harder:
* "Window handling" defaults to "Prefer pages inside windows", so when a site tries to open a new window, it gets an MDI child window. This isn't nice for web applications or users who don't like tabbed browsing, but it is more secure against spoofing.
* At least in the default theme, if I do javascript:window.open("", "", "scrollbars=no"); void 0, the content area is indented by two pixels to create a 3D effect. This wastes a little screen space, makes it measurably harder to scroll using the scrollbar, and sites with black backgrounds like Slashdot ugly, but it makes it harder for a malicious site to spoof the menu bar.
However, Opera is still vulnerable to a more serious hole that was fixed almost two months ago in Mozilla and reported to Opera in March.
The shareholder is always right.