I used to read the source code before deploying applications on servers that might be accessible to "other people". I'd download maybe a half dozen programs before I found one that did what I wanted and didn't have a security hole that I could find in the first ten minutes of searching the source code.

I don't bother with programs that are too broken to easily repair. If I ever started fixing security bugs on every interesting program Freshmeat, I'd never stop--there's more bugs coming into there every day than I could possibly fix, and many of the worst offenders are simple programs that have many competitors, so they're easier to replace outright or even to rewrite than to repair.

Someone commented that finding bugs in closed-source programs through reverse-engineering isn't difficult, and they're absolutely correct.

Tracing and debugging tools these days are getting so good that I rarely bother to use the source code to find a vulnerability, even when I do have access to it. Why bother trying to analyze a program's control flow from source code when it displays obviously insecure behavior seconds after you start to run the binary?

Confirming a security hole early in the evaluation cycle saves a lot of time, because if I can confirm the existence of a security vulnerability, I can simply drop the program in question and move on to the next one. Of course, if a bug doesn't show up in the first few seconds, or if the program doesn't have viable alternatives, then I still have code reading to do, but at least reading the source code isn't a waste of time in that case.

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/articles/19/1400#1400