Mozilla UI Spoofing Vulnerability 583
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."
Re:This is nothing... (Score:5, Informative)
Re:Vulnerability? (Score:3, Informative)
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... (Score:5, Informative)
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.
Not sure how they'll fix this... (Score:3, Informative)
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.
Javascript window "features" (Score:5, Informative)
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 [nd.edu].
Re:Not another one! (Score:1, Informative)
How about webapps (Score:1, Informative)
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.
too bad, Mozilla suite suckers! (Score:5, Informative)
Re:Javascript window "features" (Score:3, Informative)
Situation is web interface to a database. Popup windows are used to search database and fill in parts of the main form (product search, customer search, etc).
It saves a lot of screen real estate turning off those unnecessary things--and it's helpful for the user to have both the main form as well as any search windows open at the same time.
remote content should only control "client area" (Score:5, Informative)
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.
Re:Marked confidential? (Score:3, Informative)
That said, five years is a long time.
Re:There's something rotten in Firefox. (Score:2, Informative)
Use shit.slashdot.org :) (Score:5, Informative)
Re:Vulnerability? (Score:5, Informative)
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.
Re:Uselss Spoof (Score:3, Informative)
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.
Re:don't allow pop-ups without menu/location/etc (Score:3, Informative)
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.
It's not that big a deal really (Score:5, Informative)
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.
I wasn't vulnerable! (Score:5, Informative)
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.
Re:What the hell? (Score:5, Informative)
...
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:
Re:what? (Score:3, Informative)
Re:Use shit.slashdot.org :) (Score:1, Informative)
Re:YOU CANNOT DO THE SAME THING WITH IE!! (Score:2, Informative)
Bad, but not as bad (Score:3, Informative)
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.
Javascript issue (Score:3, Informative)
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?
Re:Holy Shit (Score:4, Informative)
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.
Re:I use Opera (Score:3, Informative)
* "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 [squarefree.com] that was fixed almost two months ago in Mozilla and reported to Opera in March.
Re:Javascript window "features" (Score:3, Informative)
Bullshit. As far as I know, Mosaic 1.0 had basic forms. Coupled with a cgi script, Mosaic was a DB front-end from the beginning. On top of that, Mozilla is, of course, the direct descendent of Netscape, which was designed by Marc Andressen, the original developer of Mosaic. Andressen stated repeatedly that he wanted to make Netscape a platform rather then just a browser, so your point is quite thouroughly shot to hell.
But even if your statement was remotely correct, it would still be irrelevent. Just because the original designers didn't foresee an application, doesn't mean that the application is somehow verboten. Innovation happens. Deal with it. The browser makes the IDEAL front end to a database. Properly implemented, it provides near write-one, run-anywhere capabilities to application developers. If you are developing an kind of database application, and you want to be able to support all users, regardless of OS, one of the easiest possible solutions is to create a browser based app. Sure you could do it in Java, but not everyone has Java installed or turned on (I don't). And sure you could write a frontend in Python (or whatever), but most users won't have the necessary software installed. By making it web based, and coding carefully, with a liittle effort you can support probably 98% of all users, without requiring anything of your users except that they be running a recent browser.
This spoofing exploit is a serious issue, but it's not one that suggests that we should throw away the "browser as platform" concept. The problem needs to be addressed, but there are several ways to do that without crippliing the browser.
Re:Use shit.slashdot.org :) (Score:3, Informative)