Message-ID: <40EE3CB0.2010707@science.org>
Date: Thu, 08 Jul 2004 20:35:28 -1000
From: Jason Coombs <jasonc@...ence.org>
To: Drew Copley <dcopley@...e.com>
Cc: security-bugtraq@...ketshark.net, bugtraq@...urityfocus.com,
	thor@...x.com
Subject: Re: Can we prevent IE exploits a priori?


Drew Copley wrote:
 > I have not seen evidence that either of these applications
 > prevents new exploits. If anyone is making this claim, they
 > should explain what technology they are using.
 >
 > The required fix is simply setting a kill bit on the vulnerable
 > activex objects.

In response to security-bugtraq@...ketshark.net
 >>I don't mean to flame you
 >>Thor, as your client list is certainly impressive:
 >>(http://pivx.com/clients.html) I just can't seem to get your
 >>program from anywhere.
 >>
 >>So I wanted to know, has anyone tried these programs
 >>successfully?  Can anyone validate their claims?  Better yet,
 >>does anyone have a link to a "how to" doc, that tells smart
 >>geeks how to make the registry changes ourselves, so we don't
 >>have to rely on some program to do it for us?

Aloha, Drew and MarketShark.net.

To answer your last question first, I wrote an article recently for Dr. 
Dobb's that you may find helpful as you figure out how to harden the IE 
My Computer/Local Machine zone yourself.

Dr. Dobb’s Windows Security, June 18, 2004

IE’s Local Machine Zone and the Attack of the TLAs
http://www.ddj.com/documents/s=9207/ddj040618sec/

As Thor Larholm pointed out to Drew Copley on July 3rd, the kill bit is 
good but preventing all scripting of controls in the My Computer Zone is 
better. This is the sort of security hardening for IE that Qwik Fix 
provides. See http://www.qwik-fix.net

Thor Larholm wrote:
 >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.

Qwik Fix does set the kill bit on bad controls, and will set the kill 
bit on controls that are not bad but are a risk, but only when there is 
not a better technical solution available than setting kill bits.

There can be little argument that setting the kill bit on each control 
that poses a threat when IE's zones are not properly hardened is to 
attempt to hit a moving target.

Drew Copley wrote:
> The easy to use, free fix for all of these issues:
> http://www.eeye.com/html/research/alerts/AL20040610.html

It is not free if a paid employee of the company has to spend time doing 
it. Although the eeye registry fixer tool may be useful to some, the 
fact that registry hacks like the ones that eeye recommends often have 
to be backed out temporarily to do something that has been blocked by 
the new setting, and then re-implemented after that action is complete, 
makes it necessary to have a trusted software agent that does these 
security hardening and temporary unhardening steps for us automatically 
at runtime.

The user knows when they are browsing the Web and when they aren't -- 
therefore the user gets to decide when the protection should be present 
and when it should not be. This is a security context decision that a 
simple registry hack cannot make at runtime, and that in the end we have 
to be able to rely on the end user to understand. More importantly, we 
need the end user to be capable of exerting specific information 
security skill and knowledge with the click of a mouse in a consistent 
and manageable fashion.

My experience has been that end users do understand the difference 
between browsing the Web and printing a file to their printer, for 
example, and there are instances where security registry hacks will 
disable printing or some other mundane, low-risk activity. That the end 
user must take action to unharden a box long enough to print is an 
unfortunate reality of poor security design in printer manufacturer's 
user interfaces, and we all just have to live with and adapt our boxes 
around these realities.

> If you mess up you will make it very difficult for users to
> browse the web and they will manually change the settings and
> likely end up getting spyware running automatically on their
> systems -- or worse.

Again the reference to "you" as distinct from the "users" themselves 
makes it clear that you are thinking of the problem only from one 
perspective. End users will always manually change settings when not 
given an easy way to bypass barriers to getting things done. Spyware 
will do it for them without their knowledge. The "you" in the real world 
is often the end user themself, reinstallation of a Windows 
hotfix/service pack, and so forth. When "you" does refer to a system or 
network administrator, they know very well that even when they don't 
mess up, things still go wrong and settings get changed.

A software agent like Qwik Fix that knows how to harden and unharden or 
reharden a Windows box solves the "if you mess up" problem, no matter 
who, or what, "you" it is that is responsible for messing it up (again).

There are hundreds of thousands of Qwik Fix users to date, and the 
response to the software from other infosec peers has been very 
positive. After Scob there was an outpouring of gratitude expressed from 
people who realized that the software protected them in advance.

This is pretty convincing proof that the product protects against new 
exploits by solving root problems that allow them to occur. I personally 
was impressed enough to join the company. (note sig below)

Sincerely,

Jason Coombs
jasonc@...ence.org

Director of Forensic Services
PivX Solutions, Inc.
http://www.pivx.com

Powered by blists - more mailing lists