Availability is becoming the poor cousin in security
on June 4th, 2007 at 9:53 amThere have been a few discussions here and there over the last few months as to whether or not a software vulnerability that causes stability problems but does not allow remote code execution is actually a security flaw. There were some good arguments on it, and I think us old schoolers who think a DoS attack is still a security problem made our point. Then I see this post at the Watchfire blog, and I feel the old burn coming back.
Seems like Jonathan Afek over at Watchfire is going to be presenting at BlackHat (congrats). He gives a description of the presentation. Here is part of that description:
Just another day at the office started with scanning a web application with a vulnerability scanner (AppScan of course). The scan resulted in an unexpected crash in a Microsoft IIS server. This discovery was really exciting – a crash might mean a new IIS vulnerability.
A more thorough research concluded that we were facing a “dangling pointer bug” and that it might be remotely exploitable for arbitrary code execution. After a while, an already published advisory of this bug was found on the net. It stated that this was a DoS vulnerability and that it couldn’t be exploited for remote code execution.
We thought differently.
First of all, let me say that I don’t see Jonathan arguing that DoS is not a problem, and the advisory that he points to list the vulnerability as critical. And while I think the presentation is probably going to be very interesting and one I would love to see, it still gives the impression that if the remote code execution is not possible, then there’s not a big danger. When did availability become the poor cousin in security? The availability of a service is JUST as important as the integrity. Plain, simple, end of story.
Vet
Ory,
Thanks for the clarification.
Michael
Hi,
It seems that our post about the dangling pointer was a bit unclear – what we actually meant to say, is that originally Microsoft did not fix this DoS issue, because “it was just a DoS”, and what we have proven, is that it is a critical vulnerability after all, and that DoS (other than being a serious issue by itself), can be escalated to something even more serious (i.e. Code Execution).
We did not intend to downplay the importance of DoS.
Hope this clears things up,
-Ory Segal,
Watchfire.
Kurt,
I get your point. But couple them together, and you have a very sexy attack.
Michael
LV, I remember that discussion, and you were right about that case. ANd i think you are essentially agreeing with me here. but something you said struck me.
You said in this comment: “One reason I think availability is necessary for us is because of the extreme security: lock it all up so it is not usable at all, and it is secure! But availability is our own internal mechanism to fight against that extreme.”
I would argue that data is NOT secure when it is locked up and not available. I think this is a common misconception. From the layman’s point of view, maybe the data is secure (not calling you a layman
). But from our professional POV, availability is integral to the security of information or to a system. If it is information, maybe a company needs to have the ability to get to their data in order to do business. A competitor can utilize a flaw that allows no remote code execution but crashes all the victim’s web servers that hold the portal to the database. Not good. We are not called to just keep the data locked up and hidden. From a business perspective, we have to be able to allow the user to actually USE the data.
From a system POV, there could be secondary effects to a DoS attack. If there is a flaw in Debian Linux (don’t flame me, you Debian lovers out there
), and your IPS runs a flavor of Debian, then a DoS attack on your IPS might allow bad traffic to get through (just an example since the IPS should be transparent and should fail closed, though not all businesses can allow that).
Michael
while i do agree that availability is just as important, while reading your post my mind inadvertently added a word which helped me see the other side (amazing how framing things differently can make all the difference)…
specifically: ‘if the remote code execution is not possible, then there’s not _as_ big _a_ danger’
i can think of no way to negatively affect the availability of something without it being immediately obvious… confidentiality and integrity, on the other hand, can be damaged covertly and i can definitely see why a covert attack would be regarded differently than an overt attack…
add to that the ability for certain types of integrity loss to snowball, and the non-recoverability of a confidential data breach and i can definitely see the argument for attacks on availability being at the very least less interesting from a defender’s point of view…
I think this ends up being a lot of marketing and money-speak from vendors trying to downplay issues. “We don’t have security holes, they just cause a DoS condition or a panic/fault/vomit.” If someone can DoS my servers due to a preventable hole or condition caused by software, that affects the availability of my servers and their legitimate use of information on those servers. One reason I think availability is necessary for us is because of the extreme security: lock it all up so it is not usable at all, and it is secure! But availability is our own internal mechanism to fight against that extreme.
At least, that’s another way to put it. I don’t think DoS bugs are a universal security issue. I think you and I had that quick comment-discussion a few months back about a browser DoS on a server and I said it wasn’t a security issue. In that case, it can be argued and might not be as big a deal since it wasn’t a server thing. But a server DoS…
I could accept that most DoS effects are a security issue, but we certainly can’t do much about many of them. And I really wouldn’t want to find out 2 years later that a DoS really was exploitable and someone has been doing it…
I couldn’t agree more. The triad still has 3 legs.