RE: IE ActiveX 0day? Sep 15 2006 03:40PM
Hayes, Bill (Bill Hayes owh com) (1 replies)
Re: IE ActiveX 0day? Sep 18 2006 04:44PM
Alexander Sotirov (asotirov determina com)
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

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus