Ask Jesse answer: Mozilla security process
I know you’ve criticised the mozilla security process (that is, what happens in practice rather than the documented process) previously, but haven’t seen you say anything about it recently. Do you think things have improved? What concerns do you still have?
Dealing with vulnerabilities that are found
There are many problems with Mozilla's vulnerability-handling process:
- For bugs that are disclosed by the reporter, patches usually appear quickly, but fixed releases take too long.
- For bugs that are not disclosed by the reporter, patches and fixed releases take too long.
- Reporters of security holes sometimes don't get any response for a week, which may make them inclined to disclose the hole sooner.
- For bugs that are not disclosed by the reporter, fixes are checked into public CVS days, weeks, or months before the release. Anyone can look through Bonsai and identify which checkins correspond to security holes without looking at code. (Checkins with references to hidden bugs, branch checkins, and checkins with vague comments without bug numbers are likely to be security holes). They could then look at the source code changes and, in many cases, reconstruct an attack based on understanding the vulnerability in the old code. Mozilla's security group needs a secret CVS repository for security patches.
- Bugzilla, Mozilla's bug-tracking system, has holes that can lead to the disclosure of information about security-sensitive bugs. One such bug is itself marked as security-sensitive and has been for years even though multiple people have filed duplicates.
I posted an older version of this list in a comment on Asa's blog. Security researcher "mikx" knew about the CVS problem and it was one of the reasons he chose to disclose holes in Firefox before a fixed version was released.
Eliminating grandfathered vulnerabilities
I'm sad how long my Security tips for users document has to be. I believe that most of the vulnerabilities in Windows and Firefox mentioned there can be fixed with little impact on usability in non-attack cases. They could certainly be fixed with less impact on usability in non-attack cases than making all users read that document ;)
Getting users to keep Firefox updated
Firefox's update notification is too subtle, and updating requires too much bandwidth and effort. Plans for software update in Firefox 1.1 are moving in the right direction to fix these problems. One issue that will be hard to address is users not updating due to abandoned extensions.
Avoiding "missing security check" holes
There have been several fixes that eliminate the need for a class of security check. These fixes make it easier to write secure C++ and JavaScript code and make it unnecessary to sprinkle easy-to-miss security checks throughout Firefox. I hope to see more fixes like these in the future.
Avoiding holes in Firefox's security UI
Someone (maybe me) should keep a list of all the security UI in Firefox and ensure the necessary precautions are applied. For example, users should see clear, accurate information to help them make security decisions such as entering passwords, opening downloaded files, and granting elevated permissions to specific web sites.
One aspect of security UI that requires a lot of attention is dialogs where users make security decisions. In addition to everything above, security dialogs should have safe default actions, clear button labels, and protection against race-against-the-user attacks.
Firefox is doing better on the security-UI front than IE and Opera. IE's and Opera's "what do you want to do with this file" dialogs are still vulnerable to race-against-the-user attacks almost a year after I informed Microsoft and Opera Software. That means that if you're using IE or Opera, a web site can own you pretty easily.
Working with other browser vendors
The Mozilla security group has coordinated security fixes and PR with Opera Software when Firefox and Opera have shared vulnerabilities. This is a good thing.
May 4th, 2005 at 5:15 am
Thanks for the comprehensive answer – will be easier to find if I want to point someone to what you’ve said in the future.
Sounds like (from your internship answer in the next entry) you’ll be able to help with some of this stuff when you’re there. :)
May 4th, 2005 at 5:40 am
Actually i made up my mind on sending advisorys when a patch get’s checked in into public CVS.
I still strongly disagree with this behavior and consider it more or less a full information disclosure, but i dicided to hold my advisorys back in the future until the patch gets released or the bug gets exploited in the wild. Since there is mostly no workaround beside re-compiling on your own or disable javascript (both unlikely actions) triggering an advisory to early doesn’t help.
A drasticly too good documented checkin would still make me release an advisory, though. But the Mozilla Security team was doing a good job in doing “obfuscated” checkins lately.
May 4th, 2005 at 6:46 am
Re: Getting users to keep Firefox updated
I know a lot of users like the subtlety of the update notification. In particular, everything on windows pops up with a big bubble demanding attention right now and will continue to harass you every fifteen minutes of your life until you do what it wants.
I definitely think it’s good to be noisy and explain it the first time around, but after that it should quiet down. I imagine a dialog with the “don’t ask me again” checkbox would make sense. I also think that any noisiness should be confined to critical updates. I really don’t need to be pestered to update my extensions.
May 4th, 2005 at 10:37 am
You write “Someone (maybe me) should keep a list of all the security UI in Firefox and ensure the necessary precautions are applied.” It would be truly wonderful if you and/or others were to look at the Firefox (and Thunderbird) security UI and figure out how it could be improved, particular for typical users.
May 4th, 2005 at 9:32 pm
Re: Getting users to keep Firefox updated
It’s get’s even more difficult with blunders like this:
* ANOTHER bug in the File Save dialog – MozillaZine Forums – http://forums.mozillazine.org/viewtopic.php?t=228991
* Bugzilla Bug 283730 – https://bugzilla.mozilla.org/show_bug.cgi?id=283730