FUD is not needed here [LWN.net]

FUD is not needed here

Posted Mar 14, 2007 19:32 UTC (Wed) by mheily (guest, #27123)
In reply to: A second remote hole for OpenBSD by ajross
Parent article: A second remote hole for OpenBSD

Why are you trying to spread FUD about the OpenBSD developers? Do you have any evidence to back up your "psychological analysis" of them?

OpenBSD takes security very seriously. The OpenBSD project released a patch within 48 hours of being notified of a remotely exploitable vulnerability. When the issue was first reported as a denial of service, they released a patch six days later. That's a pretty good response time, IMHO.

The reason this was initially treated as a denial-of-service problem is that the buffer overflow did not directly involve user-supplied data. It is non-trivial to exploit this kind of problem, and kudos should be given to Core for figuring out a way.

Any piece of complex software cannot be proven correct; it can only be proven to be *incorrect* in certain corner cases.

(Log in to post comments)

FUD is not needed here

Posted Mar 14, 2007 20:20 UTC (Wed) by ajross (subscriber, #4563) [Link]

Do you have any evidence to back up your "psychological analysis" of them?

As explained: they apparently tried to "cover up" a serious security issue as a denial of service. I suggested that the reason might be because they were afraid of having to increment their "Only N holes" counter. That seems like a reasonable line or argument to me. There is some factual evidence (click on the link above), that I combined with other facts (the "Only N holes" marketing slogan) to suggest a hypothesis (the "psychological analysis"). Now, you may not agree with me, and I may be wrong, but I think this is well above the level of "FUD".

I'll be honest, I think the "Only N holes" slogan is a dumb idea. At best, it has the effect of fooling the users (or fan base) into thinking it means more than it really does. At worst, it actively encourages the developers to "cook the books" in an attempt to avoid incrementing N.

And please don't pretend that a kernel overflow bug is ever a minor issue that can be fixed with a silent (non-security) bugfix. It's a huge deal, and sweeping it under the rug as a DoS until someone can prove you incorrect is just wrong. This should have been disclosed as a potential security issue instantly.

Ignorance is not an excuse for spreading FUD

Posted Mar 15, 2007 3:12 UTC (Thu) by mheily (guest, #27123) [Link]

There is nothing in the advisory that supports your claim that there was some kind of attempted "cover up" to "cook the books" so that the OpenBSD project wouldn't have to increment a number in their marketing slogan. In fact, the opposite occurred; the problem was handled quickly and professionally, with full disclosure and communication between the project developers and the security researchers, and patches were released as new information about the severity of the problem was discovered. What more do you want?

There are plenty of ways to cause a kernel panic that don't lead to privilege escalation or remote code execution. If every bug that causes a kernel panic is treated as a critical security vulnerability, we would all drown in a sea of false positives and be constantly patching and rebooting our servers for no good reason.

At most, there was a linguistic disagreement on using the word 'vulnerability' to describe a denial-of-service issue. The OpenBSD project uses the term 'reliability fix' to describe patches for denial-of-service issues. They only use the term 'security vulnerability' when there is a possibility of remote code execution. Both types of problems are taken seriously, and patches for both types of problems are backported from the CVS repository to the stable releases.

Your insinuation that they tried to issue a silent fix for the problem is totally wrong.

Your claim that by advertising a low number of remote holes they are "fooling the users" about the overall system security is false. The OpenBSD website states in bright red letters:

"The packages and ports collection does NOT go through the same thorough security audit that is performed on the OpenBSD base system. Although we strive to keep the quality of the packages collection high, we just do not have enough human resources to ensure the same level of robustness and security."

It is clear that you are ignorant of the facts surrounding this incident, the nature of the OpenBSD project, and the general process of reporting and resolving security flaws. Please refrain from making baseless accusations that only serve to spread fear, uncertainty, and doubt about the OpenBSD developers.

Foo is not an excuse for Bar

Posted Mar 15, 2007 4:50 UTC (Thu) by k8to (subscriber, #15413) [Link]

Describing likely security problems as mere denial of service is a sort of downgrade. Some people do so further, downgrading such things to "bug fixes". Strictly speaking such terms are not incorrect, and such descriptions may be defensible (do you describe everything as the maximum *possible* damage it can do?) But this type of action is the "cover up" being described.

I think that was quite evident.

Ignorance is not an excuse for spreading FUD

Posted Mar 15, 2007 16:44 UTC (Thu) by bronson (subscriber, #4806) [Link]

I must disagree with you mheily. It's simply good security practice to treat an exploit as its worst potential outcome. This particular exploit had components that could be used to remote the box, yet the OpenBSD team chose to categorize it as nuisance. That's unfortunate, isn't it?

Reading the report starting with, 'OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote denial of service attack,' shows how reluctant the OpenBSD team was to categorize it properly, even after the exploit was demonstrated. Why were they so reluctant?

Don't get me wrong -- OpenBSD is fantastically secure and I often use it myself. But their response in this case was uncharacteristically sloppy. How many machines were rooted in the nine days it took to convince the OpenBSD team of this bug's severity?

FUD is not needed here

Posted Mar 15, 2007 9:19 UTC (Thu) by Wol (guest, #4433) [Link]

"Any piece of complex software cannot be proven correct" ...

Well, it's maths, so while maths can be proven correct, there is no guarantee that it mirrors reality - that's Science's domain.

What's that Knuth quote? "Beware of bugs, I have only proved this program correct, I have not proved that it works".

Don't get me on my database hobbyhorse :-) and remember that Maths proves things "correct in theory", Science proves things "wrong in practice". The latter is more important but people prefer to dwell on the former :-(

Cheers,
Wol