Still Overflowing After All These Years

Even some very old lessons of secure programming turn out to be hard for developers to implement consistently.

A lot of people at Microsoft must have been alternately angry and embarrassed last week at the details of MS08-052. This series of vulnerabilities in GDI+, the graphics core of Windows, had a decidedly retro look to it, as if it belonged to an advisory back in 2002, not 2008.

The advisory describes five vulnerabilities in GDI+, which provides 2-D graphics, imaging and typography facilities in Windows. All five involve errors in buffers when GDI+ parses various data formats: VML, EMF, GIF, WMF and BMP. It appears from the Microsoft descriptions that there are different sorts of buffer abuse at issue; sometimes they use the word "overflow," sometimes "overrun," and sometimes the term "memory corruption" is used. I don't believe any outside researchers have provided clarification yet, but it's just a matter of time.

Several things got me angry about these disclosures. First, many of these formats have a history of similar vulnerabilities over a period of many years. EMF and WMF stand out in particular. There was a famous zero-day exploit of WMF files at the end of 2005 that ruined many a New Year's celebration. There have been other graphics bug roundups, such as this one from 2004. These were high-profile events at Microsoft and I'm sure that many talented people, including perhaps outside services, were put to work auditing this code for problems. And yet they persist.

I happened to be meeting the other day with Steven Lipner, Microsoft's senior director of Security Engineering Strategy, and put my frustration to him. He said he thought the number of potential overflows in this sort of code is immense. It may be that you can't actually eliminate all possible overflows, especially on this sort of code. Code that interprets data structures transferred in from the outside is always exhibit A in the case of the overrun buffer.

So even after years of serious world-class efforts at securing code that was obviously a top candidate for buffer errors, they're still finding them. I'm discouraged.

Of course, Microsoft is not alone in being hit by this old problem repeatedly. The very same day as MS08-052, Apple released numerous updates including one that fixed nine vulnerabilities in QuickTime. Depending on how you read the descriptions (which are about as vague as Microsoft's) at least seven of them are the same sort of buffer nonsense as MS08-052. For instance "[A] heap buffer overflow exists in QuickTime's handling of panorama atoms in QTVR (QuickTime Virtual Reality) movie files." Other very old projects get similar disclosures, such as this stack overflow in the 20-year-old Ghostscript.

And it's not like they're only throwing expertise at the problem. Many tools and programming practices have developed over the years at Microsoft and elsewhere to prevent buffer overflows or mitigate their effect. The granddaddy of these is StackGuard (the StackGuard page never seems to respond), which pioneered the "stack canary" approach of putting special markers on a function stack and epilogue code to check its integrity, under the theory that a stack overflow will also overwrite the marker. Here's the original paper from 10 years ago that introduced StackGuard. This approach has been widely copied, such as in the /GS switch in Microsoft's Visual Studio (since 2003), and has eliminated the most straightforward of stack overflows from a lot of important programs.