ADODB.Stream only works in combination with a site incorrectly (or through social engineering) being treated as a "trusted site". Here are two other ways a "trusted site" can own you:
* Shell.Application * Signed ActiveX (doesn't even prompt for "trusted sites")
As long as those exist, the patch that turns off ADODB.Stream is pointless.
I don't understand what you mean be "aren't nearly as dynamic and flexible". Do you mean it takes a few more minutes to code a worm that uses them instead of ADODB.Stream? That a worm using them would necessarily be much larger and/or propogate more slowly? Or do you mean that they're actually harder to exploit programatically?
That's not just annoying; it's also a security hole. All a malicious site has to do to own your system is convince you to type a word containing the letter 'y' and try to install software when you type the previous letter.
Are you talking about browser windows? I use Firefox with "Allow scripts to raise or lower windows" unchecked, and I haven't had that problem for months.
I wouldn't call that a hole in Safari, since it affected Mozilla too (bmo 243699). It was a hole in the OS. Mozilla now disallows links to help: URLs to work around that hole, btw.
Oh and this is an acceptable fix to a serious bug? Upgrade to an unstable version?
Would you have been happier if I had just said "It will be fixed in 1.0"? With Mozilla, you can use nightlies, but you don't have to.
Why not have it immediately merged into the stable tree and release 0.9.2 and have one less site that renders like shit?
Two reasons:
* This bug isn't serious enough to be a reason for a subminor release. It may annoy you a lot because you read Slashdot, but most users don't see it at all and there is a workaround.
* The fix for this bug is risky. It's generally good to avoid putting risky fixes on stable branches.
11 months of IE exploits and at least a year or two's worth of future exploits can be avoided with one simple registry change.
The registry change you point to only affects the ADODB.Stream object. While holes involving ADODB.Stream may have made up a large porportion of successful exploits by spyware (as you claim), there have been other arbitrary-code-execution vulnerabilities in Internet Explorer during the time period you mention.
I'm guessing that there have been several zone-jumping holes, and ADODB.Stream makes all zone-jumping holes into arbitrary-code-execution holes. Is that what you mean by "using ADODB.Stream in one way, shape, or form"?
I make and research IE exploits for a living and wouldn't make this kind of a claim without having the data to back it up.
I find and fix Mozilla security holes as a hobby and I think you're making stuff up.
The slashdot rendering bug (bug 217527) can happen even without AdBlock. It's fixed on the trunk, so if you switch from 0.9 or 0.9.1 to a trunk nightly, you won't see the problem any more.
The URL at the top is a wishlist, they probably never look at that, and if they do it is the wrong department.
I think you're right. But by including a "security" checkbox on the wish form, Microsoft makes it look like they might have received your message.
The last comment has the email address I used. They do respond quickly on that.
I wish it had been easier to find that address. http://www.microsoft.com/security/default.mspx doesn't have "report a vulnerability" anywhere. I found that address by reading a Microsoft blog!
When you report security bugs to Microsoft, how do you report them? My methods are in http://www.squarefree.com/archives/000374.html and a comment on the same page.
Several security holes have been fixed since Mozilla 1.4, including an arbitrary code execution hole. Please upgrade to Mozilla 1.7 or Firefox 0.9.
Security holes are discovered and fixed in web browsers often. To be safe with any browser, you should upgrade when a new version is released, regardless of whether the release is accompanied by a security advisory regarding older versions.
Lorenzo Colitti and I found the same hole several weeks ago, independently of Mark Laurence. I reported it to mozilla.org on June 11 and to Microsoft and Opera on June 16. I got different results from each browser maker:
Mozilla (bugzilla.mozilla.org 246448)
Fixed on June 14. Firefox 0.9 released with the fix June 14. Mozilla 1.7 released with the fix June 17.
Opera (bugs.opera.com 145283)
No response.
Microsoft
On June 21, I received an e-mail containing the following: "... is by design. To prevent this behavior, set the 'Navigate sub-frames across different domains' zone option to Prompt or disable in the Internet zone. We are trying to get this fixed in Longhorn... on getting this blocking on by default in XP SP2 but blocking these types of navigations is an app compatibility issue on many sites." I usually don't get any response from Microsoft when I report security holes to them; I think I only got a response this time because I used my employer's premier support contract with Microsoft.
Another cross-browser security hole I found (bugzilla.mozilla.org 162020) got similar responses from each browser maker: fixed in Mozilla 1.7 and Firefox 0.9; no response from Opera; confusing statement from Microsoft mentioning XP SP2. 162020 is an arbitrary code execution hole.
That doesn't sound like a memory leak. It sounds more like a thread (but not the UI thread) getting into an infinite loop. I'm not sure what you'd search Bugzilla for... maybe "100% CPU" or "% CPU", but those will also find hangs.
If you can find a site that always causes the problem, or a series of steps that always cause it, then report the bug. (Even a way to cause it 10% of the time would be good enough.) Or, if you can somehow get a stack trace for the thread using your CPU, that would be even better.
Of course, anyone smart enough to design it - or even just build it from a set of schematics and a bucket of spare parts - is unlikely to get pwn3d by a trojan pr0n dialer in the first place. But it'd be a fun weekend project or group exercise for a first year engineering course.
Anyone smart enough to design it would probably have broadband rather than dial-up, too.
Firefox extensions can do anything the browser can do, so a malware executable could probably install a Firefox extension and do the same thing as this site. But a malware executable could instead modify the browser itself or install a keylogger, so it doesn't make sense to call Firefox's extension system "insecure". The only security hole (if any) is the one that allowed the malware executable to run in the first place.
It would be nice if operating systems could protect applications from each other. Then we could discuss whether BHOs or Firefox extensions are secure. Are there any operating systems that do that?
Turning it off by default would be pointless. If it was off by default, BHO installers would turn it on. Instead of blaming Microsoft for enabling BHOs by default, we should blame Microsoft for the security hole that allows the BHO installer (or keylogger, etc.) to run without the user's permission.
According to the article, the security hole involved.chm files. I don't know if there's a patch available.
Makes sense. I don't see any bug reports about that when I search Bugzilla for "Dial|modem|auto disconnect", though. Someone who can test a dialup connection should file a bug report in Bugzilla.
"The memory leak in Firefox 0.9" is about as specific as "The crash in Firefox 0.9". There are probably several leaks and crashes. Different people will experience different ones, and some people won't experience any.
Can you be more specific, such as by including a link to a bug about a specific memory leak? If it was a crash I'd ask you for a talkback ID or stack trace, but I don't think there's an equally easy way to identify a memory leak.
Slashdot Mirror
Here's another arbitrary code execution hole in IE. This one doesn't involve "zones" at all. And it hasn't been fixed yet.
Unless the author is dumb enough to reveal himself by suing you for copyright infringement, it's public domain.
ADODB.Stream only works in combination with a site incorrectly (or through social engineering) being treated as a "trusted site". Here are two other ways a "trusted site" can own you:
* Shell.Application
* Signed ActiveX (doesn't even prompt for "trusted sites")
As long as those exist, the patch that turns off ADODB.Stream is pointless.
I don't understand what you mean be "aren't nearly as dynamic and flexible". Do you mean it takes a few more minutes to code a worm that uses them instead of ADODB.Stream? That a worm using them would necessarily be much larger and/or propogate more slowly? Or do you mean that they're actually harder to exploit programatically?
That's not just annoying; it's also a security hole. All a malicious site has to do to own your system is convince you to type a word containing the letter 'y' and try to install software when you type the previous letter.
Are you talking about browser windows? I use Firefox with "Allow scripts to raise or lower windows" unchecked, and I haven't had that problem for months.
I wouldn't call that a hole in Safari, since it affected Mozilla too (bmo 243699). It was a hole in the OS. Mozilla now disallows links to help: URLs to work around that hole, btw.
What was the hole in Safari? Was Mozilla vulnerable to the same hole?
Oh and this is an acceptable fix to a serious bug? Upgrade to an unstable version?
Would you have been happier if I had just said "It will be fixed in 1.0"? With Mozilla, you can use nightlies, but you don't have to.
Why not have it immediately merged into the stable tree and release 0.9.2 and have one less site that renders like shit?
Two reasons:
* This bug isn't serious enough to be a reason for a subminor release. It may annoy you a lot because you read Slashdot, but most users don't see it at all and there is a workaround.
* The fix for this bug is risky. It's generally good to avoid putting risky fixes on stable branches.
11 months of IE exploits and at least a year or two's worth of future exploits can be avoided with one simple registry change.
The registry change you point to only affects the ADODB.Stream object. While holes involving ADODB.Stream may have made up a large porportion of successful exploits by spyware (as you claim), there have been other arbitrary-code-execution vulnerabilities in Internet Explorer during the time period you mention.
I'm guessing that there have been several zone-jumping holes, and ADODB.Stream makes all zone-jumping holes into arbitrary-code-execution holes. Is that what you mean by "using ADODB.Stream in one way, shape, or form"?
I make and research IE exploits for a living and wouldn't make this kind of a claim without having the data to back it up.
I find and fix Mozilla security holes as a hobby and I think you're making stuff up.
What are the URLs of the sites where the font sizes are different in IE and Mozilla? What is your "Text Size" setting in IE's View menu?
The slashdot rendering bug (bug 217527) can happen even without AdBlock. It's fixed on the trunk, so if you switch from 0.9 or 0.9.1 to a trunk nightly, you won't see the problem any more.
The URL at the top is a wishlist, they probably never look at that, and if they do it is the wrong department.
I think you're right. But by including a "security" checkbox on the wish form, Microsoft makes it look like they might have received your message.
The last comment has the email address I used. They do respond quickly on that.
I wish it had been easier to find that address. http://www.microsoft.com/security/default.mspx doesn't have "report a vulnerability" anywhere. I found that address by reading a Microsoft blog!
I thought Mozilla [1.4.x] was the "supported" version that recieved security updates?
It was, until Mozilla 1.7 was released. Mozilla 1.7 is the new stable branch. Don't expect more 1.4.x releases.
When you report security bugs to Microsoft, how do you report them? My methods are in http://www.squarefree.com/archives/000374.html and a comment on the same page.
Several security holes have been fixed since Mozilla 1.4, including an arbitrary code execution hole. Please upgrade to Mozilla 1.7 or Firefox 0.9.
Security holes are discovered and fixed in web browsers often. To be safe with any browser, you should upgrade when a new version is released, regardless of whether the release is accompanied by a security advisory regarding older versions.
Lorenzo Colitti and I found the same hole several weeks ago, independently of Mark Laurence. I reported it to mozilla.org on June 11 and to Microsoft and Opera on June 16. I got different results from each browser maker:
Mozilla (bugzilla.mozilla.org 246448) Fixed on June 14. Firefox 0.9 released with the fix June 14. Mozilla 1.7 released with the fix June 17. Opera (bugs.opera.com 145283) No response. Microsoft On June 21, I received an e-mail containing the following: "... is by design. To prevent this behavior, set the 'Navigate sub-frames across different domains' zone option to Prompt or disable in the Internet zone. We are trying to get this fixed in LonghornAnother cross-browser security hole I found (bugzilla.mozilla.org 162020) got similar responses from each browser maker: fixed in Mozilla 1.7 and Firefox 0.9; no response from Opera; confusing statement from Microsoft mentioning XP SP2. 162020 is an arbitrary code execution hole.
That doesn't sound like a memory leak. It sounds more like a thread (but not the UI thread) getting into an infinite loop. I'm not sure what you'd search Bugzilla for... maybe "100% CPU" or "% CPU", but those will also find hangs.
If you can find a site that always causes the problem, or a series of steps that always cause it, then report the bug. (Even a way to cause it 10% of the time would be good enough.) Or, if you can somehow get a stack trace for the thread using your CPU, that would be even better.
Of course, anyone smart enough to design it - or even just build it from a set of schematics and a bucket of spare parts - is unlikely to get pwn3d by a trojan pr0n dialer in the first place. But it'd be a fun weekend project or group exercise for a first year engineering course.
Anyone smart enough to design it would probably have broadband rather than dial-up, too.
How can an ISP charge you for dialing a phone number other than their own?
Firefox extensions can do anything the browser can do, so a malware executable could probably install a Firefox extension and do the same thing as this site. But a malware executable could instead modify the browser itself or install a keylogger, so it doesn't make sense to call Firefox's extension system "insecure". The only security hole (if any) is the one that allowed the malware executable to run in the first place.
It would be nice if operating systems could protect applications from each other. Then we could discuss whether BHOs or Firefox extensions are secure. Are there any operating systems that do that?
Turning it off by default would be pointless. If it was off by default, BHO installers would turn it on. Instead of blaming Microsoft for enabling BHOs by default, we should blame Microsoft for the security hole that allows the BHO installer (or keylogger, etc.) to run without the user's permission.
.chm files. I don't know if there's a patch available.
According to the article, the security hole involved
Fox news works for me in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040629 Firefox/0.8.0+.
Bugzilla also handles feature requests, so you don't have to worry about whether something is a "bug" or not before filing it.
Makes sense. I don't see any bug reports about that when I search Bugzilla for "Dial|modem|auto disconnect", though. Someone who can test a dialup connection should file a bug report in Bugzilla.
"The memory leak in Firefox 0.9" is about as specific as "The crash in Firefox 0.9". There are probably several leaks and crashes. Different people will experience different ones, and some people won't experience any.
Can you be more specific, such as by including a link to a bug about a specific memory leak? If it was a crash I'd ask you for a talkback ID or stack trace, but I don't think there's an equally easy way to identify a memory leak.