I'm not sure why this is getting press now, given that a very similar exploit has been known and public since October 2000 (bug 56236). It was even fixed on trunk in September 2005, but left unfixed on branch intentionally because we weren't confident we had the UI right.
Zalewski's version is bug 370092, and he was unhappy when I marked it as a duplicate of bug 56236.
first postponing the 2.0.0.2 update, and then finding a remotely exploitable flaw in it immediately after its release
The remotely exploitable flaw, bug 371321, was reported at 5:35 pm (California time) on Thursday. We had been planning to release Firefox 2.0.0.2 on Friday morning. After some discussion, we decided to go ahead with the release and then follow up with a quick 2.0.0.3 once we had a patch for the newly discovered hole.
After releasing Firefox 2.0.0.2, we realized that bug 371321 didn't affect it, thanks to another patch that went into Firefox 2.0.0.2 for non-security reasons. So although we didn't know it at the time, we released a fixed version of Firefox about 16 hours after the most serious hole was reported.
The testcase in bug 371321 did lead to a fix for a similar bug that existed on trunk, though.
Firefox doesn't have a "Hold Ctrl to disable pop-up blocking" feature. Maybe you're thinking of another browser or a Firefox extension?
This vulnerability involves the "Show blocked popup" feature, which you can activate from the status bar icon indicating that a popup was blocked. If the popup is allowed in the first place, the security check works correctly.
PageRank is not obsolete or broken. It's actually one of the few trust metrics for which you can make a useful statement about attack-resistance. See my blog entry and class paper on the topic.
Assuming you have Talkback installed, can you post some Talkback IDs? It's often possible to tell what bug is causing the crash by looking at the Talkback report's stack trace.
Otherwise, we'll just keep trying to fix the most frequent crashes, rather than fixing your crash. Not that that would be a bad thing:)
Sorry, I misread your comment. Makes me wonder how I got modded up, making fun of you for something you didn't say;)
But more seriously...
I think it's pretty hard for applications to manipulate data (even passwords) in a way that guarantees they are never written to a swap file. And that's assuming your computer is *off* when it's stolen; it takes even more care to ensure the data doesn't remain in memory.
If you're paranoid enough to want to protect that data, though, why not encrypt your entire user account including the swap file?
What possibly earthly reason would there be for a server to request the content of client's clipboard?? I'm having an extremely hard time imagining a use case for such an event even with Ajax web applications.
Usually, the site wants to offer an alternate user interface for the Paste command.
The most common example is a WYSIWYG editing box with a 'B' button, an 'I', button, etc. Maybe they think users expect Cut/Copy/Paste buttons on any toolbar that includes text-styling commands, and won't think to use the normal methods such as Ctrl+V, the menu at the top, or a context menu.
A better example is Google Docs, which overrides the context menu in order to include special items like "Insert Image..." and "Insert Link...". Because it isn't using the browser's normal context menu, it can't include a (working) Paste command.
I'm not saying it's a good idea for browsers to let scripts access the clipboard (with or without a prompt). I'm just pointing out that there are legitimate cases where a site would be able to offer a better user interface (or at least a user interface more consistent with popular native applications) if it were able to script Paste commands.
It may be convenient, but it's also a severe security hole. If you paste anything from an untrusted site into a terminal window or into mIRC, you're owned. (I make this point on Security tips for Firefox users.) If web sites were able to put data on your clipboard without your knowledge (e.g. without you pressing Ctrl+C), it would be even worse.
Do you know what other "security holes by design" Flash has? Or other widely used plugins, for that matter?
I first became aware of this particular one when mkaply filed bug 360950, and I've been trying to figure out how to incorporate it into Security tips for Firefox users.
Your computer forces you to wait, enter your password, and then wait again? Aside from preventing you from accomplishing something useful during the entire wait time, that's bad for security.
The people who fix bugs in and refactor parts of Gecko are mostly not the same people who add frontend features to Firefox. Those activities involve different skills and programming languages.
When browsers added password management features 5 (?) years ago, there weren't a lot of sites that required passwords, included user-generated content, and allowed that user-generated content to include password fields. But there were (and still are) many sites where loading just about any URL on the site could give you a "you need to log in" page.
I'd be perfectly happy with this becoming part of the accepted security model for web applications, just like "don't let user-generated content include SCRIPT tags with arbitrary content".
This doesn't mean Mozilla will support ActionScript either, as it's just the virtual machine that's being opened, not the 'internal' functionality.
ActionScript and JavaScript are both extensions of ECMAScript 3. Mozilla and Adobe (among others) are working on an ECMAScript 4 specification that will incorporate many of the extensions, so I actually expect JavaScript and ActionScript to converge quite a bit over the next few years.
Note that I'm just talking about the programming languages, not the DOM for manipulating HTML/XML documents in Firefox or the APIs for manipulating movies and animations in Flash.
It makes more sense to give a web browser write access only to a small part of the file system than to force an entirely separate device to have a hard drive, IMO.
If Firefox's reputation with respect to security were "it never has any bugs that let sites do even mildly annoying things to you", this might be news. But I believe its reputation is a bit more realistic than that, focusing on the frequency, severity, obviousness, and time-to-patch of more severe holes.
Likewise, few people believe that Firefox is perfectly stable to the point of never crashing. MTBF estimates for stable releases are over 24 hours, which is pretty good, but far from perfect....
Maybe I should be happy this is the worst that has been said about Firefox lately. "I found a crash!" (a week passes) "So did I!"
If you go search Firefox's bug database for bugs with the "crash" and "testcase" keywords at any time, you'll find dozens of known crash bugs. I imagine it's the same for any other major browser. Meanwhile, very few sites intentionally crash web browsers. It makes more sense for developers to focus on lowering the average time between crashes (by fixing the most common crashes), or on fixing actual security holes, than to focus on squashing the largest number of crash bugs.
Why are CNet and Slashdot so interested in these particular two crash bugs? They aren't crashes that can be exploited to run arbitrary code.
There's no contradiction between the sentences you pasted. It's entirely possible that there are two (or more) "denial of service" bugs (bugs that can't be exploited to run arbitrary code, but do make your browser crash/exit) in Firefox 2.
More to the point, there's a fundamental difference between "I can make your copy of Firefox crash when you visit my site" and "I can make your copy of Apache crash".
Crash bugs in client software such as web browsers are "crashes", not "DoS vulnerabilities".
While it's a feature that ' opens find when focus is on the page, it's a bug that for some users, it sometimes has that behavior even when you're typing into a textbox or textarea. See bug 320465.
Slashdot Mirror
That's horrible. How is the HTML parser supposed to know that the second [script] is not just part of the comment started by the first [script]?
Perhaps more importantly, document.write can't be used to modify a page that has already loaded, limiting its usefulness for AJAX-style features.
Next thing you know, there will be articles related to Python on Slashdot that don't use the word "programming" or even "computer"!
I'm not sure why this is getting press now, given that a very similar exploit has been known and public since October 2000 (bug 56236). It was even fixed on trunk in September 2005, but left unfixed on branch intentionally because we weren't confident we had the UI right.
Zalewski's version is bug 370092, and he was unhappy when I marked it as a duplicate of bug 56236.
first postponing the 2.0.0.2 update, and then finding a remotely exploitable flaw in it immediately after its release
The remotely exploitable flaw, bug 371321, was reported at 5:35 pm (California time) on Thursday. We had been planning to release Firefox 2.0.0.2 on Friday morning. After some discussion, we decided to go ahead with the release and then follow up with a quick 2.0.0.3 once we had a patch for the newly discovered hole.
After releasing Firefox 2.0.0.2, we realized that bug 371321 didn't affect it, thanks to another patch that went into Firefox 2.0.0.2 for non-security reasons. So although we didn't know it at the time, we released a fixed version of Firefox about 16 hours after the most serious hole was reported.
The testcase in bug 371321 did lead to a fix for a similar bug that existed on trunk, though.
Firefox doesn't have a "Hold Ctrl to disable pop-up blocking" feature. Maybe you're thinking of another browser or a Firefox extension?
This vulnerability involves the "Show blocked popup" feature, which you can activate from the status bar icon indicating that a popup was blocked. If the popup is allowed in the first place, the security check works correctly.
PageRank is not obsolete or broken. It's actually one of the few trust metrics for which you can make a useful statement about attack-resistance. See my blog entry and class paper on the topic.
Assuming you have Talkback installed, can you post some Talkback IDs? It's often possible to tell what bug is causing the crash by looking at the Talkback report's stack trace.
:)
Otherwise, we'll just keep trying to fix the most frequent crashes, rather than fixing your crash. Not that that would be a bad thing
Sorry, I misread your comment. Makes me wonder how I got modded up, making fun of you for something you didn't say ;)
But more seriously...
I think it's pretty hard for applications to manipulate data (even passwords) in a way that guarantees they are never written to a swap file. And that's assuming your computer is *off* when it's stolen; it takes even more care to ensure the data doesn't remain in memory.
If you're paranoid enough to want to protect that data, though, why not encrypt your entire user account including the swap file?
What possibly earthly reason would there be for a server to request the content of client's clipboard?? I'm having an extremely hard time imagining a use case for such an event even with Ajax web applications.
Usually, the site wants to offer an alternate user interface for the Paste command.
The most common example is a WYSIWYG editing box with a 'B' button, an 'I', button, etc. Maybe they think users expect Cut/Copy/Paste buttons on any toolbar that includes text-styling commands, and won't think to use the normal methods such as Ctrl+V, the menu at the top, or a context menu.
A better example is Google Docs, which overrides the context menu in order to include special items like "Insert Image..." and "Insert Link...". Because it isn't using the browser's normal context menu, it can't include a (working) Paste command.
I'm not saying it's a good idea for browsers to let scripts access the clipboard (with or without a prompt). I'm just pointing out that there are legitimate cases where a site would be able to offer a better user interface (or at least a user interface more consistent with popular native applications) if it were able to script Paste commands.
It may be convenient, but it's also a severe security hole. If you paste anything from an untrusted site into a terminal window or into mIRC, you're owned. (I make this point on Security tips for Firefox users.) If web sites were able to put data on your clipboard without your knowledge (e.g. without you pressing Ctrl+C), it would be even worse.
You're worried that if someone steals your laptop, they might be able to find your email address and spam you?
Do you know what other "security holes by design" Flash has? Or other widely used plugins, for that matter?
I first became aware of this particular one when mkaply filed bug 360950, and I've been trying to figure out how to incorporate it into Security tips for Firefox users.
Your computer forces you to wait, enter your password, and then wait again? Aside from preventing you from accomplishing something useful during the entire wait time, that's bad for security.
I haven't noticed this. Can you file a bug with a URL (or even better, a simple testcase) if there isn't already a bug on it?
The people who fix bugs in and refactor parts of Gecko are mostly not the same people who add frontend features to Firefox. Those activities involve different skills and programming languages.
When browsers added password management features 5 (?) years ago, there weren't a lot of sites that required passwords, included user-generated content, and allowed that user-generated content to include password fields. But there were (and still are) many sites where loading just about any URL on the site could give you a "you need to log in" page.
I'd be perfectly happy with this becoming part of the accepted security model for web applications, just like "don't let user-generated content include SCRIPT tags with arbitrary content".
This doesn't mean Mozilla will support ActionScript either, as it's just the virtual machine that's being opened, not the 'internal' functionality.
ActionScript and JavaScript are both extensions of ECMAScript 3. Mozilla and Adobe (among others) are working on an ECMAScript 4 specification that will incorporate many of the extensions, so I actually expect JavaScript and ActionScript to converge quite a bit over the next few years.
Note that I'm just talking about the programming languages, not the DOM for manipulating HTML/XML documents in Firefox or the APIs for manipulating movies and animations in Flash.
It makes more sense to give a web browser write access only to a small part of the file system than to force an entirely separate device to have a hard drive, IMO.
If Firefox's reputation with respect to security were "it never has any bugs that let sites do even mildly annoying things to you", this might be news. But I believe its reputation is a bit more realistic than that, focusing on the frequency, severity, obviousness, and time-to-patch of more severe holes.
...
Likewise, few people believe that Firefox is perfectly stable to the point of never crashing. MTBF estimates for stable releases are over 24 hours, which is pretty good, but far from perfect.
Maybe I should be happy this is the worst that has been said about Firefox lately. "I found a crash!" (a week passes) "So did I!"
If you go search Firefox's bug database for bugs with the "crash" and "testcase" keywords at any time, you'll find dozens of known crash bugs. I imagine it's the same for any other major browser. Meanwhile, very few sites intentionally crash web browsers. It makes more sense for developers to focus on lowering the average time between crashes (by fixing the most common crashes), or on fixing actual security holes, than to focus on squashing the largest number of crash bugs.
Why are CNet and Slashdot so interested in these particular two crash bugs? They aren't crashes that can be exploited to run arbitrary code.
There's no contradiction between the sentences you pasted. It's entirely possible that there are two (or more) "denial of service" bugs (bugs that can't be exploited to run arbitrary code, but do make your browser crash/exit) in Firefox 2.
More to the point, there's a fundamental difference between "I can make your copy of Firefox crash when you visit my site" and "I can make your copy of Apache crash".
Crash bugs in client software such as web browsers are "crashes", not "DoS vulnerabilities".
While it's a feature that ' opens find when focus is on the page, it's a bug that for some users, it sometimes has that behavior even when you're typing into a textbox or textarea. See bug 320465.
Is Firefox trunk better for you in this regard?
Can you point to a myspace page where Firefox screws up the table layout? I thought table layout was one of the few things browsers agreed on.