Slashdot Mirror
Spoofing Flaw Resurfaces in Mozilla Browsers
GregThePaladin writes "A 7-year-old flaw that could let an attacker place malicious content on trusted Web sites has resurfaced in the most recent Firefox browser, Secunia has warned. The flaw, which also affects some other Mozilla Foundation programs, lies in the way the software handles frames. The applications don't check whether the frames displayed in a single window all originate from the same Web site." Commentary on this at whitedust as well.
The number of Firefox vulnerabilities that have been exposed is frightening. But I wonder when the first actual exploit will be found...
Try out fish, the friendly interactive shell.
-dave
http://millionnumbers.com/ - own the number of your dreams
Saying the bug resurfaced is not completely true. This bug was removed from the old Netscape rendering engine, and reintroduced when replacing it with the new and fancy Gecko rendering engine. Apache also reintroduced a number of bugs when switching from 1.3 to 2.0, I belive. That is one of the many prices you pay when rewriting old code from scratch.
Try out fish, the friendly interactive shell.
it's actually nothing to do with malicious code...it's just that someone could make an easy fake site with frames... I'm sure there are some sites that legitimately use this feature with differnt parts of their site hosted on different servers...What's next? Ban sites that use offsite graphics?
"A truly wise man realizes he knows nothing."
To have such fundamental flaws appear, whether by accident or negligence, is unacceptable.
Furthermore, the browser "industry" and the commercial sector NEED to come up with some guidelines as to how to promote and ensure online security for financial transactions and personal data.
For example, it's almost impossible for the casual or sophisticated user to easily determine whether a frame that appears within a website actually belongs to that website, or another. For example, if you have an online account with MBNA credit card, and make an online purchase, some vendors will display an MBNA authentication page which asks you to login to your online account to verify the purchase.
The problem is that this authentication page appears as a frame within the online vendor. How can you tell whether that frame is a legitimate MBNA page, or just a clever phishing attack? The browser gives no indication as to whether the frame belongs to MBNA or the vendor.
PayPal suffers from the same thing. I hate clicking on the "Make a Donation" button of some sites, and then seeing the PayPal login appear within a frame of the original site. That prevents me from making a donation - with today's complicated scripting invocations and what not, I don't feel trusting enough to type my account info and password into some frame which happens to appear in the middle of some other organization's website.
I can't BELIEVE that MBNA and PayPal would promote such idiotic practices, much less allow them to happen.
" Oh, damn IE for being so insecure. Wait, this is about an Open Source browser---damn IE for being so insecure!"
There will never be such a thing as a 100% secure browser. It's all about which one is "more" secure... Even with the holes found in Firefox it's still many times safer than IE. Not only that, but these holes are usually patched in a matter of days, while with MS your lucky if it gets fixed in a few months.
"A truly wise man realizes he knows nothing."
The applications don't check whether the frames displayed in a single window all originate from the same Web site.
And they shouldn't check that because often frames do not originate on the same web site (e.g., Google, Hotmail). The problem is if you try to frame something low security inside something high security; the other direction is OK.
What they should check (according to Secunia) is something different: when code attempts to put content into a target, the browser should check whether that code actually created that frame and otherwise refuse.
A simple way of fixing this problem might be to prefix the name of any frame with the host that created it, so that "target=foobar" actually means "target=www.host-of-this-page.com::foobar"; that also helps avoid confusing name conflicts between web sites. But that suffers from the same problem as anything else that relies on host names: you can't tell which ones are supposed to "belong together".
Alternatively, you might require that if any frame in a window uses https, then all of them must, and they all must use the same certificate.
The best solution is probably just to abolish frames altogether; they cause many other problems as well.
A slightly less drastic solution would be to prohibit the display of any https content in a frame.
The problem is not offsite graphics. The problem is controlling one webpage with an offsite webpage. This should never ever ever ever be allowed for obvious reasons. From TFA: "As a result, an attacker could insert content into a frame on a trusted Web site." (read that: "a website can modify the contents of a trusted website".)
There is absolutley no reason anyone should ever use this exploit for legitimate reasons. Yes, I can think of a few times it would be great if one website could help someone fill out another websites forms - but its not neccessary. If someone really wants to do that, they should attain permission and do it via GET or POST vars, or some serverside communication.
A website should still have control over what page is being shown in its frames, but not over the content of those pages directly.
-dave
http://millionnumbers.com/ - own the number of your dreams
The problem is not that different frames can come from different sites. The problem is that one site can change the existing content of a frame that is already being displayed.
So, if you do banking in one window and you then open up a malicious site in another, the malicious site can change the content of a frame in your banking window. That's not "faking", it's something worse.
I can't think of a legitimate use for that "feature" in a real application, and the fact that it didn't use to work suggests that sites aren't relying on it.
IE has this issue, want to bet which browser will fix it first? (hint, Mozilla fixed it before)
"...perhaps Mozilla should just take the lead on this and remove frame support entirely."
As much as I hate frames (oh GOD do I hate frames!), this would be a step back for FireFox and its proponents. One of the largest arguments for using non-IE browsers is compatibility with standards. Frames are in the HTML 4.01 standard, and therefore, removing support would be incredibly hypocritical.
Laziness, check. Impatience, check. Hubris, double check!
Gimme 1.00 $ for each website using frames, and 'll never have to work again ...