Thursday, July 13, 2006

bug will always be with us

I came across this google blog post after my last entry. It describes how a bug in a binary search program, in Programming Pearls, escaped detection for twenty years! Check this out:
"And now we know the binary search is bug-free, right? Well, we strongly suspect so, but we don't know. It is not sufficient merely to prove a program correct; you have to test it too. Moreover, to be really certain that a program is correct, you have to test it for all possible input values, but this is seldom feasible. With concurrent programs, it's even worse: You have to test for all internal states, which is, for all practical purposes, impossible."
This is exactly the reason why we have so many problems comprehensively scanning complex web applications. Where the descrete software components exist on many different servers. The state is always changing. The code is always changing. Everything is always changing.

"Careful design is great. Testing is great. Formal methods are great. Code reviews are great. Static analysis is great. But none of these things alone are sufficient to eliminate bugs: They will always be with us. A bug can exist for half a century despite our best efforts to exterminate it."

This is another reason why I've been a heavy proponent (as a practitioner and a vendor) for pen-testing websites like a hacker would. Because a hacker only needs to find that 1 bug to ruin your day, you have to test even more thoroughly and intensely. The focus must be to find all vulnerabilties all the time, its the only way to make a difference.


Albert said...

I've dealt with my fair share of headaches after finding my programs have missed a small bug described in the article. This is inevitable, but for programs like the binary search program, the boundaries should be known and enforced but I wouldve missed it also. It seems to me that *possibly* alot more bugs will be prevented by input enforcement.

Jeremiah Grossman said...

Right you are. A lot more bugs (or vulnerabilities) would be prevented using simple input enforcement. Inside that statement though was the message I was trying to get across. "A lot" is not "All". Bugs will always be with us, we're just trying to figure out new ways to limit their exisitence. And that also means we have to be prepared for an inevitable system failure.