| |||||||||||||
FUD is not needed hereFUD is not needed herePosted Mar 14, 2007 20:20 UTC (Wed) by ajross (subscriber, #4563)In reply to: FUD is not needed here by mheily Parent article: A second remote hole for OpenBSD
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.
(Log in to post comments)
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?
|
|||||||||||||