eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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 immunix.org 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.
Stack and Heap Overflows: Different Animals
Stack overflows and heap overflows are different animals. Heap overflows are much more subtle, but there are some dev tools for you to use. Microsoft’s David LeBlanc developed SafeInt class, a replacement integer class for which operators have been overwritten to force safe handling. (I always thought operator overriding was one of the stupider features of C++; this is the first compelling application I’ve seen of it.) There’s also an intsafe library for C development.
But even with such safeguards in place, things can go wrong. Want a good example of how wrong things can go? Consider this US Cert alert that talks about how C compiler optimizations can end up “optimizing away” code inserted to detect and prevent overflows. The alert was inspired by an actual problem in gcc, but any optimizing compiler should be inspected for this sort of problem. In fact, LeBlanc was concerned enough to check how SafeInt was handled. I’m not clear from his blog if he had a problem or not, but I think not.
People at Microsoft tell me that the vulnerabilities they’re finding these days, especially on old code, are very obscure and difficult to exploit. It’s true that the overall numbers and overall severity of vulnerabilities in Windows is way down from what it was in previous years. They never claimed that they could eliminate all vulnerabilities or even all overflows. These things will always be with us, and it’s a testament to how complicated software is these days that it can’t be completely secured.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s blog Cheap Hack.