Sometimes it’s the little things. According to Microsoft, one of the bugs in the Active Template Library was the result of a typo.
An ampersand, to be exact.
“The extra ‘&’ character in the vulnerable code causes the code to write potentially untrusted data, of size cbSize, to the address of the pointer to the array, pbArray, rather than write the data into the array, and the pointer is on the stack,” wrote Michael Howard, a principal security program manager in Microsoft’s security engineering and communications group, in a post on the company’s Security Development Lifecycle (SDL) blog. “This is a stack-based buffer overrun vulnerability.”
The mistake is the core issue involving the MSVidCtl ActiveX control, which was created by Microsoft using a private, internal version of the Active Template Library (ATL). The company patched vulnerabilities in ATL yesterday as part of an out-of-band emergency fix.
The flaw has been linked to attacks launched by hackers. So how did this slip through the cracks?
“I contend that this would be very difficult to spot in a code review, and is not picked up by the C/C++ compiler owing to the (void*) cast,” Howard wrote. “If the cast is removed, the compiler issues a warning like this:
C2664: ” : cannot convert parameter 1 from ‘BYTE **’ to ‘BYTE *’
“I despise C-style casting because it’s utterly unsafe; C++ casting is safer, although the reinterpret_cast operator is almost as bad as C-style casting.
“In the SDL we require that teams fuzz their controls, but our fuzzing tools didn’t find this because the method in question requires a specially formed input stream that includes many sentinel bytes,” he continued. “I explain the weaknesses of fuzzing here. We are in the process of adding more heuristics to our fuzzing engine so it can include these COM-specific bytes if needed.”
Howard goes on to discuss a second bug involving the use of ATL property maps to instantiate a COM object. He admits that their SDL has no requirements or recommendations for using ATL property maps, and that, at least in theory, fuzzing should have uncovered the problem.
Without disputing the actual level of difficulty involved in catching the mistake, the situation clearly underscores the importance of code review. After all, it is the little things that make the difference between being vulnerable and being secure.