From: jkuperus at planet.nl (Jelmer)
Subject: Comments on 5 IE vulnerabilities

> When I attended the NTBugtraq Retreat earlier this year, most of the
> attendees were surprised to hear that I am using Internet Explorer on a
> daily basis, particularly since I should know how vulnerable it can be
> at any given time. I surf with JavaScript and ActiveX enabled, see flash
> movies and play Java games, but despite this I am not vulnerable [0] to
> a single command execution vulnerability or system compromise through
> Internet Explorer.
>
> How, you might ask? Simple, I have locked down the My Computer security
> zone on my installations [1].
>
> Each and every command execution vulnerability in Internet Explorer over
> the last few years have all depended on the functionality of local
> security zones. Whenever you are crafting an exploit, you want to
> navigate a window object to a local security zone, inject some scripting
> or HTML into the window object and subsequently use the features of the
> local security zone to execute your payload. Properly locking down the
> My Computer zone prevents all of these from having any effect.

each and every ?

http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2003-07/0301.html

http://www.securitytracker.com/alerts/2003/Jun/1007072.html

etc.. etc.. etc..

please tell me what registryhacks you applied to stop those ;)
What you are suggesting only stops one very specific class of exploits

- It doesn't prevent buffer / heap / integer overflow attacks

- It doesn't stop stealing of session data, which *IS* a big deal in a world
where more and more applications are getting to be webbased.

- It doesn't protect you against broken certificate handling

Posts like this give people a false sense of security, just run our magical
little program and click your heels twice and all the issues will just fade
a way. Thats not the way it works. At best it adds a layer of security

> However, changing the Internet Explorer security zone settings is not a
> nimble task. Despite being partly split after IE4, the functionality of
> Windows Explorer and Internet Explorer is still very tightly interwoven.
> If you are not careful you WILL cause your system to malfunction and no
> longer open Explorer folders, launch applications or even boot into
> Windows properly. You need to strike a very sensible balance.
>
> During the course of our research, we crafted and tested solutions to
> this problem on tens of thousands of installations and have beta tested
> on thousands of users, and have incorporated the results into our FREE
> constantly updated Proactive Threat Mitigation application that goes by
> the name of Qwik-Fix(r) ( www.pivx.com/qwikfix/ ). Our beta users were
> never affected by Blaster, HTAExploit or MiMail - to name a few.

Seems valueble would you concider writing a whitepaper / howto on the
subject ?


>
> Now, let's analyze the vulnerabilities Liu Die Yu posted on November
> 25th [2], as there was not much details in the post.
>
> "1stCleanRc" is not a vulnerability of its own, but an example exploit
> detailing how to combine the "MhtRedirParsesLocalFile",
> "BackToFramedJpu" and "MhtRedirLaunchInetExe" vulnerabilities. The same
> goes for "execdror6" which is an example exploit that relies on the
> "LocalZoneInCache" vulnerability, as well as "LocalZoneInCache" which is
> a demonstration of using "threadid10008".
>
> This leaves us with 5 vulnerabilities to analyze:
>
> MhtRedirParsesLocalFile is designed to display and parse a locally
> residing file of any plaintext format in an IFRAME. On most of our
> installations we could only reproduce the display part. Still, being
> able to display a locally residing file in a window object is
> specifically prohibited by IE6 SP1.

I wouldn't classify this one as a vulnerability, it's just a variation o
what mindwarper reported
he reported that setting the moved temprarily header with an Location forces
parsing of the local file

now there are a couple of ways to force a redirect, your what mindwarper
used, your plain vanilla http redirect,  and pointing to a non existant mht
file.
Enumerating all possibilities does not constitute a new vulnerability each
and everytime, its like saying, woohoo
<object type="text/html" data="redirect.asp"></object> also works  :-o ,
well duh offcourse it does, but it remains the same iussue


> MhtRedirLaunchInetExe expands a bit on the capabilities of the codeBase
> vulnerability. Microsoft fixed codeBase in the Internet Zone, but left
> it in the My Computer zone. As such, MhtRedirLaunchInetExe simply makes
> it one step easier to bundle HTML, Script and executable payload in the
> same file.
>
> BackToFramedJpu lets you inject javascript URLs into the history and
> have them executed in the context of the target window object.
>

> HijackClickV2 lets you hijack clicks and target them at some system
> dialogs. You will have to know the location of those.
>
> Threadid10008 is intended to download an HTML file to the TIF and
> subsequently display and parse it. It could not be reproduced on all our
> systems, but it does help leverage entry into a local security zones on
> the installations it worked on.
>
> Locking down the My Computer security zone prevents all of the 3
> exploits by mitigating the effects of the remaining vulnerabilities
> substantially, while still allowing a usable surfing experience.
> As a final comment, I do believe that vulnerability researchers should
> notify vendors of potential vulnerabilities and give them some time to
> fix these before exposing the public to the dangers of those
> vulnerabilities. Posting demonstratory proof-of-concept code has served
> to apply pressure in the past towards unresponsive vendors, but not
> giving the vendors any chance to respond at all in the first place is
> simply irresponsible and jeopardizes the security of the Internet as a
> whole.
>
>
> References:
>
> [0] Qwik-Fix(r)
> http://www.pivx.com/qwikfix/
>
> [1]
> Description of Internet Explorer Security Zones Registry Entries
> http://tinyurl.com/ubfq
>
> [2] Post by Liu Die Yu
> http://tinyurl.com/x8qx
>
>
>
> Regards
>
> Thor Larholm
> Senior Security Researcher
> PivX Solutions
> 24 Corporate Plaza #180
> Newport Beach, CA 92660
> http://www.pivx.com
> thor@...x.com
> 949-231-8496
>
> PivX defines "Proactive Threat Mitigation". Get a FREE Beta Version of
> Qwik-Fix <http://www.qwik-fix.net>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

Powered by blists - more mailing lists