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.
Oh, damn IE for being so insecure. Wait, this is about an Open Source browser---damn IE for being so insecure!
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.
from TFA:
For a spoofing attempt to work, a surfer would need to have both the attacker's Web site and a trusted Web site open in different windows.
So, uh, what about tabs? 'Cause I never have 2 windows open at the same time.
Your sig(k) has been stolen. There is a puff of smoke!
Type: Spoofing
Exploit: Local
Effects: All browsers
Description:
A 7 year old vulnerability has been discovered in multiple browsers, allowing malicious people to spoof the content of websites.
The problem is that the browsers don't check if a piece of black electrical tape is on the screen covering the address bar, which prevents the user from identifying the source of content in the browser window.
Successful exploitation allows a malicious website to load arbitrary content with its source masked by the black tape. The user cannot know if this is a trusted site.
Solution:
Remove the piece of electrical tape from the screen. Windex may be necessary to clean up afterwards.
Unknown host pong.
Recycling old bugs...I have to say that the Mozilla code base is losing some credibility with mistakes like this. Seems like a code audit is called for guys...
The NSA: The only part of the US government that actually listens.
is it impossible to test new releases against old bugs?
Does the firefox community have any regression testing? They need fully automated test like the linux kernel has now.
-dave
http://millionnumbers.com/ - own the number of your dreams
The Debian package of Firefox 1.0.4, with the extension tabbrowser preferences installed isn't, for example. As a result of this extension, the frame isn't injected into the frameset that is being targetted, and is opened in a new tab instead.
It is surprising, though, that a security vulnerability like this goes unnoticed for so long. On the other hand, I very much doubt that anybody has actually used this to exploit users.
www.fearthecow.net
Just one problem - the example "exploit" doesn't work. I press the MSDN link, it opens up in a new tab, press the demonstration link... And nothing happens.
So what do I do wrong?
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.
Or are they supposed to scrap it all and rewrite from scratch every few years? I sure hope not. Anyone else out remember M13, M14, M15, etc.? *shudder*
- I don't need to go outside, my CRT tan'll do me just fine.
It appears that if you have the Tabbrowser Preferences extension installed, then this exploit doesn't work.
perl -e 'foreach(values %SIG){$_="IGNORE";}while(){}'
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."
Does the Firefox team use any automated testing on the project? Seems like these sort of errors could stay dead, if so.
Software testing automation tools
If you mod me down, I shall become more powerful than you could possibly imagine.
Suite will be EOL'ed, but security patches are still being applied.
IIRC 1.x is feature frozen, but still 'active'.
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.
The bug in IE was reported almost a year ago, and it is still unpatched.
The bug was reported in all major browsers (Mozilla and Firefox, Opera, Safari, Konqueror, IE), and was patched in all of them except IE. It has now reappeared in Mozilla.
The whole terminology used for web sites belies the myth of a trusted web site.
Web sites are placed on "sacrificial hosts" in a "DMZ". Web sites are not trusted by the people who build them and never have been. If the owner of a web site doesn't trust it, why should you?
A victim would never need to visit an "untrusted" web site, because this defect could be coupled with others (exploit chaining). It's even been done before with other defects, notably Download.ject.
If you mod me down, I shall become more powerful than you could possibly imagine.
Now...take how many bugs have been exposed in Firfox and how many have been exploited.
How many bugs have been exposed in IE and exploited? (Especially because for IE it's almost a 1:1 ratio)
~Ilyanep
To get message, take amount of carrier pigeons at each stage mod 2. Then decode binary.
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.
Sorry if I'm misunderstanding you, but I think you have it backward. They're not saying that hack.ru could have a frameset that pointed to a frame with a real ebay page. They're saying that if ebay had a frameset, hack.ru could use javascript to insert itself as one of the frames. That is indeed a security hole -- unless you want to claim that it's one of those extra features that differentiates Firefox from Safari and IE ...
"...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!
You see? Another security fault in an open sores program. This is what you get if you don't pay your developers. Opening the source so that everyone can see the flaws is just asking for trouble. I'm going back to IE.
-- Cheers!
I click RMB->This Frame->Open Frame In New Tab
As you'd expect this opens the frame in a new tab where you can easily see the URL.
You can also find information about an embedded frame by clicking RBS->This Frame->Frame Info
What about placing a small colored box in the corner of each frame... If a frame's box differs in color from the surrounding frames, this would indicate the frame was on a different domain. That way the developers wouldn't have to worry about breaking the legitimate use of this technique.
What the hell's a "gewie?"
Gimme 1.00 $ for each website using frames, and 'll never have to work again ...
If you are using the TabBrowser Preference extension for Firefox, the exploit site will just open in a new tab, and the MSDN site will remain unaffected. https://addons.mozilla.org/extensions/moreinfo.php ?id=158&application=firefox
This just in, putting your picture inside a frame may cause an unfavorable reaction to whoever is looking at it. The results can range from shreeks of horror, to nausea and an look of disdain on the viewers face. The fix is to burn the picture with the frame....
There are many uses for frames that can increase usability or enhance/ease integration with other systems (that you cannot directly modify for example), particularly inline frames -- if you know what you are doing.
Simply saying frames suck without qualifying further only shows your lack of understanding of appropriate applications of them