Sunday, September 16, 2007

Buffer Overflows are like Hospital-Acquired Infections?

I was listening to NPR a few weeks ago and heard an interesting piece about new policies being implemented related to "Avoidable Errors."

The idea is that certain medical outcomes are always the results of medical negligence rather than inherent issues in medicine such as patient differences, etc. A few things that fall into the avoidable category are:
  • Common hospital-acquired infections
    • Urinary tract infections for example are extremely rare when proper protocols are followed.
  • Blatant surgical errors
    • Tools left in patient for example. There are easy ways to make 100% sure this doesn't happen.
What is most interesting I think is that historically there have been problems with these issues, but we now have good procedures for avoiding these in almost circumstances. There will be corner cases as the article points out, but these are by far the exception.

For historical context we didn't used to understand that we needed to sterilize needs and/or use them only once. Needles used to be expensive and so we reused them, but we discovered infection rates were unacceptably high. We created low-cost disposable needles and we use those now instead because they are safer.

Similarly we continue to program in languages that make avoiding things like buffer overflows tricky. Not impossible, but tricky. Given the attention to buffer overflows, the fact that we have tools to completely eliminate them from regular code, I'd say they fall into the same category as surgical tools left inside the patient - negligence.

A key quote from Lucien Leape of the Harvard School of Public Health:

Today, he says, dozens of safe practices have been developed to prevent such errors. But he says there hasn't been enough of a push for hospitals to put them into use.

"I think it's fair to say that progress in patient safety up to now has relied on altruism. It's been largely accomplished by good people trying to do the right thing," Leape says. "And what we're saying is that hasn't gotten us far enough, and now we'll go to what really moves things in our society, which is money."

Maybe I should start putting money-back guarantees in my contracts with software vendors so they owe me a partial refund for every buffer overflow that gets exploited/announced in their code?


Peter said...

Good post. I just found out that we have some web-facing code written in C and some written in Fortran 77. The first is horrible, the second is simply jumping the shark.

As far as I'm concerned, leaving C and Fortran (Fortran!?) code around on a webserver isn't leaving tools inside people--it's like stitching up the patient with the prep nurse inside.

Jonathan said...

It's an interesting perspective, but I think the analogy fails in at least one way. We have licensing boards that decide who is qualified to cut people open and even who can stab someone with a needle.

Unfortunately any unskilled worker can write an OSS app rife with buffer overflows, and even if it's a specifically commercial activity, there are no licensing boards for coders.

Security Retentive said...

Jonathan - I don't disagree that the standards for practitioners aren't different - merely that we shouldn't treat them differently from an outcome perspective.

If companies developing and selling software want to reduce buffer overflows, they need to figure out how best to do it.

We didn't used to regulate doctors either - medicine hasn't been an accredited degree/program for that long frankly.