eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Its hard to feel comforted by the fact that Windows XP Service Pack 2 was not subject to the more severe of Tuesdays announced vulnerabilities. Even most SP2 users need to scour their systems for vulnerable applications, and the whole affair raises many unpleasant questions.
The bug is not the usual stack-based buffer overflow, but a classic heap-based “integer overflow.” Actually, its really an integer underflow. The problem comes from copying a particular value out of the JPG file. When checking the purported length of a string to copy, the program doesnt sufficiently check for small values before subtracting 2 from the length.
Therefore, if the value is 0 or 1, it will be negative after the subtraction and will be interpreted as a large positive number by the copying routine. Far more data than is proper will be copied, and something will get overwritten.
Its easy to see how one could crash the system with this error, and indeed there is already a proof-of-concept program to demonstrate this. But it is much harder to get a heap-based overflow to execute arbitrary code than a stack-based one, and in a shared library such as this, it could be even more difficult since the heap will be in an even less predictable state.
So, while it may be trivial to use this vulnerability to crash the system—in fact, theres already a proof-of-concept JPG file for this—it take much longer for code execution exploits, especially the canned ones that most attackers need, to show up. In the past, exploits of bugs like this havent always been reliable.
In other words, some of them execute the attack sometimes, but other times they just crash the system. Not to make light of system crashes, but they are a far less serious matter than running arbitrary attack code.
Its also the case that support for NX page marking in SP2 should prevent errors such as this. The next computer I buy, Im going to try to get one that supports NX. I consider all of this very good news.
After reading the descriptions Ive read, I have to say Im surprised at the sloppiness of the code in the error. It sounds like a very elementary error and one that should have been caught.
And speaking of when it should have been caught, TruSecures Russ Cooper raises an excellent point when he points out that this bug was probably found some time ago. It had been found for Service Pack 2 and must have been so a while ago, so why wasnt it fixed in SP1 earlier?
One can only imagine that they thought SP2 was a higher priority, and perhaps they were also comforted by the fact that the vulnerability wasnt generally announced yet. Now, I have to wonder how many other problems were found in the SP2 project that are still lurking in SP1 until Microsoft gets around to patching them there.
Next Page: The GDI+ detection tool.
Detection Tool
Theres another problem with the solutions that Microsoft has provided. Third-party programs can redistribute the vulnerable GDI+ library (generally for older versions of Windows that dont include GDI+ on their own), and Microsoft development guidelines recommend that they install it in their own directory.
This means that just fixing the shared version installed by Windows or the Office version that Microsoft knows how to find doesnt excise the problem completely. You need to find all of the other copies of GDIPLUS.DLL that might be on the system.
For this reason, Microsoft created a tool, the GDI+ Detection Tool, that does such a search. You can read a description of it and get a link to download it in this Knowledge Base article. You need administrative privileges in order to run this application.
Unfortunately, this tool doesnt actually detect programs running the vulnerable versions of GDIPLUS.DLL; it only searches for programs on a fixed list that Microsoft looks for. If you have a third-party program or custom program, it may not be found. The tool also doesnt specify where the vulnerable versions are, it just tells you that you have a problem. So, its worth running, but its far from a complete solution to the problem of random GDIPLUS.DLLs out there.
Because of the third-party application problem, even Windows XP SP2 users should scan for the vulnerable version, but its unlikely to be a problem for them. In most cases, applications would use the OS version of the library, and that one is OK.
And it seems much less likely that a third-party application would be exploited unless it was a mail client or a browser. One can easily imagine a mail worm incorporating this exploit once a canned tool for it is developed. The fruit just hangs so much lower for those programs, but there cant be many of them that redistribute GDIPLUS.DLL—perhaps there are none at all.
As TruSecures Russ Cooper said Tuesday, this bug makes you want your anti-virus to scan everything, not just executable files. Of course, thats not practical, so the solution is to look for suspicious behavior as an IPS (intrusion-prevention system) would do. Fortunately, this is a tool of the future for client-side systems, and we should be reading more about them soon.
There is great potential in this vulnerability, both to be a major problem and to be a major flop. A large number of vulnerable systems are out there, and if someone can figure out a reliable exploit and if they can figure out a good delivery mechanism, then it could cause widespread havoc. But theres no guarantee that will happen.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog.
Be sure to add our eWEEK.com Security news feed to your RSS newsreader or My Yahoo page
More from Larry Seltzer