I don't like the wording in the press release either. The Bug Bounty FAQ makes it more clear, but still leaves a lot of information out.
Bugs that will get the bounty:
* Arbitrary code execution without user interaction. * Reading files with known names from the user's hard drive without user interaction. * Reading cookies or stored passwords for other sites without user interaction.
For bugs that require some user interaction to exploit, human judgement is required, hence contest judges.
Bugs that will not get the bounty:
* Temporary DoS, such as crashing or hanging the browser. * Exposure of browsing history. * Local file detection.
I don't know what would happen with a bug whose severity is between those listed as ineligible and those listed as eligible.
For what it's worth, about half of the security holes I've reported in Mozilla had the necessary severity (code execution, cookie read, file read). Many of those holes those required user interaction, though. It might be interesting to ask the judges which of my security holes would have been eligible had I reported them after 2004-08-02, to get a better idea of what they consider eligible.
TeX's bounty is for all bugs, not just security holes.
mozilla.org's bounty is more similar to djb's bounties for security holes in his server software, djbdns and qmail. The major differences between mozilla.org's bounty and djb's are that mozilla.org produces client software rather than server software, and we expect our bounty to be won (multiple times).
TeX has a lot of "interesting" features that I would consider bugs if the program wasn't as old as TeX is. For example, you have to run TeX twice to get it to update both the body of a document and its table of contents. And its error messages aren't always informative.
The fact of the matter is that this strategy only works if there are only a handful of people with the knowledge to write the virii, and you think you can catch them all. However this is not the case... several "authors" have proven to be minors, which only demonstrates that the knowledge is widely available to those who seek it out.
More to the point, this strategy only works if virus authors make it possible for other people to find out who the author is.
or maybe there is good still in him and we can sway him back to the good side of the force
When I was that around his age, I disclosed a security hole I found in DALnet's IRCD to blackhats rather than to server admins. I wrote one of the "script.ini" worms for mIRC described by RIMC. I even used a form of nick "spoofing" to execute "man-in-the-middle" attacks between members of IRC lesbian sex channels.
Now I use my powers for good as a member of Mozilla's security group.
Reading that bugzilla page is pretty scary. What else is hiding in there?
Bug 22183 was by far the oldest security-confidential bug. The next oldest is bug 149895, which is not a security hole but a reminder to review a specific feature for security holes.
There are 80 NEW, ASSIGNED, or REOPENED bugs marked as security-confidential. I'm the reporter of 6 of them.
It doesn't matter whether you can create an effectively spoofed IE user interface. It's been done and it's been posted on the Web. All you have to do to use is change what's displayed in the "content area" of the spoofed interface.
I just tested this attack in Opera. You're right, Opera does two things that make this kind of spoofing attack a little harder:
* "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 that was fixed almost two months ago in Mozilla and reported to Opera in March.
The advantage is that if you're ever transported back in time to when Google required you to include "-qqqqqqqq" in site: searches, your searches will still work. I don't know when they fixed it, but it was on or before April 23, 2004.
Don't let "Personalized" in the name worry you; it won't personalize your results unless you go through the process of telling it your interests. The only difference I see between Google Personalized Search and normal Google Search is that the second result from a site is not indented.
The most likely explanation is that some Google datacenters are horked and others are not. I think each browser picks a datacenter at random and sticks with that datacenter until you close the browser.
In the webmail world?? Gmail kicks the ass of every local e-mail client I have ever used. Its searching, while not instant like Google web search, is hundreds of times faster than Thunderbird's. The way Gmail combines e-mails from a thread into a single page is awesome. It even has better e-mail address autocomplete than Thunderbird.
Even if every RSS reader used HEAD (or if-modified-since) correctly, servers would still get hammered on the hour when the RSS feed has been updated during the hour. If-modified-since saves you bandwidth over the course of a day or month, but it doesn't reduce peak usage.
It would be simpler for RSS readers to generate a random time themselves rather than asking a server for a random time. I assume that RSS readers have a user option for when to check for updates; all that is needed is for the default to be random instead of "0 past the hour" for everyone.
In Windows XP (Classic theme), the start button doesn't look like it's in the corner, but if you click in the corner, the start menu opens. Same with the "close" button on a maximized window.
I don't see this as an open source vs. closed source issue. IE and Mozilla took the same approach to this kind of hole: assume that programs that register protocols aren't lying. I still think that's the right approach for protocols, even though Opera seems to be doing ok with the whitelist approach.
Slashdot Mirror
Many worms spread using holes that are already publicly known at the time the worm is written.
I don't like the wording in the press release either. The Bug Bounty FAQ makes it more clear, but still leaves a lot of information out.
Bugs that will get the bounty:
* Arbitrary code execution without user interaction.
* Reading files with known names from the user's hard drive without user interaction.
* Reading cookies or stored passwords for other sites without user interaction.
For bugs that require some user interaction to exploit, human judgement is required, hence contest judges.
Bugs that will not get the bounty:
* Temporary DoS, such as crashing or hanging the browser.
* Exposure of browsing history.
* Local file detection.
I don't know what would happen with a bug whose severity is between those listed as ineligible and those listed as eligible.
For what it's worth, about half of the security holes I've reported in Mozilla had the necessary severity (code execution, cookie read, file read). Many of those holes those required user interaction, though. It might be interesting to ask the judges which of my security holes would have been eligible had I reported them after 2004-08-02, to get a better idea of what they consider eligible.
One of Mudd's required classes has "Exploit a buffer overflow" as an assignment. Unfortunately, I took the class before that assignment was added.
Fwiw, I find it more fun to look for security holes in high level logic and GUIs than security holes related to memory management.
Is it a reference to Haibane?
TeX's bounty is for all bugs, not just security holes.
mozilla.org's bounty is more similar to djb's bounties for security holes in his server software, djbdns and qmail. The major differences between mozilla.org's bounty and djb's are that mozilla.org produces client software rather than server software, and we expect our bounty to be won (multiple times).
TeX has a lot of "interesting" features that I would consider bugs if the program wasn't as old as TeX is. For example, you have to run TeX twice to get it to update both the body of a document and its table of contents. And its error messages aren't always informative.
The fact of the matter is that this strategy only works if there are only a handful of people with the knowledge to write the virii, and you think you can catch them all. However this is not the case... several "authors" have proven to be minors, which only demonstrates that the knowledge is widely available to those who seek it out.
More to the point, this strategy only works if virus authors make it possible for other people to find out who the author is.
or maybe there is good still in him and we can sway him back to the good side of the force
When I was that around his age, I disclosed a security hole I found in DALnet's IRCD to blackhats rather than to server admins. I wrote one of the "script.ini" worms for mIRC described by RIMC. I even used a form of nick "spoofing" to execute "man-in-the-middle" attacks between members of IRC lesbian sex channels.
Now I use my powers for good as a member of Mozilla's security group.
I also read the headline that way.
How about something starting with "If you follow a link from an untrusted site to what appears to be a trusted site..."?
Reading that bugzilla page is pretty scary. What else is hiding in there?
Bug 22183 was by far the oldest security-confidential bug. The next oldest is bug 149895, which is not a security hole but a reminder to review a specific feature for security holes.
There are 80 NEW, ASSIGNED, or REOPENED bugs marked as security-confidential. I'm the reporter of 6 of them.
It doesn't matter whether you can create an effectively spoofed IE user interface. It's been done and it's been posted on the Web. All you have to do to use is change what's displayed in the "content area" of the spoofed interface.
I just made bug 182078 public. Thanks for pointing it out to me.
I just tested this attack in Opera. You're right, Opera does two things that make this kind of spoofing attack a little harder:
* "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 that was fixed almost two months ago in Mozilla and reported to Opera in March.
The advantage is that if you're ever transported back in time to when Google required you to include "-qqqqqqqq" in site: searches, your searches will still work. I don't know when they fixed it, but it was on or before April 23, 2004.
While Google Groups and the Usenet search are probably bookmarked by any geek out there
Real geeks don't use bookmarks, they use Google Web Search to return to sites.
Google Personalized Search still works.
Don't let "Personalized" in the name worry you; it won't personalize your results unless you go through the process of telling it your interests. The only difference I see between Google Personalized Search and normal Google Search is that the second result from a site is not indented.
The most likely explanation is that some Google datacenters are horked and others are not. I think each browser picks a datacenter at random and sticks with that datacenter until you close the browser.
How Does Gmail Stack Up In The Webmail World?
In the webmail world?? Gmail kicks the ass of every local e-mail client I have ever used. Its searching, while not instant like Google web search, is hundreds of times faster than Thunderbird's. The way Gmail combines e-mails from a thread into a single page is awesome. It even has better e-mail address autocomplete than Thunderbird.
an English translation will be available soon
Translation: 4 free karma points for the first translation!
Even if every RSS reader used HEAD (or if-modified-since) correctly, servers would still get hammered on the hour when the RSS feed has been updated during the hour. If-modified-since saves you bandwidth over the course of a day or month, but it doesn't reduce peak usage.
It would be simpler for RSS readers to generate a random time themselves rather than asking a server for a random time. I assume that RSS readers have a user option for when to check for updates; all that is needed is for the default to be random instead of "0 past the hour" for everyone.
In Windows XP (Classic theme), the start button doesn't look like it's in the corner, but if you click in the corner, the start menu opens. Same with the "close" button on a maximized window.
Is ICQ still "beta"?
I don't see this as an open source vs. closed source issue. IE and Mozilla took the same approach to this kind of hole: assume that programs that register protocols aren't lying. I still think that's the right approach for protocols, even though Opera seems to be doing ok with the whitelist approach.