Microsoft: Human error caused critical SMB2 vulnerability

Microsoft is blaming human error for one of the critical SMB v2 vulnerabilities that exposed Windows users to remote code execution attacks and argues that it's near impossible to catch these types of bugs with existing code review tools and techniques.

According to a post-mortem of the issue by Redmond security guru Michael Howard (right), the company detected the vulnerable code "very late" in the Windows 7 development process but argued that there are no static analysis tools or SDL requirements that would spot this type of human error.

"Right now there is no static analysis tool I know of that would point out the developer used the wrong variable, and our analysis tools didn’t spot the potential array bounds problem in part because it’s hard to do so with generate a very large quantity of false positives," Howard said.

"There is only one current SDL requirement or recommendation that could potentially find this, and that is fuzz testing. In fact we did find it very late in the Windows 7 development process through network fuzzing and that is why post-RC versions of Windows 7 do not have this bug," he added.

Howard did not explain why the fix was not back-ported to Windows Vista and other vulnerable versions until it was independently discovered and released by external security researchers.

[ SEE: Microsoft security guru: Get fuzzing ]

He said the only other technique that could find this type of vulnerability -- an incorrect variable in an array reference -- is the process of "very slow and painstaking code review."

This code was peer-reviewed prior to check-in into Windows Vista; but the bug was missed. Humans are fallible, after all.

Howard said the types of vulnerabilities surfacing in Windows OS code today shows that the mandatory SDL has "whittled away most of the ‘low-hanging’ bugs."

Of course, I might be proven wrong, but looking at all the bugs over the last year in Windows, the only pattern I can spot is there is no pattern! The majority of the bugs I see in Windows are one-off bugs that can’t be found easily through static analysis or education, which leaves only manual code review, and for some bug classes, fuzz testing. But fuzz testing is hardly perfect, because the malformed data might not hit the vulnerable code path or trigger a failure in the code.

He called on software developers to spend more time on defenses against unknown vulnerabilities, as well as trying to prevent or remove vulnerabilities.

See: MS09-050, SMBv2 and the SDL, by Michael Howard.