Feedback from Opera on Mozilla JavaScript fuzzer

Claudio Santambrogio at Opera posted that they have been running the Mozilla JavaScript fuzzer and as of Friday have found and fixed 4 issues with it. I am thrilled. This is exactly what we hoped would happen. Hopefully, this will encourage other vendors to share their internal security tools with everyone so we call all make our software more secure.

Mike Shaver, ten days, and expletives

Mike Shaver (Director of Ecosystem Development at Mozilla) handed his business card to Robert Hansen (RSnake) on Wednesday night at Black Hat. On it he wrote “ten f—ing days.” When I asked him about it, he said he meant to communicate to Robert that since Mozilla got a recent security update out in only ten days, that there was no reason for Robert to post details of vulnerabilities publicly before a patch was available. Since we’re among the most responsive software vendors, security researchers do not have to resort to full disclosure to get us to patch bugs quickly.

Well, whatever he meant, his statement has taken on a life of its own. Robert posted on his blog, and a bunch of news articles picked it up as a challenge.

This is the official Mozilla word: This is not our policy. We do not think security is a game, nor do we issue challenges or ultimatums. We are proud of our track record of quickly releasing critical security patches, often in days. We work hard to ship fixes as fast as possible because it keeps people safe. We hope these comments do not overshadow the tremendous efforts of the Mozilla community to keep the Internet secure.

JavaScript fuzzer available

Mike Shaver and I just finished presenting “Building and Breaking the Browser”at Blackhat today in Las Vegas. We discussed the methods and tools that Mozilla uses to secure the Firefox browser. These tools include a fuzzer for Javascript, which has led to the discovery and resolution of dozens of critical security bugs. Fuzzers are tools that generate a large amount of input in order to test the robustness of a piece of software and can be used to identify potential vulnerabilities.

This is the tool we discussed in our presentation, the first in a series of security tools that we intend to make publicly available.

https://bugzilla.mozilla.org/show_bug.cgi?id=jsfunfuzz

The responsible sharing of security tools is an important way to contribute to the overall health of the web. We worked with Microsoft, Apple, and Opera to reduce the possibility that this tool might adversely affect users of those browsers. All of these browser vendors reviewed the tool and let us know that they were okay with the release.

Off to Black Hat!

I’m heading to Las Vegas tomorrow for the Black Hat Briefings. If you’re in town you can catch me speaking on Thursday morning on Building and Breaking the Browser.

You can also catch up with me Wednesday afternoon on the Future of Information Security panel or Thursday afternoon on the Ethics Challenge panel.

After you roll in from all the parties on Wednesday night, stop by Royal 55, Augustus Tower in Caesar’s Palace to have milk and cookies with Mozilla. It’s a super chill pajama party with some of the people who make Firefox. Pajamas not required. Stop by on your way to bed. We’ll be there 11pm to 2am and possibly later.

Firefox 2.0.0.6 now available

We’ve just released Firefox 2.0.0.6 which contains a security patch to mitigate the issue described here. The patch enables percent-encoding for spaces and double-quotes in URIs handed off to external programs. This reduces the risk of malicious data being passed through Firefox to another application that may then trigger unexpected and potentially dangerous behavior.

Get Firefox 2.0.0.6 here.

Read the release notes for Firefox 2.0.0.6 here.

Congratulations and thank you to the dev, QA, and build teams, and all the community members that worked so hard to get this fix out quickly to our users.

Launching local programs through FileType handler

Issue
We are currently investigating an issue on Windows XP, where some urls for “web” protocols that contain %00 launch the wrong handler and appear to be able to launch local programs, with limited argument passing.

Impact
The impact to users is unknown at this point in time. We are working to verify this and in the meantime, advise users to be cautious when browsing unknown sites.

Status
We are currently working on a fix. You can follow our work and process at: https://bugzilla.mozilla.org/show_bug.cgi?id=389580

Credit
Billy Rios and Nate McFeters posted details about this issue publicly at:http://xs-sniper.com/blog/remote-command-exec-firefox-2005/

Related Security Issue in URL Protocol Handling on Windows

On July 10th, I posted about a security issue in URL protocol handling on Windows. In the previous example, Internet Explorer was the entry point and Firefox was the application receiving the bad data.

Over the weekend, we learned about a new scenario that identifies ways that Firefox could also be used as the entry point. While browsing with Firefox, a specially crafted URL could potentially be used to send bad data to another application.

We thought this was just a problem with IE. It turns out, it is a problem with Firefox as well. We should have caught this scenario when we fixed the related problem in 2.0.0.5. We believe that defense in depth is the best way to protect people, so we’re investigating it now.

We are working to make sure that we are giving you as much information about pressing security issues as possible. We make real-time updates as we find out new information because we are committed to an open and transparent security process.

For more information: https://bugzilla.mozilla.org/show_bug.cgi?id=389106

BaySec is tonight!

If you are a security geek in the bay area, find your way to O’Niell’s on 3rd and King Street in San Francisco at 7pm to meet up at BaySec. I’ll be there to celebrate shipping Firefox 2.0.0.5. I may even have some Mozilla and Firefox goodies to give out. Say hi if you see me there.

Details here: http://www.sockpuppet.org/baysec/

Fix for Windows URL Protocol Handling Problem in Firefox 2.0.0.5

Firefox 2.0.0.5 is now available and there is a fix for the URL protocol handling issue described here. We warned that other Windows applications may be vulnerable to this Internet Explorer issue, and on Sunday Nate Mcfeters, Billy Rios, and Raghav Dube posted a proof of concept that demonstrates the same attack through Internet Explorer to execute code in Trillian.  Additionally, Thor Larholm says I can still automatically launch a wide range of external applications from Internet Explorer and provide them with arbitrary command line arguments. AcroRd32.exe (Adobe Acrobat PDF Reader), aim.exe (AOL Instant Messenger), Outlook.exe, msimn.exe (Outlook Express), netmeeting.exe, HelpCtr.exe (Windows Help Center), mirc.exe, Skype.exe, wab.exe (Windows Address Book) and wmplayer.exe (Windows Media Player) - just to name a few.”

This patch for Firefox prevents Firefox from accepting bad data from Internet Explorer. It does not fix the critical vulnerability in Internet Explorer. Microsoft needs to patch Internet Explorer, but at last check, they were not planning to. Mark Griesi is quoted in Infoworld saying “We don’t feel that there’s an issue in IE, and therefore, there’s nothing to be fixed.”

Mozilla recommends using Firefox to browse the web to prevent attackers from taking advantage of this vulnerability in Internet Explorer.

Security Issue in URL Protocol Handling on Windows

Today security firm Secunia released an advisory on a security issue found (apparently) simultaneously and independently by Greg MacManus and Billy Rios based on a previously reported issue in Safari found by Thor Larholm.

Any Windows application that calls a registered URL protocol without escaping quotes may be used to pass unexpected and potentially dangerous data to the application that registers that URL Protocol. This could result in a critical security vulnerability.

The vulnerability is exposed when a user browses to a malicious web page in Internet Explorer and clicks on a specially crafted link. That link causes Internet Explorer to invoke another Windows program via the command line and then pass that program the URL from the malicious webpage without escaping the quotes. This can cause data to be passed accidentally from the malicious web page to the second Windows program. In the specific attack described in the report, Internet Explorer sends URL data to Firefox. If the data is crafted a certain way it will allow remote code execution in Firefox.

A similar interaction between Safari and Firefox was reported earlier and fixed by Apple. According to Ryan Naraine at ZDNet, Microsoft is not planning to release a patch at this time.

Mozilla believes in defense in depth and will be patching Firefox in the upcoming 2.0.0.5 release to mitigate the problem. This will prevent IE from sending Firefox malicious data. Other Windows programs may also be vulnerable to bad data being passed from IE although we are not aware of any at this time.

It is important to note that if you are using Firefox to browse the web you *are not* vulnerable to this attack. While we have seen no evidence of attackers exploiting this issue, there is proof of concept code available publicly. So we recommend that people use Firefox and as always take care when browsing unknown websites.

We appreciate the work of the security researchers who identified this issue and the thousands of Mozilla community members who test patches and enable us to ship fixes so quickly. Mozilla is committed to identifying, prioritizing and fixing bugs to deliver the safest online experience for its users. We fix all bugs with any security risk as part of our commitment to security.