Bugs and flaws

[dana at vulscan.com (Dana Epp)]

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: sc-l-bounces at securecoding.org 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)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060203/6cfd986a/attachment.html