a three-dimensional platform

Firefox now includes, on all desktop platforms, support for a technology known as WebGL. WebGL allows web developers to use accelerated 3D graphics, including textures and shaders; it exposes the same capabilities used by games like Doom 3 and (optionally) World of Warcraft, and virtually every game that runs on the iPhone, OS X, Android or Linux.

Security professionals, including Context IS, have discovered bugs in the specification (related to cross-domain image loading) and in Firefox’s specific implementation. Both are being addressed, as with security problems in any other technology we ship, but recently the conversation has turned to inherent security characteristics of WebGL and whether it should be supported at all by browsers, ever.

I think that there is no question that the web needs 3D capabilities. Pretty much every platform has or is building ways for developers to perform low-level 3D operations, giving them the capabilities they need to create advanced visualizations, games, or new user interfaces:

  • Adobe is building 3D for Flash in a project called “Molehill“, about which they say: “In terms of design, our approach is very similar to the WebGL design.”
  • Microsoft is doing something similar with Silverlight 5, where they’re bringing XNA Graphics to Silverlight 3D.

Adding new capabilities can expose parts of the application stack to potentially-hostile content for the first time. Graphics drivers are an example of that, as are font engines, video codecs, OS text-display facilities (!) and image libraries. Even improvements in existing capabilities can lead to new types of threats that need to be modelled, understood, and mitigated. We have a number of mitigations in place, including a driver whitelist that’s checked daily for updates; this seems similar to the driver-blocking model used in SL5, based on what information is available. Shaders are validated as legal GLSL before being sent to the driver (or to Direct3D’s HLSL compiler), to avoid problems with drivers mishandling invalid shader text. We’re also working with the ARB and driver vendors on extensions to OpenGL which will make the system even more robust against runaway shaders and the like.

Microsoft’s concern that a technology be able to pass their security review process is reasonable, and similar matters were the subject of a large proportion of the discussions leading to WebGL’s standardization; I also suspect that whatever hardening they applied to the low-level D3D API wrapped by Silverlight 3D can be applied to a Microsoft WebGL implementation as well. That Silverlight supports Mac as well, where these capabilities must be mapped to OpenGL, makes me even more confident. The Microsoft graphics team seems to have done a great job of making the D3D shader pipeline robust against invalid input, for example. (The Windows Display Driver Model in Vista and Windows 7 is a great asset here, because it dramatically reduces the “blast radius” of a problem at the driver level. This likely explains the difference between default-enable and default-disable for WDDM/non-WDDM drivers in SL5′s 3D support. It’s not yet clear to me what the model will be for SL5 on OS X.)

It may be that we’re more comfortable living on top of a stack we don’t control all the way to the metal than are OS vendors, but our conversations with the developers of the drivers in question make us confident that they’re as committed as us and Microsoft to a robust and secure experience for our shared users. Web developers, like all developers, need good 3D support, and — as with Flash and Silverlight — browser implementers will need to be careful and thoughtful about how to expose that functionality securely on all operating systems.

updating the update, as it were

I made an update to my WPF timeline post, but I wanted to make sure that the correction was seen by people who may not revisit that post.

The SRD blog post which revealed that Firefox users were also exposed to the IE vulnerability was published on Tuesday, not Monday. The post is labelled as having been published Monday, and the timeline including that survived review by Microsoft, but nonetheless it was an error that I published, so I’ll own it. To the best of my knowledge, the SRD post which informed us and the world of the Firefox exposure was published on Tuesday after the patch and bulletins were first made available to Windows users.

You guys all about ready to have this thing entirely behind us? Yeah, me too. Me too.

update on the .NET Framework Assistant and Windows Presentation Foundation plugin blocking from this weekend

There’s a fair bit of confusion circulating about what happened, and what’s going to happen next, which is understandable — it’s been confusing! I’ll summarize here what happened, and what’s next.


The add-on and plugin in question have a long and storied history, but for the events of this weekend the timeline basically starts this summer:

July 2009: Mark Dowd, Ryan Smith, and David Dewey present a paper at Black Hat detailing vulnerabilities in Internet Explorer and other software (including some Firefox plugins, such as Google’s Native Client, but not including Firefox itself or the Windows Presentation Foundation plugin).

Tuesday, October 13: Microsoft’s Security Research & Development team posts on their blog revealing that one of the Internet Explorer vulnerabilities in the Dowd and co. paper can be used to attack Firefox users through the use of this IE component in the Windows Presentation Foundation plugin. This plugin was and is distributed as part of Windows .NET Framework 3.5. As part of Patch Tuesday, Microsoft releases MS09-054 and its associated cumulative update, labeled as an Internet Explorer patch. (The bulletin has subsequently been updated to mention Firefox, see below.)

Friday, October 16: Mozilla contacted Microsoft to learn more about the exposure of our shared users. We discussed the nature of the vulnerability as well as the difficulty of uninstalling the plugin and add-on, and agreed that Mozilla should blocklist the add-on and plugin while we sorted out how best to ensure that Firefox users on Windows were protected. The SRP blog post was updated to indicate that Firefox users who applied the patch were protected from the vulnerability.

Saturday, October 17: Based on feedback from users (chiefly enterprise users), our web team began work on mechanisms for an overridable block (“soft block”) capability for Firefox 3.5 users. Discussions with Microsoft indicated that the add-on was a possible vector for the exploit, so it remained blocked.

Sunday, October 18: Microsoft informed us that the add-on (.NET Framework Assistant) was NOT a means for exploiting the vulnerability, and we removed it from the blocklist. The Windows Presentation Foundation plugin was confirmed to be exploitable unless the patch was applied, and remained on the blocklist. The MS09-054 bulletin was updated by Microsoft to include text about Firefox users.

Monday, October 19: We updated our blocklist management system to permit “soft blocks”, and adjusted the blocklist entry for the Windows Presentation Foundation plugin so that users who know they have the appropriate IE patch installed can re-enable the plugin.

Next Steps

Microsoft is monitoring patch adoption rates for the relevant patch, and when it reaches a high level of deployment we will remove the remaining blocklist item. I expect that will be in the next 48 hours at the outside.

Users of Windows 7 RTM are not affected, as the add-on and plugin are not distributed as part of Windows 7. Microsoft is working with Mozilla to make the functionality available to Firefox users in a user-controlled way for all operating systems in the future.

Stephanie Boesch, Director of Program Management at Microsoft, coordinated with Mozilla on this issue, and I want to thank her for her responsiveness and help throughout. She says: “Security is a top priority for all Microsoft customers, and we jointly decided the best course of action was to temporarily block the plugin and add-on while Firefox customers applied the Internet Explorer Security Update. We appreciate Mozilla’s shared commitment to protecting our mutual customers and look forward to working more closely with them in the future on such issues.”

Updated (Wed, Oct 21): fixed a timeline error caused by the SRD blog post having an incorrect publishing date on it, which even survived MSFT review of the timeline. The SRD post was published on Tuesday, not Monday.

[Comments are closed on my blog, but you can leave comments at the Mozilla Security Blog post on the topic if you'd like.]

.NET Framework Assistant blocked to disarm security vulnerability

I’ve previously posted about the .NET Framework Assistant add-on that was delivered via Windows Update earlier this year. It’s recently surfaced that it has a serious security vulnerability, and Microsoft is recommending that users disable the add-on if they have not installed IE patch MS09-054.

Because of the difficulties some users have had entirely removing the add-on, and because of the severity of the risk it represents if not disabled, we contacted Microsoft today to indicate that we were looking to disable the extension and plugin for all users via our blocklisting mechanism. Microsoft agreed with the plan, and we put the blocklist entry live immediately. (Some users are already seeing it disabled, less than an hour after we added it!)

Updated to reflect updates to Microsoft blog post. Also, the add-on was confirmed to not be a vector for the vulnerabilites, so it was removed from the blocklist. The plugin is still blocked pending more information about patch deployment rates; work is underway to make the blocking overridable to accommodate enterprises and sophisticated users who know they have installed the IE patch.

failure is not an option

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 recommendsout 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.

view-source/resource “vulnerability” does not expose personal information

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 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.

counting still easy, critical thinking still surprisingly hard

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.

not that I was counting or anything

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 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!

about ten days at black hat

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.]

vegas, baby

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.

next page »