------=_Part_1173_32018819.1124329567242 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 M=FCller and Martin Eiszner found a similar iss= ue 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=20 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=20 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=20 Compatibility\{EC444CB6-3E7E-4865-B1C3-0DE72EF39B3F}] "Compatibility Flags"=3Ddword: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 --- Possibly Vulnerable...');" onerror=3D"document.write('You should be safe!');" classid=3D"clsid:{EC444CB6-3E7E-4865-B1C3-0DE72EF39B3F}" > ---- 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 ------=_Part_1173_32018819.1124329567242 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Disclaimer:
    The information in this email is distr= ibuted WITHOUT ANY WARRANTY, TO THE
    EXTENT PERMITTED = BY APPLICABLE LAW; without even the implied warranty of
  &nbs= p; 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:
    Inte= rnet Exploiter 4 will not be released to the public in the near future.
=     Public exploits based on Internet Exploiter have been wr= itten by third
    parties for a number of affected objects. They are a= vailable on the net
    from various sources.

Short description:
    A number of issues have been re= ported lately by various sources about
    Internet Explo= rer vulnerabilities in relation to specific COM objects.
  &nb= sp; Research has shown that the root cause is the fact that these COM objec= ts
    are not designed to be loaded in IE at all. These ob= jects therefore make
    wrongful assumptions about the s= tate of the process they are loaded into,
    specificall= y about the contents of heap memory. This can be abused to
    uncover unwanted features, like the ability to run a= rbitrary code on a
    victims machine.
  &n= bsp;
Short History:
    On June 24th 2002 'ken'@FTU reported a NULL-pointer exception in IE whe= n
    loading a specific COM object. The object was mmsys.= cpl which uses
    clsid:{00022613-0000-0000-C000-0000000= 00046}. The issue was discarded as
    a low impact DoS.<= /p>

    On April 18th 2005, Further research revealed that th= is 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 lo= ading the object
    allowed remote code execution on Win= 2K. Internet Exploiter 4 was born.
    (This vulnerabilit= y does NOT seem to be exploitable on WinXPSP2, as claimed
    by FrSIRT in their MS05-038 exploit)
  =   On June 17th 2005, Bernhard M=FCller and Martin Eiszner found a simi= lar issue
    when loading javaprxy.dll and released thei= r information to the public.
   
    O= n 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 thr= ough 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 eff= ort 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 Expl= orer 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 kil= lbits
    prevent exploits from loading these objects and abus= ing this vulnerability.

    The latest exploit by FrSIRT targets "msdss.dll&= quot; with clsid
    EC444CB6-3E7E-4865-B1C3-0DE72EF39B3= F, which is not killbitted by ms05-038.
    I was unable = to reproduce the vulnerability with version=20 7.10.3077.0 of the
    dll; the object doesn't even crash= . From what I've heard everybody else
    seems to be un= affected too, so maybe it's just a local .fr thing.
    J= ust in case, here's a .reg file you can use to killbit this control;
    Create a new .txt file, copy+paste this into it, ren= ame it to .reg, double
    click it and say "yes, I = want to add it to the registry."
    !!! Lines may w= rap, 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 Compati= bility\{EC444CB6-3E7E-4865-B1C3-0DE72EF39B3F}]
"Compatibility Flags= "=3Ddword: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, ren= ame 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
    onreadystatechang= e=3D"document.write('<I>Possibly</I> Vulnerable...');"= ;
    onerror=3D"document.write('You should be safe!= ');"
    classid=3D"clsid:{EC444CB6-3E7E-4865-B= 1C3-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

------=_Part_1173_32018819.1124329567242--