eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
After all the work Microsoft did leveraging the Security Development Lifecycle, why didn’t SDL catch the animated cursor vulnerability in Windows Vista?
According to Adrian Stone at the MSRC (Microsoft Security Response Center), that is a question that he’s still getting regularly—and it’s a good one. “Honestly, that is a fair question and one I asked myself during the investigation, as I was the program manager responsible for the case,” he wrote in a blog entry on April 26.
As it turns out, Microsoft’s SDL group—which tracks security issues and works on incorporating lessons learned into future development—has just begun a blog, and the first entry is on lessons learned from ANI. Those lessons are leading the company to consider, for example, eliminating at least one call from old (pre-SDL) code that escaped the first round of cuts. Also, it’s already replaced a buffer stack check and has updated its fuzzing tools.
According to Michael Howard, an architect of the SDL and a senior security program manager in the security engineering group at Microsoft, the company came away with the following lessons.
“SDL is not perfect, nor will it ever be perfect. We still have work to do, and this bug shows that,” he said.
The ANI code is “pretty old,” Howard added, predating the SDL itself. In developing Vista, 140,000 calls were changed to safer calls, and certain APIs were banned outright. Memcpy, a function that copies data between two memory locations, wasn’t on that initial list of banned calls, but it may well get tossed soon.
Howard said his team is investigating the impact on new code of banning the memory handling function.
“We will pay closer attention to exception handlers that could mask vulnerabilities, and we will investigate the impact of banning memcpy for new code,” he said.
In fact, memcpy is at the heart of why Microsoft’s static analysis tools didn’t find the .ANI bug. The problem with memcpy is that when it’s used in a call, it makes that code hard to flag as vulnerable without generating a heap of false positives.
Nobody has managed to solve that problem, either inside or outside of Microsoft. Howard said his group is pondering swapping in a variation of the call—memcpy_s—that requires the developer to insert the destination buffer size. Stay tuned, he said.
Even some defense-in-depth measures didn’t stop ANI—for example, /GS, a buffer security check. Microsoft has swapped out the -GS pragma, and, because of certain issues of the original -GS, the company is also rethinking the heuristics the compiler uses in handling -GS.
That won’t happen overnight though. “…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,” Howard said.
Microsoft is also mulling over what Howard called an “interesting security side effect” of code being wrapped in an exception handler that catches code failures. That’s “usually” good for security, he said, but Vista includes ASLR (address space layout randomization) with the goal of making it harder for an attacker to figure out addresses of critical functions and hence harder to get exploits running correctly.
“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,” he said.
“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.”
Microsoft has also found that the .ANI exploit is slipping by without getting noticed by its SAL (Standard Annotation Language), which usually finds “many bugs,” Howard said. It’s doing that by taking a PVOID buffer and hiding its length inside a piece of code that’s passed by reference.
If SAL could read the buffer length, he said, it would generate alerts about both readable size and a possible stack-based buffer overrun.
The company has also beefed up its fuzzers in response to the .ANI exploit. Fuzz tests didn’t initially find the .ANI code because none of them had ample “anih” records to do so.
“This is now addressed, and we are continually enhancing our fuzzing tools to make sure they add manipulations that duplicate arbitrary object elements better,” Howard said.
The .ANI bug hasn’t been all bad news. Howard points out that malicious exploits were “stopped dead” due to UAC and Protected Mode IE, although exploits could certainly be written that could sneak around those protective mechanisms.
But hopefully, Microsoft will respond quickly when those exploits are written.
“Our goals are to code well, catch bugs, and reduce the chance that new bugs enter the code,” Howard said. “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.”