Bugtraq mailing list archives

Re: IE ActiveX 0day?


From: Alexander Sotirov <asotirov () determina com>
Date: Mon, 18 Sep 2006 09:44:20 -0700

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


Current thread: