Code Scanners and Security
Tim already posted about the Debian SSL flaw so I’ll let you read his take on it, but I wanted to bring some more information to the table.
Slashdot (of all places) has an excellent description of why the code was originally changed. The maintainer/developer had run valgrind on the code, and changed the code without thinking about it. It’s unclear who’s to blame here, we only have who checked in the code, not necessarily who changed it. However, this bug is a prime example of using “security” tools without knowing what you’re doing.
Valgrind looks for memory leaks and undefined memory usage. It’s not purely a security tool, but sometimes it’s used as one. Purify and flawfinder are others that I’ve seen used. These tools can show you how memory is used (or misused) in source code. Its these memory misuses that typically cause buffer overflows, so while it’s desirable to remove all “bad” code, it’s also desirable to understand why the code is bad or good.
Security folks aren’t always developers, and developers are almost never security folks. Get the two together to interpret the results of code scanners, it’ll make it a lot easier for you in the long run.
May 21st, 2008 at 1:30 pm
Just thought I’d share the email I just received from Verisign: