Still Overflowing After All These Years (
Page 1 of 2 )
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 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.
