Bugtraq mailing list archives

Re: Can we prevent IE exploits a priori?


From: Jason Coombs <jasonc () science org>
Date: Thu, 08 Jul 2004 20:35:28 -1000

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 () marketshark 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 () science org

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


Current thread: