More Integer Overflow stuff


I think I’ve said this a billion times, but I’ll say it again. No-one has done more research into integer overflow (and underflow, and truncation and signed-ness) issues than my good friend and co-author, David LeBlanc.


So here’s the great news – he’s updated his very cool (and fast) C++ SafeInt class and written some more words of wisdom.


Here ’tis…


 

Comments (2)

  1. When XP SP2 was first delayed, there were a LOT of complaints about the fact MS couldn’t keep their act together as it relates to their development cycle. It’s easy to assume the worst and complain when you have no idea what is really going on. Last week at CanSecWest it was brought forth that Microsoft delayed the release of SP2 by 6 weeks when they found some significant issues with integer overflows. I wonder if that was why Michael Howard wrote an article on the very thing in April 2003. Or why he continues to talk about it to this day. Apparently Microsoft found integer overflows in a lot of different places in the code, and they quickly realized that they weren’t looking for them the same way they looked for other things like buffer overflows. Microsoft decided that fixing the problems was more important than keeping the original product schedule, and thus let the shipping schedule slip another 6 weeks. Interesting quote from Window Snyder, the security strategist at Microsoft that was presenting this information: "We slipped 6 weeks just for this… but it was the right thing to do." Bravo. Damn straight it was the right thing to do. I was recently at Microsoft for a week doing interop testing with our kernelmode security drivers in their test lab in Building 20 when I came across a potential buffer overflow based on a static #define which was used incorrectly. This was from code over 3 years old now, and really should have been caught by now. Unfortunately static code analysis tools like prefast can’t catch this sort of thing, and our human heuristic tests or automated code analysis tools were not designed to look for this type of problem. When I found this I stopped all further work until we rescanned all code for this type of error, and not the error itself. Doing so found one other instance where we did something similar. The result? A newly added code scan test to check for such things to prevent it from occuring again in the future. I was pleased to hear Microsoft taking the same attitude. It INDEED was the RIGHT THING TO DO. Good job….