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.