Message-ID: <8B32EDC90D8F4E4AB40918883281874D8B5BD7@mail.pivx.com>
From: thor at pivx.com (Thor Larholm)
Subject: RE: Registry Fix For Variant of Scob

Setting the kill bit on the "Shell.Application" ActiveX object, or any
other ActiveX, is a system wide configuration change. This is also the
reason for the incompatibility issues you are mentioning, but there is
no reason to kill the bird to secure the nest.

The problem here is not the ADODB.Stream or Shell.Application objects,
the problem is the insecure My Computer zone in Internet Explorer. Your
registry fix will have adverse functionality regressions on any Windows
administrator that use WSH when there is no reason for this. ActiveX
objects are used in many hosts of which IE is just one, others include
Jscript, VBScript, HTML Applications and WSH, all of which run outside
of the browser and require executional privileges to launch in the first
place.

The prerequisite for even having privileges enough to launch the
Shell.Application ActiveX object inside IE is to have script running in
the My Computer zone. Locking down this zone will completely prevent
this exploit, without introduing functionality regressions in other
parts of Windows. In fact, if you had implemented the registry changes I
described back in early September 2003 you would have been safe against
all the command execution vulnerabilities that have subsequently been
discovered - including ADODB.Stream and Shell.Application who are
themselves just minor components of a larger exploit prerequisite.

http://www.securityfocus.com/archive/1/346174/2003-11-30/2003-12-06/0

I am sure that tomorrow, next week and next month we will find even more
ways to exploit insecure zone privileges in IE. You can either try to
fix the root cause once or you can try to treat each new symptom as it
is discovered.

There is no need to hurridly introduce last-minute system wide
functionality regressions such as killbitting Shell.Application, all you
need to do is lock down the My Computer zone in IE properly. We
implemented this in Qwik-Fix last September and have since then not had
to worry about exploits that target these design principles in IE.
Instead, we have been able to focus our efforts on securing other parts
of Windows as opposed to scramble to cope up with each new exploit from
jelmer or http-equiv. You can get a free copy of Qwik-Fix Pro at

http://qwik-fix.net

All software is inherently insecure, the difference is in how you treat
that insecurity. 


Regards

Thor Larholm
Senior Security Researcher
PivX Solutions
24 Corporate Plaza #180
Newport Beach, CA 92660
http://www.pivx.com
thor@...x.com
Stock symbol: (PIVX)
Phone: +1 (949) 231-8496
PGP: 0x5A276569
6BB1 B77F CB62 0D3D 5A82 C65D E1A4 157C 5A27 6569

PivX defines a new genre in Desktop Security: Proactive Threat
Mitigation. 
<http://www.pivx.com/qwikfix>
-----Original Message-----
From: Drew Copley [mailto:dcopley@...e.com] 
Sent: Friday, July 02, 2004 2:33 PM
To: Windows NTBugtraq Mailing List; bugtraq@...urityfocus.com
Subject: Registry Fix For Variant of Scob


About the same time Jelmer found the adodb bug, http-equiv found a
similiar issue with the object "Shell.Application".

This issue has also been unfixed for the past ten months.

Unfortunately, Microsoft has not taken the "hint" and not
fixed this issue either.

Jelmer has noted this and made a proof of concept exploit
page here: http://62.131.86.111/security/idiots/malware2k/installer.htm


The below registry file will protect you from this exploit
by kill biting "Shell.Application" variant.

<------------------------------------------->
Windows Registry Editor Version 5.00 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\{13709620-C279-11CE-A49E-444553540000}]
"Compatibility Flags"=dword:00000400
<-------------------------------------------->

I will be updating our free fix download here:
http://www.eeye.com/html/research/alerts/AL20040610.html

This will break some hta scripts that might be used
for management. It may cause some incompatibility issues
with some programs.

Shell.Application is commonly used by administrators
for administration of systems via Visual basic script
or WSH. It may have other uses. It is kind of Microsoft's answer to
shell script -- though not as happy as batch.

Powered by blists - more mailing lists