Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:9516
HistoryAug 18, 2005 - 12:00 a.m.

[Full-disclosure] COM objects and MSIE vulnerabilities recap + additional fix

2005-08-1800:00:00
vulners.com
5

Disclaimer:
The information in this email is distributed WITHOUT ANY WARRANTY, TO THE
EXTENT PERMITTED BY APPLICABLE LAW; without even the implied warranty of
CORRECTNESS or FITNESS FOR A PARTICULAR PURPOSE. You know the drill…
Affected products:
Various COM objects when loaded in Microsoft Internet Explorer.
Extend:
DoS and remote arbitrary code execution.
Patches:
MS05-037 and MS05-38
See below for additional killbit.
Exploits:
Internet Exploiter 4 will not be released to the public in the near future.
Public exploits based on Internet Exploiter have been written by third
parties for a number of affected objects. They are available on the net
from various sources.
Short description:
A number of issues have been reported lately by various sources about
Internet Explorer vulnerabilities in relation to specific COM objects.
Research has shown that the root cause is the fact that these COM objects
are not designed to be loaded in IE at all. These objects therefore make
wrongful assumptions about the state of the process they are loaded into,
specifically about the contents of heap memory. This can be abused to
uncover unwanted features, like the ability to run arbitrary code on a
victims machine.

Short History:
On June 24th 2002 'ken'@FTU reported a NULL-pointer exception in IE when
loading a specific COM object. The object was mmsys.cpl which uses
clsid:{00022613-0000-0000-C000-000000000046}. The issue was discarded as
a low impact DoS.
On April 18th 2005, Further research revealed that this was in fact a
problem with the COM object reusing previously freed memory without
initialising it. Part of the reused memory was used as a function pointer.
Careful allocating and freeing of memory prior to loading the object
allowed remote code execution on Win2K. Internet Exploiter 4 was born.
(This vulnerability does NOT seem to be exploitable on WinXPSP2, as claimed
by FrSIRT in their MS05-038 exploit)
On June 17th 2005, Bernhard Muller and Martin Eiszner found a similar issue
when loading javaprxy.dll and released their information to the public.

On July 2nd, August 9th and August 17th 2005, FrSIRT released shamelessly 
ripped code that claims to exploit a number of these objects. While failing
to work on most occasions through lack of finesse, it does prove that even
script-kiddies can easily write exploits by copy-pasting my Internet 
Exploiter heap spraying code. It takes so little effort that it might
actually cost you more time to add proper credits to the original author
of the code.

Solution:
I've been working with the Internet Explorer team on short term and long
term solutions. The latest patch (MS05-038) will "killbit" a number of
objects that were found to have issues when loaded in IE. These killbits
prevent exploits from loading these objects and abusing this vulnerability.
The latest exploit by FrSIRT targets "msdss.dll" with clsid
EC444CB6-3E7E-4865-B1C3-0DE72EF39B3F, which is not killbitted by ms05-038.
I was unable to reproduce the vulnerability with version 7.10.3077.0 of the
dll; the object doesn't even crash. From what I've heard everybody else
seems to be unaffected too, so maybe it's just a local .fr thing.
Just in case, here's a .reg file you can use to killbit this control;
Create a new .txt file, copy+paste this into it, rename it to .reg, double
click it and say "yes, I want to add it to the registry."
!!! Lines may wrap, you might have to remove the extra line-breaks !!!
---- cut here ----
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{EC444CB6-3E7E-4865-B1C3-0DE72EF39B3F}]
"Compatibility Flags"=dword:00000400
---- cut here ----
If you want to test if it works, here's a .html file that will show you;
Create a new .txt file, copy+paste this into it, rename it to .html, double
click and it will tell you if you are safe (the object cannot be loaded)
or if you might be vulnerable to this attack (the object can be loaded):
---- cut here β€”
<OBJECT
onreadystatechange="document.write('<I>Possibly</I> Vulnerable…');"
onerror="document.write('You should be safe!');"
classid="clsid:{EC444CB6-3E7E-4865-B1C3-0DE72EF39B3F}"
></OBJECT>
---- cut here β€”

Greets:
Paul@greyhats, st0ke@milworm, 0dd, 0x4553, l33tsecurity, NGS.

Anti-Greets:
FrSIRT (I thought I was special, turns out they rip-off everybody's code!)

Cheers,
SkyLined