Every bug is an opportunity to learn, and the security update that fixed the data binding bug that affected Internet Explorer users is no exception.
The Common Vulnerabilities and Exposures (CVE) entry for this bug is CVE-2008-4844.
Before I get started, I want to explain the goals of the SDL and the security work here at Microsoft. The SDL is designed as a multi-layered process to help systemically reduce security vulnerabilities; if one component of the SDL process fails to prevent or catch a bug, then some other component should prevent or catch the bug. The SDL also mandates the use of security defenses whose impact will be reflected in the "mitigations" section of a security bulletin, because we know that no software development process will catch all security bugs. As we have said many times, the goal of the SDL is to "Reduce vulnerabilities, and reduce the severity of what's missed."
In this post, I want to focus on the SDL-required code analysis, code review, fuzzing and compiler and operating system defenses and how they fared.
The bug was an invalid pointer dereference in MSHTML.DLL when the code handles data binding. It's important to point out that there is no heap corruption and there is no heap-based buffer overrun!
When data binding is used, IE creates an object which contains an array of data binding objects. In the code in question, when a data binding object is released, the array length is not correctly updated leading to a function call into freed memory.
The vulnerable code looks a little like this (by the way, the real array name is _aryPXfer, but I figured ArrayOfObjectsFromIE is a little more descriptive for people not in the Internet Explorer team.)
int MaxIdx = ArrayOfObjectsFromIE.Size()-1; for (int i=0; i <= MaxIdx; i++) { if (!ArrayOfObjectsFromIE[i]) continue; ArrayOfObjectsFromIE[i]->TransferFromSource(); ... }
int MaxIdx = ArrayOfObjectsFromIE.Size()-1;
for (int i=0; i <= MaxIdx; i++) {
if (!ArrayOfObjectsFromIE[i])
continue;
ArrayOfObjectsFromIE[i]->TransferFromSource();
...
}
Here's how the vulnerability manifests itself: if there are two data transfers with the same identifier (so MaxIdx is 2), and the first transfer updates the length of the ArrayOfObjectsFromIE array when its work was done and releases its data binding object, the loop count would still be whatever MaxIdx was at the start of the loop, 2.
This is a time-of-check-time-of-use (TOCTOU) bug that led to code calling into a freed memory block. The Common Weakness Enumeration (CWE) classification for this vulnerability is CWE-367.
The fix was to check the maximum iteration count on each loop iteration rather than once before the loop starts; this is the correct fix for a TOCTOU bug - move the check as close as possible to the action because, in this case, the array size might change.
Memory-related TOCTOU bugs are hard to find through code review; we teach TOCTOU issues, and we teach memory corruption issues, and issues with using freed memory blocks; but we do not teach memory-related TOCTOU issues. We will update our training to address this.
Our static analysis tools don't find this because the tools would need to understand the re-entrant nature of the code.
In theory, fuzz testing could find this bug, but today there is no fuzz test case for this code. Triggering the bug would require a fuzzing tool that builds data streams with multiple data binding constructs with the same identifier. Random (or dumb) fuzzing payloads of this data type would probably not trigger the bug, however.
There is a plethora of defenses available on various versions of Windows, but only a couple came into play owing to the nature of the code.
As mandated by the SDL, the code is compiled with -GS to detect some forms of stack-based buffer overruns at runtime, but it's moot because this is not a stack-based buffer overrun.
Even though Windows Vista and Windows Server 2008 have both ASLR and NX enabled by default, Internet Explorer 7 does not opt-in to these defenses owing to compatibility issues with many common applications. Internet Explorer 8 enables these defenses by default, but an attack could be mounted by calling a component that does not use these defenses, and then by using an attack technique known as heap-spraying get the attacker's code into the non-ASLR and non-NX memory. This is why it's so important to build components for Windows that use all the available Windows defenses. Matt Thomlinson and I wrote an article on this subject, and David LeBlanc and I wrote Writing Secure Code for Windows Vista that covers the subject in much more detail.
IE7 and IE8 both use the SDL-required process termination if the heap is corrupted (you can read more about this here.) But there is technically no heap corruption, so the defense does not come into play in this instance.
On Windows Vista and Windows Server 2008, this is a major defense that comes into play against the currently circulating exploits. When the exploit code runs, it's running at low integrity because IE runs at low integrity, and this means the exploit code cannot write to higher integrity portions of the operating system, which is just about everywhere!
For our server platforms, Windows Server 2003 and Windows Server 2008, Internet Explorer Enhanced Security Configuration also prevents the exploit from working because the vulnerable code is disabled.
We really don't know how the bug was found, but some of the security people in Internet Explorer and the Trustworthy Computing Security teams suggest that the bug was either "stumbled upon" or found through directed fuzzing. The finder could spend as long as he or she wanted to find this one bug. This is one of the things that makes security hard - security is a highly asymmetric problem: software developers must get the code right 100% of the time in a very short amount of time, while attackers can spend as long as they want to find one bug. This isn't an excuse; it's a fact of life
I think this bug is a great example of "you will never get the code 100% right, so multiple defenses are critical." As you can see from this post, many defenses in Windows did not come into play, but all it takes is one defense to help stop or reduce the chance that an exploit will succeed, and in the case of Windows Vista and Windows Server 2008, Internet Explorer's Protected Mode was that defense.
If there is one other lesson from this, it's that we, the software industry, need to work harder to make sure applications take advantage of the defenses offered in Windows today.
Big thanks to Chengyun Chu, Jonathan Ness, Adam Shostack, Bronwen Matthews, Mike Reavey and Steve Lipner for their valuable edits and input to this post.
Hi, Todd Kutzke here… I’m the Sr. Director of Microsoft’s Information Security team whose mission is to enable secure and reliable business for Microsoft and its customers. Our team resides inside of Microsoft IT (MSIT) and is focused on managing information security risk around our operational practices and tools that are used to support Microsoft business. Over the past 6+ years, one such area that we’ve been heavily involved in is the security of line-of-business applications through our Assessment, Consulting & Engineering (ACE) team, a team that is an integral part of Information Security. This work has taken the form of processes we’ve developed (derived from SDL with a focus on LOB) as well as specific tools to help in the development and maintenance of a secure enterprise application portfolio.
As various forms of data become more readily available through online applications, managing the security of these applications is becoming more critical. And, as something that has been discussed on this blog and in other forums, security has to be considered throughout the entire lifecycle of the application as just another attribute of the application alongside scalability, usability, performance, accessibility and others. This is very much the goal of SDL and to help with the adoption of the process, we’re very committed to providing tools to our customers to help with the adoption of SDL, and ultimately, a more secure application portfolio.
Today, we’re very excited to announce the availability of our next version of the Anti-Cross Site Scripting Library (Anti-XSS) v3 BETA as well as Code Analysis Tool .NET (CAT.NET) v1 CTP. Anti-XSS v3 BETA includes performance improvements, localization enhancement as well as a Security Runtime Engine (SRE) that uses an HTTP module to provide a level of protection against XSS for your application without the need to rebuild your code. CAT.NET v1 CTP is a binary analysis tool that can be used by developers to identify some common vulnerabilities that can lead to attack vectors such as XSS, SQL Injection and XPath Injection in your code.
These tools are examples of technologies we’ve develop and are using internally as a part of our larger SDL initiative in helping to build and maintain secure code and we’re excited to share these tools with our customers. We’re definitely looking at releasing more tools from our portfolio and are very much looking forward to your feedback.
Adam Shostack here. While at Tech Ed Developer in Barcelona, Michael Howard and I did three video segments. The first is on the announcements that we made and Dave Ladd blogged about. The second is a 25 minute detailed walkthrough of the new SDL Threat Modeling Tool, and the last is our top 10 security pet peeves.
Why not check them out, or have a look at all the content that TechEd Online makes available?
Hi everyone, Bryan here. The debut BlueHat SDL Sessions are over, and they were a resounding success: 96% of attendees completing evaluation surveys reported that they will be able to apply knowledge that they learned in the SDL sessions to make their products more secure. This is a great score and I’d like to thank all of our speakers and the BlueHat planning team for their hard work. As for the other 4% of attendees, we’ll just have to work that much harder next year to bring them actionable guidance for dealing with new vulnerabilities.
As promised, we recorded all of the day’s presentations and we’ve published them on TechNet:
Keynote Address by Scott Charney, Corporate VP, Microsoft Trustworthy Computing
Threat Modeling at EMC and Microsoft by Danny Dhillon of EMC and Adam Shostack of the Microsoft SDL team (of course)
Mitigations Unplugged by Matt Miller, Microsoft Security Science team
Concurrency Attacks on Web Applications by Scott Stender and Alex Vidergar of iSEC Partners
Fuzzed Enough? When it’s OK to Put the Shears Down by Jason Shirk, Dave Weinstein and Lars Opstad, Microsoft Security Science team
Real World Code Review – Using the Right Tools in the Right Place at the Right Time by Vinnie Liu of Stach & Liu
In addition to the presentations, we also recorded some short interviews (about 10 minutes long) with each of the speakers. If you’re just looking for a quick summary of a particular talk, these interviews are the place to start:
Threat Modeling at EMC, Danny Dhillon
Threat Modeling at Microsoft, Adam Shostack
Mitigations Unplugged, Matt Miller
Concurrency Attacks on Web Applications, Scott Stender and Alex Vidergar
Fuzzed Enough? Jason Shirk and Dave Weinstein
Real World Code Review, Vinnie Liu
I hope at least 96% of online readers will be able to directly apply this material to their products, just like the show attendees. Please post back and let us know, either way. And let us know what you’d like to see for next year. We have big plans to build on our success and make SDL Sessions 2.0 even bigger and better than the first.