"Buffer Overflow" rant in Risks Digest

[dws]

I'm no fan of lawyers or litigation, but it's high time that someone defined "buffer overflow" as being equal to "gross criminal negligence".

Thus begins a rant by Henry Baker in the latest Risks Digest. He repeats some standard complaints about software engineering, but he also provides a historic perspective that many screeds lack.

Baker's rant is worth reading, even if Perl is safe from the problem he describes. There are security problems beyond buffer overflows that we're often guilty of. Skim the rest of the issue while you're there. There are several good reminders that security is an end-to-end issue, but humans in between.

[Chrisf]

Good article, it addresses what is probably going to become a very large issue in the near future. From the article...

Software crashes due to mere incompetence apparently don't raise any eyebrows, because no one wants to fault the incompetent programmer (and his incompetent boss). So we have to conjure up "bad guys" as "boogie men" in (hopefully) far-distant lands who "hack our systems", rather than noticing that in pointing one finger at the hacker, we still have three fingers pointed at ourselves.

He hit it dead on here, you can see examples of companies blaming their products faults on "hackers" everyday, and of course they are rarely called on it by the media.

There would obviously be strong opposition from many large software companies against any sort of legislation (it could put microsoft out of business pretty fast ;-) but something really does need to be done about this. The difficult part of this issue is deciding how far to go with legal penalties for negligent companies. I'm interested to hear what everyone here feels constitutes negligence.

There was another good article over at security focus a little while ago as well.

[Cybercosis]

The only problem with accusing programmers of negligence in their work because their software can be exploited is determining at which point "due diligence" ends and "criminal negligence" begins. It is not inconcievable that someone could write a program that, at the time of writing, has no known security holes, but is vulnerable to some technique not yet developed. Is the programmer to be blamed for not being clairvoyant?

~Cybercosis

nemo accipere quod non merere

[Anonymous Monk]

I don't think anything in the article referenced mentioned anything about _unknown_ security holes. The topic was security problems that have been in existence for quite some time and have well known fixes (the example problem: buffer overflow, fix: bounds checking, existence: since before many of todays programmers were even born).

Why would a buffer overflow problem "not" be considered negligence? While some of the jokes about what would happen if car manufacturers followed the design and implementation practices of some large software corporation have some humor in them, they generally fail to state the rather unfunny truth that a good number of both users and non-users of such vehicles would be dead.

Does the software you write contain the standard liability disclaimers? Are you not willing to take full _responsibility_ and _liability_ for your software working according to spec and not failing in the face of *known* bugs and security issues? Are you prepared to pay damages if your software fails due to a problem widely known in the industry? If not, why not and why is it so acceptable for software to be a 'use at your own risk' product? Why is the software profession not really a profession at all? Why is there no infrastructure for the 'software profession'? No bar exam? No licence? Have you looked into malpractice insurance for the 'software profession'? Doctors, lawyers, engineers, etc. have licences to practice, and insurance, and risk losing them in the course of performing their practice.

Bearing the cost of liability is not competitive if everyone isn't doing it, and everyone won't be doing it unless a regulative body is in place to define and manage the currently non-existent so-called software 'profession'. And none of that will ever get started unless at the very least the serious and widely known problems like buffer-overflow bugs in software become recognized as the gross negligences that they are and punishable with damages. Once potentially costly damages are in play, large software houses see a benefit in being able to hire licenced programmers if only there were some and the ball starts rolling. I would welcome that day both as a developer and as a consumer.

[converter]

Would a manufacturer of automobiles, for instance, be willing to warrant his products against catastrophic failure if he were forced to build his product using materials from sources who refused to make similar guarantees, because the materials from which they manufactured their products offered no guarantees?

No. He'd be insane.

When you write software, you can't guarantee much unless you can be certain that the software used to create it and the software upon which it depends come with the same assurances.

What about liability? ISVs have been playing the blame game for years. They get away with it because their denials are plausible. I doubt this will ever change.

[tilly]

This is not a question of being able to predict the future. It is a question of not making the most common, stupid mistake imaginable. For every year since they started keeping track, the most common cause of security holes announced on CERT has been the buffer overflow. This is true despite the fact that there have been programming environments for decades which stop this bug cold.

At what point do you stop saying, "That is life." and start saying, "That is negligence?"

[ariels]

"...Perl is safe from the problem he describes..."

Perl (the language) is safe from buffer overflows, yes. But perl (the implementation) is written in C. It is not impossible for there to be a buffer overflow in your perl executable. And it is not impossible for a Perl program to accept inputs which would expose this overflow.

I'd say Perl programs are safe. As long as you don't try running them.

[mpeppler]

Indeed. And of course you have tons of XS code (in C, usually) that could very well have an unchecked strcpy or two (guilty of that myself, in one spot, now fixed)...

Michael