I would actually question people's opinions on the "seriousness" of DoS vulnerabilities. The common, and perhaps correct, mentality is, in the security community, "oh no, it brings down a server/service, whatever will we do!". A lot of people thing it's not that big of deal because you restart the service or press the reset button on the computer. That's true, when you look at a DoS on it's own. What if we combine it with the rest of an attack. There are a couple of scenarios where a DoS either makes an attack worse (remote code execution) or initializes a large threat (planned attack). Let's take a look at an example of each.

A new 0-day remote code execution vuln is floating around for a server you have... you can't take it down but there's currently no way to protect against it, so as an alternative you've setup a "secure IDS" in front of it to email you if the attack is detected. What you don't know is that the operating system running the "secure IDS" is vulnerable to a DoS that causes it's network stack to fail. The attacker, while doing some quiet fingerprinting notices all of this, so they DoS the "secure IDS" first and then run the remote code execution. Being that the network stack dropped the IDS can no longer communicate with you that it saw the remote code execution and the attacker is now inside your network. You didn't get your advanced warning because of a DoS.

What about a "planned attack"

Let's say you have a tech savvy insider who is disgruntled. Due to a poor network setup (we all know how common those are), a server that his entire department accesses daily (and on weekends) is on the same subnet as his desktop. The server authenticates against the domain. What does this tech savvy user do? He DoS's the server offline late on a Friday (knowing that it's a busy weekend and people will be working from home, but corporate helpdesk will be unavailable). He then changes his IP to the IP of the server and loads a webpage. The initial page is a replica of the actual page, logging to his hard drive and upon "login" the user sees a page that says due to maintenance the server will be down all weekend. He's now picked up a number of AD credentials simply because he had a DoS available to him...

We tend to think of DoS as exactly that... a method of denying service, which is something that can be easily resolved but a lot of people fail to think of DoS in a larger scope. They fail to see it as a stepping stone to a more advanced attack.

OpenBSD no longer considers remote denial of service "issues" vulnerabilities anymore.

that's not true, they're just not considered related to security. the bugs are still fixed, patches are still produced for them, and they are still listed on the errata page as "reliability" problems.

However, just because DoS vulnerabilities are not as dangerous as their remote control counterparts, it does not mean that they are not important.

no one said they aren't important, they just aren't classified as a "security" problem.

One thing that everyone seems to be skipping over here is that the OpenBSD team calls a denial of service a reliability issue because it does not effect the security of a system, while it does call any kind of compromise a security issue, since it does effect the security of the system.

Remotely crashing a machine, while a total pain to everyone, is not a security issue. Noone is getting into my mailserver after it's kernel paniced, hell it'll just reboot and be down for a minute. Until it was shown to be anything but a crash, the developers treated it as such, they fixed the problem and moved on.

I agree with them in their stance of making a real difference between a security issue and a stability issue, sure, we want both, and they are related, but there is a difference.

While they treated this as a simple denial of service, they have in the past treated things that looked to be exploitable, but noone had made an attempt at exploiting, as security issues, rather than reliability ones.

They just happened to be wrong about this one with their initial appraisal, not such a big deal, since they've probably done the same thing in reverse once or twice with their security updates, some of them may not have actually allowed for exploitation, but they felt it was likely, fixed it and moved on.

I agree with you here. While DoS is sloughed off as a non-issue by many people, they can be very damaging. In fact, talk to many business people and they might say they prefer a remote exploit that they may or may not have to disclose and no one else will know as opposed to a very visible DoS attack that leaves their services offline for X amount of time. That hurts. Just like your example of spyware. What is worse to most people, spyware that sits on their computer and pops up some ads or spyware that sits on their computer and blocks all email?

I think people moving DoS into a different category as opposed to a real vulnerability are just playing marketing and semantics. People discovering these want them vulnerabilities and the people they are against want them as benign as possible...

So, the basic premise is that dos isn't a security issue, its a reliability issue.

So, they've decided that the CIA triad is just plain wrong, is just the CI and A isn't in the loop?

A reliability issue is one that impacts availability but is under the control of the owner of the asset and shouldn't be remotely triggerable.

A security issue related to availability is one that can be deliberately caused.

Whether I root your box, cause it to leak information, or make in unavailable to you, I've caused a security problem.

It is a shame that given all of the good that the OpenBSD team has done that they've come up with their own definition of security. Alas, more forms in the definition tree.

Who wants to write the Wikipedia article redefining security on the OpenBSD world?

I disagree with OpenBSD (and by proxy Anonymous and James above). I understand why they want they want to make the distinction between the two, both from a technical level and the external perception from their community. As I mentioned in the post above, I also agree that they should make the distinction between the two. Calling something a general security problem does absolutely nothing for anybody.

I was going to write a long comment about why I believe this, but Andy's comment above sums it up better than I ever could. Whether I root your box, cause it to leak information, or make in unavailable to you, I've caused a security problem. In the end, it may be a reliability issue, but it is also a security issue as well.

I am sorry Ryan but I completely disagree with you and Andrew, a lack of availability is not a compromise of security. It's a lockdown, causing the alarm to go off and alert the authorities to the attempt.

A DoS does not allow any access to the machine from the hypothetical bad guys, there is no loss.

Some of the mechanisms in OpenBSD actually invoke crashes rather than allow for corruption of memory, these crashes are an act of security, rather than a breach of it.

This wasnt released via matasano. It was released via bugtraq by core. Wow this industry is full idiots. Do you just read the itsecurity.com top 59 list and consider yourself an expert? please go away now

Seriously James?

Sure, I understand that a system deliberately shutting itself off if it can't write an audit trail isn't a reliability mechanism, it is a feature. Even if the attacker can trigger it remotely by filling the logs it is still designed behavior.

Behavior that isn't intended, that results in the machine being made unavailable is a security issue.

It is the inflection of harm on the system owner. Whether it is in the same exact category as a root compromise is a different question.

Trying to call it a reliability issue and not a security issue is dodging the fact, and really a silly semantics game with the goal of perpetuating the "no remote exploit" mantra.

This wasnt released via matasano. It was released via bugtraq by core. Wow this industry is full idiots. Do you just read the itsecurity.com top 59 list and consider yourself an expert? please go away now

I wouldn't normally respond to such blatant trolling, but I felt that I had to just in case others were confused.

I know that the advisory wasn't released via Matasano. I was referencing them because that is where I first learned of the humourous discussions between CORE and the OpenBSD team and I was acknowledging them for pointing me there and talking about it first.

Cheers...

How about DoS as a social-engineering vehicle?

Say that I can reliably deny a user service to application X. Unless the vulnerability is fixed, that user will very likely switch to -- perhaps a less secure -- application Y.

An attack of this nature -- in theory -- would be amplified with OpenBSD, as it's widely regarded as being one of the most secure OSs around. Would would application Y be in this case? Certainly something that is less secure by default.