> 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 > [EMAIL PROTECTED] > 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 > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html