Fuzzing shouldn't work!

After the Month of Browser Bugs ended in August 2006, I imagined that browser fuzzing will be over soon. The widespread awareness of this technique and the release of multiple HTML and ActiveX fuzzers were going to help eradicate all easily-found bugs. Vendors were going to incorporate fuzzing in their QA process, and I expected that running a fuzzer in 2007 would be pointless.

It turns out that I was wrong. After the release of Vista, I ran a very simple ActiveX fuzzer against it and only a few minutes later I hit a NULL pointer dereference bug in Internet Explorer. You can read the full advisory at our security research site.

The ActiveX fuzzer I used was extremely simple - it instantiated each available ActiveX control and accessed all its properties. It didn't even have to send any malformed data or long strings, just accessing the ActiveX object was enough to crash the browser. Something this simple isn't supposed to work!

I agree with Microsoft's assessment of the bug as something that's probably not worth fixing in a security update, but the fact stands: this is a bug that should have been found and fixed very early in the development cycle. Maybe next time they'll do better.

Vendor acknowledgement policies

In a recent post on the Matasano blog, Dave G. asks whether acknowledging MOAB in their latest QuickTime security update was a wise decision on Apple’s part. I believe that it was, and I recommend that other vendors follow this practice as well.

Microsoft has a stated policy against acknowledging the work of researchers that do not follow their "responsible" disclosure guidelines. This policy has been successful in encouraging the security industry to play by Microsoft's rules, but their definition of "responsible disclosure" is still far from universally accepted. A quick look at milw0rm or bugtraq shows there are many independent researchers who disclose vulnerabilities and publish exploits with no regard for any policies other than full disclosure.

What is the best way for a vendor to handle a publicly disclosed vulnerability? Releasing a workaround or a patch should have the highest priority, but the vendor's responsibilities do not end there. Many advisories are needlessly vague in describing the vulnerabilities, even though the vendor admits that the information is already public. This makes it harder for security teams to evaluate both patched and unpatched bugs and to realistically assess their exposure.

If you don't believe me, take the following challenge:

Without installing any security updates or running any PoC code, find out which of the MoBB vulnerabilities have been patched, and list the corresponding Microsoft security bulletins.

The vendors are in the best position to provide this information. It is not as important that they they credit the researchers, but they need to provide links to all publicly available information about all vulnerabilities addressed in each patch. This is exactly what Apple did by acknowledging MOAB in their latest QuickTime security update, and I commend them for it.

What's wrong with WMF?

As a kid I was fascinated by the Indiana Jones movies and their portrayal of the brave explorer searching for artifacts in ancient tombs and ruins. These days my job as a security researcher involves a certain amount of software archeology. Many software vulnerabilities are a result of old and long forgotten code, often interacting in unexpected ways with new systems.

A great example for this is the WMF file format, a source of multiple vulnerabilities over the last two years. This format was based on a wrong design decision which has come to haunt Microsoft ever since. In this post I will describe the fundamental design flaws in the WMF format and analyze a new attack that was disclosed publicly today.

WMF is different from typical bitmap graphics file formats. It contains a sequence of processing instructions that are interpreted by the display system and used to draw an image. In this the format is similar to PostScript. Unlike PostScript however, the WMF file format is not based on an abstract graphics language, but instead maps directly into Windows API calls. Each record in the file contains the arguments for a single Windows API function. An advantage of this design is the ability to open a WMF file and record a series of Windows API calls into it. When the file is viewed later, the API calls will be replayed and will draw the image. Unfortunately, this design violates one of the main requirements for secure system - a clear separation of trusted and untrusted data.

The Windows API makes the fundamental assumption that the program issuing API calls is trusted. If the program passes invalid arguments to an API function, it will crash, and the programmer will have to fix it. Unlike the syscall interface to the kernel, the Windows API functions are running at the same privilege level as the program that calls them. This makes it possible to omit a lot of parameter validation.

When we introduce WMF files into this system, the basic assumption breaks. WMF files downloaded from the Internet are untrusted, and so are the parameters that they pass to the Windows API functions. If an untrusted parameter is passed without validation, the WMF file will be able to crash or exploit the program that displays it.

An example of this kind of attack was posted on milw0rm earlier today. The WMF file created by the exploit calls the CreateBrushIndirect function and passes it a LOGBRUSH structure from the file without validating any of its contents. According to the MSDN documentation, the lbHatch field in the structure is a constant specifying the hatch style of the brush. However, when the lbStyle field is BS_DIBPATTERNPT, the lbHatch parameter is used as a pointer to a device-independent bitmap structure in memory.

The PoC code on milw0rm sets the lbStyle field to BS_DIBPATTERNPT and passes an invalid pointer value in lbHatch. This value is dereferenced inside GDI32.DLL. Since this address is invalid, the memory access causes an unhandled exception and the program displaying the WMF file crashes. The impact of the vulnerability is limited and does not allow remote code execution, but it is still a good illustration of the fundamental problem with the WMF format.

Solving this problem is not easy, but it can be done. Writing a formal specification for the WMF format and implementing a validating parser would be a good first step. The mapping between each WMF record and Windows API function must be audited for unexpected interactions and issues such as the one described above. Only then can we be reasonably sure that the WMF format is reasonably safe to use for untrusted Internet content.

Vulns in Vista, no way?

I certainly applaud the efforts that Microsoft has made in improving the security in Windows. I don't know the other vendors well, but they're ahead of most other ISVs.

However, to think that means there won't be vulnerabilities in Vista is sort of silly. Simply stated, new or changed code means that there will be new vulnerabilities given the state of art of application security testing today.

For example, we just started a new initiative on our website today with a zero-day page where we record significant zero-day vulnerabilities that may be of interest to our customer base. We recently reported 5 such vulnerabilities to Microsoft in Vista.

I wonder what 2007 will bring. 2006 saw a significant increase in 0-days with IE being openly vulnerable for 284 days during the year as documented by Brian Krebs, and lots of Office 0-days that seemed timed to come just after 'Patch Tuesdays'.

Vista notices

Recently, there has been the start of some discussion around vulnerabilities on Vista. The NYT and CNBC were interested in what we've done in that area recently. See our research page for some more details...