RE: [SC-L] Bugs and flaws

Dana Epp Fri, 03 Feb 2006 15:53:41 -0800

Title: Re: [SC-L] Bugs and flaws

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/
Director of Software Engineering, Novell http://novell.com
        Olympic Games: The Bi-Annual Festival of Corruption

_______________________________________________
Secure Coding mailing list (SC-L)
[email protected]
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

_______________________________________________
Secure Coding mailing list (SC-L)
[email protected]
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

RE: [SC-L] Bugs and flaws

Reply via email to