|Programmer slip-up produces critical bug, Microsoft admits|
| 6:49 pm on Oct 16, 2009 (gmt 0)|
Programmer slip-up produces critical bug, Microsoft admits [computerworld.com]
October 16, 2009
|Microsoft acknowledged Thursday that one of the critical network vulnerabilities it patched earlier in the week was due to a programming error on its part. |
The flaw, one of 34 patched Tuesday in a massive security update, was in the code for SMB 2 (Server Message Block 2), a Microsoft-made network file- and print-sharing protocol that ships with Windows Vista, Windows 7 and Windows Server 2008....
...As he did in July when he admitted an extra "&" character in a Microsoft code library created a widespread vulnerability in most company software -- and software crafted by third-party developers such as Sun, Cisco and Adobe -- Howard argued that the SMB 2 mistake was virtually impossible to catch without a line-by-line review.
Interesting article that touches on human fallibility and the difficulties of detecting code errors through standard testing procedures.
WebmasterWorld thread on installation of the Oct 2009 security patches here...
Microsoft plans monster Patch Tuesday next week
| 10:34 am on Oct 17, 2009 (gmt 0)|
This is worrying, and perhaps tells us a great deal
|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. With that said, weíre looking deeper into the latter challenge now. |
Debuggers (and test code/data) can and should be used to routinely check for errors of this sort. Also, all code needs to be able to handle errors in input data in a defined way. Unless or until code has been tested with bad data as well as good, it cannot be considered finished.
This just about says it all...
|But fuzz testing is hardly perfect, because the malformed data might not hit the vulnerable code path... |
If you are not sure whether a branch is entered or not, you set a break point in that branch. If a branch is never entered using the available test data, you must either create new test data or modify the code temporarily so that it enters the branch anyway and observe what happens (using a debugger if necessary). This is elementary, any student programmer that's more than a few weeks into their course should understand this, yet, the Microsoft exec in charge doesn't seem to.