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:
- Fwd: IE ActiveX 0day? Tyop Tyip (Sep 15)
- Re: Fwd: IE ActiveX 0day? H D Moore (Sep 15)
- <Possible follow-ups>
- RE: IE ActiveX 0day? Hayes, Bill (Sep 15)
- Re: IE ActiveX 0day? Alexander Sotirov (Sep 18)
- Re: Fwd: IE ActiveX 0day? Juha-Matti Laurio (Sep 15)