Indistinguishable from Jesse

Some Firefox users (I don't know how many) refuse to upgrade to new major versions because their favorite extensions break. Users who don't upgrade miss out on new features, new extensions, and security fixes. What can be done to reduce the number of extensions that break when a new version of Firefox is released? Some ideas:

• Make sure extension authors know when all the major changes for a release have happened, so they have plenty of time to test their extension against the trunk/alpha/beta and bump maxVersion. Ensuring that all major changes for Firefox 1.1 happen before Firefox 1.1 beta might be a good way to accomplish this.
• Ensure that mozilla.org has permission to distribute new versions of extensions listed on UMO that authors abandon.
• Make maxVersion optional (bug 251148).
• Let users override a specific extension's maxVersion through the Extension Manager UI.
• Broken XUL overlays should not break XUL windows with XML errors. Instead, they should disable the extension or make the overlay be ignored.
• Try to freeze interfaces that extensions use.

Dan Veditz has updated the Mozilla Foundation Security Advisories page with information about holes that were fixed for Firefox 1.0, Thunderbird 0.9 and 1.0, and Mozilla 1.7.5.

None of the holes were arbitrary-code-execution holes, which surprised me. The worst hole fixed for Firefox 1.0 was the javascript: Live Bookmarks hole, which required some user cooperation and allowed attackers to steal cookies and sometimes execute arbitrary code. In contrast, many previous Mozilla and Firefox releases included new fixes for memory management holes such as buffer overflows. Exploits for memory management holes are harder to write, but they allow attackers to execute arbitrary code without getting any cooperation from users.

I have trouble completing personal projects that take longer than a weekend. I often lose interest after doing the interesting parts and procrastinate indefinitely on completing the projects since they have no deadline. In August 2004, I set a goal compatible with my attention span: "start and finish one interesting project every weekend". This goal helped me write a bunch of Firefox extensions and one or two Firefox patches, but of course it didn't help me finish longer projects. Now I have several half-finished longer-than-a-weekend projects piled up.

I'm hoping that this "coming soon" post will make me finish at least some of these projects soon. Also, you can tell me which projects you want me to finish first.

• A novel attack against something that was proven secure using a what I think is a poor definition of security.
• A proof that a popular puzzle is NP-complete.
• A list of some of Firefox's weaknesses, design elements that can lead to security holes.
• Security tips for Firefox users (current version). Since this document is already 7 printed pages long without screenshots, it may be more effective at pointing out critical user interface flaws in Firefox and Windows than at educating users.
• Security tips for web application developers (current version).
• Security tips for Firefox developers and extension developers (current version).

Google Desktop Search is useful enough for me to keep it installed, but I wouldn't say that it works well.

Functionality

• The file I'm looking for is often missing from Google Desktop Search's index. Even the filename is missing. I can't tell if it decided to skip the file because of its extension, contents, location, or changed-on date. Sometimes touching the file gets it indexed, but sometimes it doesn't.
• It "caches" old versions of files often enough to take up disk space unnecessarily, but not often enough that I can rely on it for a revision history when I break something.
• Since Google Desktop Search is slower than www.google.com, leaving "Show Desktop Search results on Google Web Search result pages" checked makes it slow down web searches.
• It gets much slower if I add num=100 to the URLs. A search with num=100 usually takes 3 seconds. This would be ok if it streamed the results, but I just don't see anything for 3 seconds. (There's no UI for adding num=100, so it's not really fair to complain.)

Security

• "Show Desktop Search results on Google Web Search result pages", which is checked by default, elevates any XSS hole in www.google.com to a read-my-files hole.
• Google Desktop Search uses an interesting scheme to mitigate XSS and CSRF holes: it includes a hash in every URL, even the root. The hash includes the path and sometimes includes the query parameters. If the hash is missing or doesn't match, it returns "Invalid Request".
• Clicking a link to an .exe file in search results runs it without any warning.
• The web site doesn't mention the current version number. The program doesn't have a "Check for upgrades" link, and if checks automatically, it makes no indication of that fact.
• Any web page can detect whether you have Google Desktop Search running by loading an image (or perhaps any URL) from http://127.0.0.1:4664/.
• The index is stored in a predictable location. "File upload holes", which let sites read your files if they know the filenames, are common in web browsers. File upload holes that require no user interaction are usually fixed quickly. But file upload holes that do require user interaction are not always fixed quickly. Two file upload holes requiring user interaction that I reported in 2000 are still present in IE and Firefox.

Michael Lefevre and mpt gave correct, but incomplete, answers to the question in my previous blog entry in their comments. Part of Michael's answer:

You'd have to work out which bits of closed bugs should be queryable (if you give any indication of a result based on, say, summary or comment queries, you could be disclosing important bits of the closed bug).

Indicating hidden results for a summary query would indeed disclose an important bit of the bug: its summary. First, the attacker would query for bugs with summaries starting with "a", "b", etc. Discovering that at least one hidden bug's summary begins with "b", the attacker would query for bugs whose summaries start with "ba", "bb", etc. After a few hundred more queries, the attacker would have the entire summary.

Google sometimes hides search results to ensure that search results are varied:

In order to show you the most relevant results, we have omitted some entries very similar to the 15 already displayed. If you like, you can repeat the search with the omitted results included. [foo site:squarefree.com]

or due to bad laws:

In response to a complaint we received under the Digital Millennium Copyright Act, we have removed 1 result(s) from this page. If you wish, you may read the DMCA complaint for these removed results. [scientology site:xenu.net]

Bugzilla also sometimes hides search results, to protect confidential bugs such as undisclosed security holes. Unlike Google, Bugzilla doesn't tell you that there are hidden results for your search. This caused me to worry that potential employers would think I can't count. It also makes it impossible for Peter(6) and others to tell exactly how many release blockers there are.

When Bugzilla hides search results from you, why doesn't it inform you like Google does?

Hint: while "Because nobody implemented that feature" may be technically correct, that's not the answer I'm looking for.

mozilla.org now has a security bug bounty program, which offers $500 to people who discover "critical" security holes. Meanwhile, Microsoft offers a $250,000 bounty for catching virus authors.

The problem of web sites being able to spoof browser UI was on Slashdot recently. This is a hard problem that browser vendors have known about for a long time.

The most popular solution, preventing web sites from disabling the status bar, is insufficient. Keeping the status bar always on would only keep malcious sites from spoofing https sites. In contrast, keeping the address bar always on would keep malicious sites from spoofing all web sites. Keeping the address bar always on would also be more effective at preventing web sites from spoofing native applications.

One argument for using the status bar is that it's smaller than the address bar. But it's only about 8px shorter if we use small-icons mode for pop-ups, and we can probably make it even shorter.

One suggestion was to show the hostname in the status bar. The hope is that users would then look there instead of the address bar to verify what site they're on. I don't think enough users would change their habits for this to work. It would also require cluttering the status bar in ordinary windows, which seems like a high price to pay to save 8px in pop-up windows.

Whatever we choose (address bar or status bar), we can do things to avoid breaking existing web sites. If a web site requests a 400x300 window without an address bar, we can give it a 400x334 window with an address bar. We can add a menubutton to the address toolbar in pop-up windows with menu items "Restore toolbars", "Hide address toolbar", and "Hide address toolbar in all pop-ups from https://gmail.google.com/".