Thanks for the very detailed and informative explanation. However, I still think it sounds like IE has too large of an attack surface :) It still seems to be the case that IE can be persuaded to execute any of a large amount of code based on its raw (web) input, with (fairly) arbitrary parameters, and this large attack surface allows attackers to find vulnerabilities in any of the code that IE calls out to.
Crispin Dana Epp wrote: > I think I would word that differently. The design defect was when > Microsoft decided to allow meta data to call GDI functions. > > Around 1990 when this was introduced the threat profile was entirely > different; the operating system could trust the metadata. Well, > actually I would argue that they couldn't, but no one knew any better > yet. At the time SetAbortProc() was an important function to allow for > print cancellation in the co-operative multitasking environment that > was Windows 3.0. > > To be clear, IE was NOT DIRECTLY vulnerable to the WMF attack vector > everyone likes to use as a test case for this discussion. IE actually > refuses to process any type of metadata that supported META_ESCAPE > records (which SetAbortProc relies on). Hence why its not possible to > exploit the vulnerability by simply calling a WMF image via HTML. So > how is IE vulnerable then? It's not actually. The attack vector uses > IE as a conduit to actually call out to secondary library code that > will process it. In the case of the exploits that hit the Net, > attackers used an IFRAME hack to call out to the shell to process it. > The shell would look up the handler for WMF, which was the Windows > Picture Viewer that did the processing in shimgvw.dll. When the dll > processed the WMF, it would convert it to a printable EMF format, and > bam... we ran into problems. > > With the design defect being the fact metadata can call arbitrary GDI > code, the implementation flaw is the fact applications like IE rely so > heavily on calling out to secondary libraries that just can't be > trusted. Even if IE has had a strong code review, it is extremely > probable that most of the secondary library code has not had the same > audit scrutiny. This is a weakness to all applications, not just IE. > When you call out to untrusted code that you don't control, you put > the application at risk. No different than any other operating system. > Only problem is Windows is riddled with these potential holes because > its sharing so much of the same codebase. And in the past the teams > rarely talk to each other to figure this out. > > Code reuse is one thing, but some of the components in Windows are > carry over from 15 years ago, and will continue to put us at risk due > to the implementation flaws that haven't yet been found. But with such > a huge master sources to begin with, its not something that will be > fixed over night. > > --- > Regards, > Dana Epp [Microsoft Security MVP] > Blog: http://silverstr.ufies.org/blog/ > > ------------------------------------------------------------------------ > *From:* [EMAIL PROTECTED] on behalf of Crispin Cowan > *Sent:* Fri 2/3/2006 12:12 PM > *To:* Gary McGraw > *Cc:* Kenneth R. van Wyk; Secure Coding Mailing List > *Subject:* Re: [SC-L] Bugs and flaws > > Gary McGraw wrote: > > To cycle this all back around to the original posting, lets talk about > > the WMF flaw in particular. Do we believe that the best way for > > Microsoft to find similar design problems is to do code review? Or > > should they use a higher level approach? > > > > Were they correct in saying (officially) that flaws such as WMF are hard > > to anticipate? > > > I have heard some very insightful security researchers from Microsoft > pushing an abstract notion of "attack surface", which is the amount of > code/data/API/whatever that is exposed to the attacker. To design for > security, among other things, reduce your attack surface. > > The WMF design defect seems to be that IE has too large of an attack > surface. There are way too many ways for unauthenticated remote web > servers to induce the client to run way too much code with parameters > provided by the attacker. The implementation flaw is that the WMF API in > particular is vulnerable to malicious content. > > None of which strikes me as surprising, but maybe that's just me :) > > Crispin > -- > Crispin Cowan, Ph.D. > http://crispincowan.com/~crispin/ <http://crispincowan.com/%7Ecrispin/> > Director of Software Engineering, Novell http://novell.com > Olympic Games: The Bi-Annual Festival of Corruption > > > _______________________________________________ > Secure Coding mailing list (SC-L) > SC-L@securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Olympic Games: The Bi-Annual Festival of Corruption _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
