shaver

There’s a great writeup over on Matasano (home of many a great writeup) about how a supergenius hacker was able to exploit a NULL pointer coming out of malloc failure to run arbitrary code in Flash. This is interesting to Mozilla in part because a lot of our users have Flash installed, but also specially interesting to me because we’re working with Adobe to converge on a common, high-performance scripting engine for both JavaScript-as-she-is-written-today and ECMAScript future. I’m actually in Boston tomorrow to work with some Mozillians to map out the next interim milestone on our way to JS2 and Tamarin.

As part of the same general effort, known as “Mozilla 2″, we’re also going to be changing how we do memory allocation, so that — just as Thomas recommends — out of memory is a hard-stop failure, rather than an opportunity for a clever (or, as in this case, hyper-clever) exploit to take hold.

Of course, in a system as large as ours, you don’t want to do it all by hand, so we’ll be using static analysis tools to identify and rewrite our code mechanically. This will give us better performance from less computer time spent checking allocation results, reduced code complexity from less human time spent reading through tedious failure-handling code, and protection against a large class of potential attacks. That’s a pretty nice set of things to get in one package.

Ronald van den Heetkamp has claimed that he found a vulnerability that affects all released versions of Firefox, and so the Mozilla security group and others have been investigating it, as we do all such claims.

In this case, it appears to me as though Ronald is simply mistaken. The files to which Ronald demonstrates access do not have the user’s settings, though he claims otherwise. Those files (the user’s data) are not stored in the Program Files hierarchy on Windows, or the equivalent on other operating systems. Instead, the preference files that he is showing in his “exploit” are ones that are defaults that are shipped with Firefox, and made freely available on the web. Again, these are not user settings, but defaults that are shipped with all copies of Firefox and contain no personal information.

(NB: this issue should not be confused with the recent “flat chrome” directory traversal vulnerability that affected users of some extensions, and which 2.0.0.12 fixes.)

I don’t know if Ronald will issue an update to his post, as he did for a previous mistaken vulnerability report, but since the story has been taken at face value by Slashdot and likely others, I thought I’d post about it here.

Edit: this is the same thing that RSnake and others on his blog discussed last May; comments there are possibly of interest. Ronald participated in the thread but didn’t think it was an important problem back then, if I understand his comment correctly.

Another security study making the rounds today in which someone who purports to know a lot about analyzing security — whose blog tagline, in fact, cautions that “we should try not to simplify [security] to the point of uselessness” — has decided that a product becomes less secure when the developer fixes and discloses vulnerabilities that they find in-house. What Jeff Jones, a director of Security Strategy at Microsoft, has done is simply counted the number of fixed vulnerabilities reported by each of Microsoft and Mozilla, grouping by labelled severity.

What could be simpler? Perhaps nothing. What could be more useless? Again, perhaps nothing.

You can only count what the vendor wants you to see

If Mozilla wanted to do better than Microsoft on this report, we would have an easy path: stop fixing and disclosing bugs that we find in-house. It is well known that Microsoft redacts release notes for service packs and bundles fixes, sometimes meaning that you get a single vulnerability “counted” for, say, seven defects repaired. Or maybe you don’t hear about it at all, because it was rolled into SP2 and they didn’t make any noise about it.

We count every defect distinctly. We count the ones that Mozilla developers find in-house. We count the things we do to mitigate defects in other pieces of software, including Windows itself and other third-party plugins. We count memory behaviour that we think might be exploitable, even if no exploit has ever been demonstrated and the issue in question was found in-house. We open our bugs up after we’ve shipped fixes, so that people don’t have to take our word for our severity ratings.

While Microsoft’s senior technical staff are trying to get severity ratings dialed down (unsuccessfully; kudos to MSRC for sticking to their guns), we are consistently rounding our severities up when there’s any doubt at all.

More fixes means less security?

Even if the scales were the same, and we were living in a parallel universe in which Microsoft even approached Mozilla’s standards of transparency and disclosure, the logic is just baffling: Jeff is saying that Mozilla’s products are less secure than Microsoft’s because Mozilla fixed more bugs. By that measure, IE4 is even more secure, because there were no security bugs fixed in that time frame; bravo to Microsoft for that!

I use Microsoft’s software products myself; I’m typing this on a machine that’s running Vista, in fact. Not only am I pretty upset that we see Microsoft referencing this report without disclosing that it was written by a Microsoft director of Security Strategy, but I’m also concerned for my own safety. Do people in charge of security strategy at Microsoft really believe that aggressively concealing the count of fixes that do make it out makes a product more secure? Shouldn’t they be trying to fix more bugs, rather than writing reports that would “punish” them for actively improving the security of their users rather than hoping that defects aren’t found by someone who they can’t keep quiet?

Microsoft should be embarrassed to be associated with this sort of ridiculous “analysis”. We don’t pretend that hiding the rate of fixes improves our users’ security in any way, and we never will. We’re transparent and aggressive in dealing with security issues, and 130 million Firefox users are safer for it every day.

Last Wednesday morning, we were informed that a bug in Quicktime could be used to send untrusted code to a part of Firefox that didn’t expect it. Today, Firefox 2.0.0.7 has been released for your updating pleasure. Seven Six-and-a-quarter days, by my math, including two and a half days of baking on the update-beta channel after our dedicated QA team signed off. Just sayin’.

(While I’m sayin’, though: hats — I will need some parallel haberdashery for this — off to the QA and release-driver folk, and especially to the build team who saw their hard work on automation really pay off huge for us, and for our many, many millions of users.)

Update: a toast!

I’ll write more about this later, but since people are starting to pick this up, I want to get this out quickly.

When I wrote “ten fucking days” on a card for Robert (rsnake), I was intending to express my confidence in our ability to turn around a fix quickly if we needed to, by giving him a sort of “admit one” ticket for a disclosure that he thought needed an especially fast response due to extreme risk or some such. That was a bit overzealous, in the cold light of hindsight, but at no point did I intend to indicate that Mozilla policy was a ten-day turn around on all disclosed vulnerabilities. People are reading the conversation and Robert’s post that way, but that’s not our situation, and it certainly wasn’t my intent to give that impression.

I apologize, and hope that nobody will think less of Mozilla because of my error. We don’t issue challenges, and nobody here thinks that security response is a game. This was a personal bargain and overwrought showmanship from a late-night Black Hat party that has now taken on a life of its own, and I hope the fracas about my overzealous comments to Robert don’t overshadow the great work that people on the Mozilla project do to keep our users secure.

[Update: Window has posted on this topic as well, over at the Mozilla security blog.]

Back at the Boston DevDay in March, Window asked me if I’d be interested in speaking with her at Black Hat. Just as I would if Tony Hawk asked if I’d like to hit the half-pipe with him, I agreed enthusiastically, and the fruit of that agreement — and Window’s patience as co-speaker and designated grown-up — will be available this Thursday, when we present Building and Breaking the Browser at this year’s Black Hat Briefings in Las Vegas. Window will be talking about how process, product design and tools all help us build a more secure product, and how those techniques and strategies can help others make their own software more secure. Jesse will, I believe, be demonstrating one of his killer tools. I’ll be wondering why I stayed at our most chill party until the early morning when I knew I had to be on stage at 10AM, and trying to not make it totally obvious that I’m the dumbest guy in the room.

A nice article about Fidelity and open source has two things that I find especially nice, in this one paragraph alone:

The Mozilla Firefox browser was an eye-opener, added Mike Askew, who also works in the technology center. A head-to-head comparison of Firefox and Internet Explorer showed that both had about the same level of security vulnerability, but ”the time needed to fix vulnerabilities in Firefox was much less,” Askew said. That experience led Fidelity to look at open source more intently.

First, I do quite like to hear that our success is making people look at other open source offerings more seriously. It’s not a primary goal for the project, but it’s one of the nice unintended consequences that we get as a bonus.

Second, I like to see people evaluating security characteristics of software in a more nuanced way than simple advisory or vulnerability count. Not all bugs are equal (as is perhaps obvious now, in the throes of the WMF vulnerability, though that’s not an IE bug), and even with severity weighting you are still faced with what are likely even more important questions. Chief among them might well be “how long am I likely to be exposed once a bug is found, or publicized?” If you believe that history is a useful, if imperfect, guide, then something like this vulnerability-window study might be of interest. If not, then you’ll have to do more research, which I very much hope you’ll publish.

In 1996, I watch Peter Gutmann present a paper about how extremely difficult it is to delete data from hard drives such that it is deleted for keepsies. I remember the discussions with Marcus and others afterwards that centered around how incredibly doomed we were, as security professionals.

It might be that time again. I sort of hope I only have one of these doomed moments once a decade.