There are only a few days left before Black Hat USA, and we, like most other speakers, are in the midst of the last-minute push to have all the materials finalized in time for our presentation. Our presentation this year, “The Language of Trust,” features a lot of material related to attacking software interoperability layers, and focuses on Web browsers as case studies. Some of the vulnerabilities we will be disclosing affect Microsoft software and have resulted in Microsoft releasing an out-of-band update on July 28th. The updates included in this release are the result of a lengthy and largely successful collaboration between us and Microsoft, particularly individuals from MSRC including Steve Adegbite, David Midturi, and Dustin Childs. Microsoft has had the unenviable task of dealing with the issues surrounding the fixes for these problems, and they have worked diligently to do so in a timely manner. We decided to put together a blog post discussing the problems that needed to be contended with to get this update out in time, and plug our upcoming Black Hat presentation.
The update addresses some issues we uncovered in the Microsoft Active Template Library (ATL). Released in 1997, the ATL is actually distributed as source code with Visual Studio and is aimed at simplifying various programming tasks for developers. It provides, among other things, helper functionality that is utilized by most ActiveX components, which is where the vulnerabilities we are disclosing reside. Anyone who has utilized the relevant ATL code in their ActiveX controls for the past twelve years may have inadvertently incorporated these vulnerabilities into their own products. Microsoft has been getting a considerable amount of criticism for the amount of time it took to patch the Video Control vulnerability; however, the issue is much larger than it first appears and this fact, along with why detection is so difficult, will be discussed further in our presentation.
There are a few unique problems that needed to be dealt with for the ATL bugs. The first problem is efficient enumeration of vulnerable applications. When you contrast issues within the ATL against issues within application code, a number of differences become apparent. Generally, problems within application code are localized to a single source file, and require the recompilation of a single program. However, with issues in the ATL, any application that includes code from the ATL may be vulnerable. Furthermore, successful detection of vulnerable ATL code usage is a complex and error-prone process, and is difficult to achieve with standard static analysis tools. The reasons why detection is difficult will become clearer after our presentation, when we discuss the details of the bug.
The second issue that needed to be addressed was that of vendor coordination. As previously stated, other vendors that use ATL code in their ActiveX controls are potentially vulnerable. As such, Microsoft charged themselves with the arduous task of tracking down as many potentially vulnerable vendors as possible, and coordinating with each of them. Coordination involved explaining a bit about the potential problems, how to determine if a given control is vulnerable, and mitigation steps that can be taken to fix identified problem controls. This is a process that obviously takes time and effort, and Microsoft has been working around the clock with a number of vendors trying to minimize the risk to end users.
So, the mitigation work is done, the update is out and the presentation is going ahead on schedule! We would like to use the rest of this blog to shamelessly promote the presentation, which is quite broader than bypassing kill bits, and give a little insight into some of the issues we will be discussing. Primarily, our presentation intends to address three issues:
1. Interoperability layers in software do a lot of complicated work behind the scenes, and provide a vast and largely unexplored attack surface.
2. Throughout the course of our research, we discovered that unique bug classes exist due to the specialized tasks that marshalling code must perform. We intend to unveil these bug classes during the presentation. We will show how various data structures and APIs utilized for marshalling in the two dominant browser architectures lend themselves to misuse, creating the potential for subtle vulnerabilities that attackers may target. We will give practical examples for code constructs we have identified as vulnerable.
3. When two disparate components are given direct communication channels to each other, trust is implicitly extended between the two components. This trust relationship can be useful to attackers wishing to bypass various security features present in one component, by abusing features of another.
We are hoping this information will be useful for developers and security professionals alike, and look forward to seeing you all there! Our Black Hat presentation is slated for Wednesday, July 29th, at 3:15pm PDT, in the Augustus Ballroom 5-6.
-Ryan Smith, Mark Dowd, David Dewey