Hayes, Bill wrote:
> It looks like the flaw is a buffer overflow and not a memory corruption
> error.
Actually, the vulnerability is an integer overflow which leads to a buffer
overflow which leads to memory corruption.
KeyFrame(npoints, ...)
{
buf = malloc(npoints*16)
copy stuff into buf
}
What is your definition of memory corruption? How can a buffer overflow not be a
memory corruption error?
> FrSIRT claims that by sending a specially-crafted argument to the
> DirectAnimation.PathControl" (daxctle.ocx) ActiveX object, a local or
> remote attacker can cause a memory corruption error that leads either to
> a Denial of Service (DoS) condition, execution of arbitrary code. As a
> workaround, FrSIRT is recommending disabling Active Scripting in the
> Internet and Local intranet security zones. This will obvioulsy break a
> number of pages.
There is a better workaround than disabling ActiveX - set the kill bit on the
DirectAnimation.PathControl CLSID. Nobody uses that control anyway.
> Symantec SecurityResponse blog states that Symantec researchers have
> determined that the flaw in the DirectAnimation Path ActiveX Control is
> in fact a buffer overflow instead of a memory corruption error. Symantec
> researchers now believe that the buffer overflow occurs "when IE tries
> to instantiate a certain DirectionAnimation COM object as an ActiveX
> control." The blog note says that remote execution of arbitrary code is
> possible.
This flaw is not an object instantiation bug. It happens when you call the
KeyFrame method of the object with a large argument.
Alex
