Still Overflowing After All These Years

By Larry Seltzer  |  Posted 2008-09-15 Print this article Print

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.

Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel