Michael Howard here.
A core tenet of the SDL is to take and incorporate lessons learned when we issue a security update, and there is a great deal to learn from the recent animated cursor bug, MS07-017, so I want to spend a few minutes to go over some of the things we have learned from this bug.
First of all, this code is pretty old; is in Windows 2000, and predates the SDL. The SDL has parts (i.e., design review, threat modeling, testing, and security push) that focus on the product as a whole, and parts (i.e., code review and use of tools) that are focused on code. In the Windows Vista process, we banned certain APIs, like strcpy and strncpy, and changed well over 140,000 calls to use safer calls. memcpy wasn’t on that list. We also built in a lot of defense-in-depth measures because we know that the SDL can’t catch everything. Let’s start by looking at some of the defense-in-depth measures we have in place that didn’t stop the threat:
The bug is a stack-based buffer overrun in code that looks like this:
HICON LoadAniIcon() {
... ANIHEADER myANIheader;
memcpy(&myANIheader, untrustedData->headerdata, untrustedData->headerlength);
Because there are no candidate buffers on the function’s stack, there is no -GS cookie added to the stack, even though the code is compiled with -GS. This is not the first time we’ve seen code with no cookie, and this has made us rethink the heuristics used by the compiler when it determines whether to place a cookie on the stack or not. But, changing the compiler is a long-term task. In the short-term, we have a new compiler pragma that forces the compiler to be much more aggressive, and we will start using this pragma on new code.
The next issue is that the code is wrapped in an exception handler that catches code failures. This can usually be good for reliability, but it has an interesting security side-effect: Windows Vista includes address space layout randomization (ASLR), and the goal of ASLR is to reduce the likelihood that an attacker can determine the address of critical functions. This makes it harder to make exploits run correctly. But, if the vulnerable code is wrapped in an exception handler that catches many errors, a failed attempt will not crash the component and the attacker can try again with a different set of addresses. David LeBlanc mentions the dangers of exception handling in a recent blog post.
Note that by itself the ”catch everything” construct is not a security bug, but it can aid an attacker if the exception handler wraps vulnerable code.
Now, let’s look at analysis tools.
Interestingly, our static analysis tools do not flag this construct as a security bug because it’s a very low-priority warning, and is presently not an SDL “must-fix” warning. Compiling the following code with the C++ compiler in Visual Studio 2005 or the Windows Development Kit...
void Foo() {
__try {
}
__except( 1 ) {
...yields the warning:
1>c:\code\demo\demo.cpp(36) : warning C6320: Exception-filter expression is the constant EXCEPTION_EXECUTE_HANDLER. This might mask exceptions that were not intended to be handled
We’re investigating this issue further to determine ways of finding exception handlers that may wrap potentially vulnerable code.
The next question is: why did our static analysis tools not find this bug? Code that uses calls such as memcpy is hard to flag as vulnerable without generating a great many false positives. This is a research problem that no one has solved, here or elsewhere. Another angle is to replace calls to memcpy with memcpy_s which forces the developer to think about the destination buffer size. We may ban memcpy for new code, but we still need to analyze this further. Stay tuned.
Another interesting note is that this code is really hard to annotate with SAL because the function takes a PVOID buffer and the buffer length is buried inside a structure that is passed by reference! SAL can help find many bugs, however. Take the following code:
char Sample(div_t *i, size_t n) {
char c[32];
memcpy(c,(void*)i,n*sizeof div_t);
return c[0];
char y = Sample((div_t*)dwArray,21);
This would normally not be flagged as an error, but when you add SAL annotations:
char Sample(__in_ecount(n) div_t *i, size_t n)
The compiler generates the following warnings:
1>c:\code\demo\demo.cpp(55) : warning C6385: Invalid data: accessing 'argument 1', the readable size is '84' bytes, but '168' bytes might be read: Lines: 50, 55
1>c:\ code\demo\demo.cpp(55) : warning C6202: Buffer overrun for 'dwArray', which is possibly stack allocated, in call to 'Sample': length '168' exceeds buffer size '84'
Next: why did our fuzz tests not find the bug? The animated cursor code was fuzz-tested extensively per the SDL requirements. It turns out none of the .ANI fuzz templates had a second “anih” record. This is now addressed, and we are continually enhancing our fuzzing tools to make sure they add manipulations that duplicate arbitrary object elements better.
There is one silver lining: on Windows Vista, known malicious exploits that affected real customers were stopped dead because of UAC and Protected Mode IE; that is not to say exploits could not be written that are UAC/Protected Mode aware.
Our goals are to code well, catch bugs, and reduce the chance that new bugs enter the code. We have a set of features in place to catch things the process misses. We have a learning process and layers of defense in depth because we don’t expect perfect code -- ever.
In summary, SDL is not perfect, nor will it ever ever be perfect. We still have work to do, and this bug shows that. We have a new -GS pragma that adds more stack cookies; we’ve updated our fuzz tools; we will pay closer attention to exception handlers that could mask vulnerabilities, and we will investigate the impact of banning memcpy for new code. Finally, we will update our education as necessary with lessons learned from this bug.
-Michael
Greetings and welcome to the Microsoft Security Development Lifecycle Blog!
We on the Security Engineering team at Microsoft have been getting a lot of friendly pokes from customers, partners, colleagues, and competitors, asking us to say more about the Microsoft Security Development Lifecycle (SDL) in an open forum. While Michael Howard, Steve Lipner, and others have written and spoken about SDL in numerous publications and venues, we understand the desire to “take a peek under the hood,” so to speak. Thus, the “SDL Blog” was born – with apologies for the decidedly unimaginative nom-de-blog. What we’d like to do in this space is provide information about SDL and commentary on security and privacy processes as close to “real time” as possible. We hope to accomplish a number of things by blogging on the SDL:
- Inform: We want to provide factual information about the SDL - this includes explorations of both the “good” and the “bad.” To that end, we will try to avoid posting on the same types of subjects that Michael, Adam and MSRC talk about in their blogs – however you can expect there to be some degree of crossover from time to time.
- Inspire debate: Amongst ourselves and with you, dear reader. There are a number of issues around security, privacy, and various processes in which reasonable people will differ. That’s cool. Platform fan-boys/otaku need not post. We’ll keep it respectful if you will…
- Respond to the “security punditocracy:” It has been interesting for some of us to watch those at various points on the punditocracy food chain, commenting not only on what the Microsoft SDL “is,” but also commenting on its effectiveness. While some of the feedback is valid, these commentaries are usually followed by the obligatory pitch for one’s own proprietary process. For those of you old enough to remember - “…it’s a floor topping AND a dessert wax!” springs to mind (apologies to SNL for the deliberate misquote).
We seek to shine the light of day onto these commentaries and let reasonable people decide for themselves! To be clear, this is not a slagfest – we will amplify points about security and privacy processes made by others that are spot on; conversely, we will seek to debunk some popular misconceptions about Microsoft’s security efforts.
It’s important to note that some of us will likely post more frequently than others – security and privacy issues at Microsoft (and in the ecosystem) will wax and wane – we will comment accordingly. Rest assured, we will not sacrifice quality for frequency as it relates to posting info about the SDL.
Enough about why we’re here. Now would be a good time to introduce the contributors to this literary tour de force…
Eric Bidstrup is a Group Program Manager responsible for managing SDL policy at Microsoft. He has worked at Microsoft for more than 17 years as an engineer and in program management. He’s worked on a variety of products and technologies from the old Microsoft character mode applications (MS Word 4.0 anyone?) and Windows 3.0/3.1/95; he led the creation of Microsoft’s online “casual” games site MSN Gaming Zone , and worked in Microsoft Research on speech recognition and synthesis technologies. Eric also contributed to the development of MSN-TV2 , and has been working in security over the last few years.
Michael Howard is a Senior Security Program Manager in the Security Engineering group at Microsoft. He is an architect of the SDL and co-author of numerous security books including Writing Secure Code for Windows Vista, The Security Development Lifecycle, 19 Deadly Sins of Software Development and the award-winning Writing Secure Code.
Tina R. Knutson is a Senior Privacy Program Manager in Microsoft’s Corporate Privacy Group. Her main focus is developing rules, processes, and compliance tools for building privacy into products and services. She is a co-author of the company’s Privacy Guidelines for Developing Software Products and Services (2006), and a Certified International Privacy Professional (CIPP).
David Ladd has worked at Microsoft for 17 years in a variety of technical and management roles. He currently serves as a Senior Security Program Manager on the Security Engineering Strategy Team. Prior to this, David served as Group Program Manager in the MSR External Research Programs group, where he focused on the expansion of security research and education. David is the co-founder of the Trustworthy Computing Academic Advisory Board, a group created to expand the interactions among Microsoft and the academic security and privacy research communities. He serves on a number of external advisory boards and committees, is an associate editor of IEEE Security and Privacy magazine, and is a member of ACM, IEEE, and USENIX. As Michael Howard and James Whittaker delight in pointing out, Dave is the author of no books.
Steve Lipner is Senior Director of Security Engineering Strategy in Trustworthy Computing at Microsoft. He is responsible for the definition and updating of the Security Development Lifecycle. Steve is also responsible for Microsoft’s policies and strategies for the security evaluation of its products, and for the development of other programs to provide improved product security to Microsoft customers. Steve has over 30 years’ experience as a researcher, development manager, and general manager in IT security. He is named as co-inventor on 11 patents in computer and network security. Steve is a co-author with Michael Howard of The Security Development Lifecycle.
Rob Roberts is a Program Manager in Microsoft’s Corporate Privacy Group. Rob’s roles include architect for privacy testing and tools, as well as privacy consultant to several Microsoft product groups. He is a co-author of Microsoft’s whitepaper on Privacy Guidelines for Developing Software Products and Services (2006).
Adam Shostack is a Program Manager in Microsoft’s Security Engineering group. Before working on the Security Development Lifecycle at Microsoft, Adam was involved in four startups on vulnerability scanning, privacy, patch management, and program analysis. He helped found the CVE, International Financial Cryptography association, the Privacy Enhancing Technologies workshop, and the Emergent Chaos blog.
James A. Whittaker who is now a Security Architect at Microsoft, spent his career in software testing and security. While a professor at Florida Tech, he created the largest academic software testing research center and made testing a degree track for undergraduates. Before he left Florida Tech, his research group had grown to over 60 faculty and students and had won over $12 million in research awards and contracts. He has several security-related patents for defense against viruses and worms, and is the creator of the highly acclaimed runtime fault injection tool Holodeck. Dr. Whittaker received his Ph.D. degree in computer science from the University of Tennessee in 1992 and is the author of How to Break Software, How to Break Software Security (with Hugh Thompson), How to Break Web Software (with Mike Andrews), and over 50 peer-reviewed papers on software development and computer security.
Dave Ladd
Sr. Security Program Manager