As far as the IE vuln goes:
This is not a traditional heap overflow, just look at how it is being exploited.
In a traditional heap overflow, we'd see them performing some type of allocation foo or shoving a lot of data into a small buffer or something along those lines, but that is not the case here. The block of XML that triggers the vuln is too small and does not have any of the indicating factors of traditional heap overflows. (This should not be confused with the fact that a heap spray is being used in the exploits we've found in the wild, that makes exploitation more reliable, but does not indicate a heap overflow always).
This is a use after free. If you debug it, you'll see that memory is free()'d, but dangling references are left to the free'd object, so if that block of memory is reallocated and filled with user controlled data, we can control a virtual function pointer and call into any area of memory we like. This makes exploitation very unreliable, in about 20 tests I ran, roughly 4 of them resulted in an exploitable condition, the others either failed to crash (memory was never reallocated) or crashed in a non-exploitable manner (another uncontrollable structure was allocated in place of the controlled data). There are ways of making these more reliable (someone wrote a paper and presentation on it a year ago wrt a IIS vulnerability), but it isn't easy and doesn't improve reliability all that much.
This is a common problem with browsers due to complicated inheritence and a large number of objects that are being handled.
Slashdot Mirror
As far as the IE vuln goes: This is not a traditional heap overflow, just look at how it is being exploited. In a traditional heap overflow, we'd see them performing some type of allocation foo or shoving a lot of data into a small buffer or something along those lines, but that is not the case here. The block of XML that triggers the vuln is too small and does not have any of the indicating factors of traditional heap overflows. (This should not be confused with the fact that a heap spray is being used in the exploits we've found in the wild, that makes exploitation more reliable, but does not indicate a heap overflow always). This is a use after free. If you debug it, you'll see that memory is free()'d, but dangling references are left to the free'd object, so if that block of memory is reallocated and filled with user controlled data, we can control a virtual function pointer and call into any area of memory we like. This makes exploitation very unreliable, in about 20 tests I ran, roughly 4 of them resulted in an exploitable condition, the others either failed to crash (memory was never reallocated) or crashed in a non-exploitable manner (another uncontrollable structure was allocated in place of the controlled data). There are ways of making these more reliable (someone wrote a paper and presentation on it a year ago wrt a IIS vulnerability), but it isn't easy and doesn't improve reliability all that much. This is a common problem with browsers due to complicated inheritence and a large number of objects that are being handled.