When Did Denial Of Service Attacks Stop Being Vulnerabilities?

Dave G. | March 17th, 2007 | Filed Under: Disclosure, Industry Punditry

Over at the nCicle VERT blog. Ryan Poppa asks: “Are Denial Of Service Vulnerabilities Important?”. Eventually, after a bit of rambling, concludes that they remain important. But, inside one of the comments, someone James Holt argues:

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.

Is this a commonly held belief? Because, it sounds pretty crazy to me. First of all, most definitions of security are based on Confidentiality, Integrity and Availability.

The ability to halt or shutdown most modern operating systems usually requires credentials (you must hava an account or be on console) and privilege (you must be in the wheel or admin group). If you can bypass authentication and authorization requirements and cause a machine to panic (let alone gracefully shutdown), then I think we have a security problem.

Furthermore, there are security implications for machines being shutdown. Ivan hints about it here:

We disagreed on that aspect and now, after the IPv6 mbuf bug report is done and gone, we continue to disagree. We consider a remote DoS a security issue not only because it has a direct effect on availability but also because a remote DoS can be aconvenient building block for a composite attack (for those lacking in creativity: think DNS).

[Excellent Conversation In The Comments —Dave G.]

Viewing 34 Comments

    • ^
    • v
    Remember the RNG talk from Black Hat last year: if you can predict the uptime of some systems (for instance, because you can SET the uptime by crashing the system), you can beat bad random number generators.
    • ^
    • v
    Tom, right on. This is another example where lack of agreement on even the most basic terms makes digital security a joke compared to older disciplines. If we can't agree on CIA as defining security, I think the situation is hopeless.
    • ^
    • v
    You mean, "Dave, right on." =)
    • ^
    • v
    That, "someone," is me, as in James Holt, the name is right there under my post. Noone has ever made these nonsensical maxims into fact, these are some random people's opinions, half the people who invoke these things are more interested in what is buzzworthy and hype-oriented. This is like the Orange Book, MACs or ACLs, they have nothing to do with security.

    The fact of the matter is that if something is actually randomly generated, you cannot predict it. Thomas, the bad random number generator you mention is not actually a random number generator, it's a patterned generator or an incremental generator, neither of which fall under the term random, as by definition random cannot be predicted at all. You cannot beat actual random number generators, that's how they work.

    Noone can agree to everything, and the belief that some maxim will suffice and become instant common sense is foolishness. This CIA and the atomic elements of information are just bollucks, utter tripe that I am suprised anyone follows, let alone many.

    Taken logically, a denial of service does not effect the integrity of the system, it only effects the temporary availability of the system. And while this is an inconvenience, on any competently made and maintained system it is only that.

    This has been what I grew up to believe, I have been in Unix management for only 15 years, but during those years all the people I've worked with agreed to this, noone has ever taken your terminology.

    Just ask yourself, "if the alarm goes off and all means of access to a bank are cut off, sealing the facility, has it been compromised?" I would say no, the bank is locked down, secure, nothing can get in to cause damage at that point. That is how risk mitigation works.

    When the castle gates are being attacked, block them off, I am pretty sure even a bloody yank knows this idea well enough.

    I realise there is an industry built up on finding security issues in software, but making up your own definition of security and then pretending that it's right, because everyone else who has a vested interest in everything seeming scarey agrees with you, is a gigantic fallacy.

    If the data remains intact, it's integrity assured, then it is secure.
    • ^
    • v
    This argument heavily depends on the type of DoS and the type of system being DoS'd. I say DoS and not attack because they are closely related topics and generally mutual, but they are different.

    If the origin were to use some malicious trick to cause the system to do something it wasn't designed to do, then it would fall more under the umbrella of security. For example, executing an evil payload on the remote system or bypassing access controls in some manner for horizontal or vertical access elevation or data access.

    However, if the origin were using the system as designed and simply over burdened it, then I think it would fall under stability and availability. For example, a data link congested to 100% due to too many connections to a web server or a firewall that is unable to deal with high session rampup times.

    Most enterprises plan for these separately. They have separate budgets and many departments and teams involved. Generally the security team is only a small fraction of people involved in the planning. (Security is probably the first called if something happens though) Most DR/BCP meetings I've been too have less to do with why something may happen as much as how to resolve it quickly. It's more about recovery time.

    (Just my .02$. I say generally and most in a lot of places and I'm sure most would disagree in general. That's fine.)
    • ^
    • v
    "Is this a commonly held belief?"

    I hope not. I thought things like threat models were meant to figure out whether availability mattered. And, I could picture sitting on a plane getting ready to land when over the PA system comes a message, "The air traffic control systems have gone down due to a DoS attack; however, this is not a security issue."

    "If we can’t agree on CIA as defining security, I think the situation is hopeless."

    I think we do agree. It is marketing that doesn't.
    • ^
    • v
    James, did you even bother to track down the Black Hat talk I referred to? It was one of the best of the show. I think you'll revisit your (weird) comment after you do. I don't know what your (weird) definition of a PRNG is, but all the PRNGs I know of need sources of entropy to seed themselves with; there are whole classes of devices, some of which could run the corrupted OpenBSD stack, which have a serious problem with cold-start entropy.

    This isn't just some nit I came up with to irritate you. It was, as I mentioned, a really excellent Black Hat talk, discussing a very real PRNG, but also a whole section of Practical Cryptography, which you apparently haven't read.

    I'm not sure what to say about someone who unilaterally decides to redefine security so that it no longer includes the "A" in CIA, but as someone who has done considerable work with large enterprises, and also led a team that built a product now deployed on the backbones of every tier-1 ISP in the world solely to combat DDoS attacks, I'm going to suggest that real-world security teams REALLY DO take that letter seriously.

    Thanks for playing, though.
    • ^
    • v
    nbates: I don't get this argument people make that just because DoS attacks are hard to stop, DoS really shouldn't be considered a "security" problem. Those people are just moving the goalposts.

    Theo's team has done all sorts of stuff to try to make DoS attacks, remote and local, harder --- and he clearly prioritizes them more highly than "random reliability" problems, which I say as someone who spent a week and a half debugging a UVM bug that Theo wouldn't touch because "Chuck Cranor's code was a mess and I don't want to think about it and you should just upgrade to three-dot-whatever and see if your problem goes away".
    • ^
    • v
    When management hires a security consultant, they would expect that consultant to address DoS along with other security issues. If a DoS attack occurs and said consultant calmly explains that it isn't a security issue, there will be a problem.

    I don't think the PR department would try to put that one out to the public. It just wouldn't work. Your company would be fodder for late night comedians.
    • ^
    • v
    I think that's true, Alice, but the subtext of the story is that the OpenBSD team would say, "Your client is wrong. DoS is a reliability issue."
    • ^
    • v
    In fairness to the people here who disagree with me, I should mention that Daniel J. Bernstein (a security hero of mine) did calmly exempt DoS attacks from the qmail security challenge. I disagree with that decision too.
    • ^
    • v
    Shortly after replying to Ryan's post, I had a conversation with him on the topic. Microsoft has started to exhibit a similar action to what OpenBSD did. If you look at the "Missing Microsoft Patches" on the ISC website that every DoS will be fixed in future service packs. Microsoft isn't considering them security risks anymore and therefore isn't associating them with MS Advisories. This was seen this Patch Tuesday when MS released a fix for a race condition in the XP SP2 Memory Manager that can cause a BSOD... That's a DoS. Yet Microsoft didn't warrant it important enough to label with an Advisory.

    I find the OpenBSD (and possibly Microsoft and Mr. Holt) mentality frightening and worrisome. I laid out two examples in my response to Ryan of where a DoS can be a real issue but there are hundreds more. To suddenly assume the aren't important and are not a security risk is a real problem.

    I still stand by a suggestion I made in a previous post of mine on the XP patch that we need some sort of IT Watchdog for vendors. Sure the concept is far fetched and next to impossible to implement but it's what we need. If we could pull off such an impracticality we could define vulnerability and impose fines for such companies that want to attempt to shrug off patches for vulnerabilities as "reliability fixes". It may be an impossible dream... but it's my impossible dream :).
    • ^
    • v
    Dude... If you will it, it is no dream, dude.
    • ^
    • v
    Andrew Donofrio said it best up there. There are systems where DOS attacks are a real problem. If availability is one of your top priorities then not having access to that system is certainly a vulnerability in your infrastructure. I consider DOS a security related issue in general, its up to the system admin to figure out whether its important to him or not, as with any advisory.
    • ^
    • v
    Tyler, that is not similar behaviour between OpenBSD and Microsoft, as OpenBSD releases the patches for reliability issues just as it does security ones. That would only be a similar definition of what security is and it's relation to reliability.

    Noone at OpenBSD has said a reliability issue is not important, and I sure as all hell don't think they're a non-issue. But if every bug ever was announced and they were all declared to be security fixes, you'd be patching constantly - your system would be down half the time from the reboots.

    The fact is the developers aren't looking to find a way to exploit every bug they find, they find the bug, they evaluate the bug and they fix the bug, then they move on to the next bug. If they really tried to exploit each bug, rather than just quickly evaluating it, they'd be wasting weeks per bug, maybe a group who's sole interest is in investigating bugs and trying to find if they are vulnerable to attack has that kind of time, since they're not developing an operating system, but the OpenBSD people aren't even doing this for a living, this is their hobby.
    • ^
    • v
    James,

    What they are doing is the same... Microsoft putting it in a service pack is essentially saying this is a "reliability fix"... Releasing the XP SP2 patch as not patching a vulnerability was releasing a reliability fix... Now there are reliability issues and there are security issues. Someone having the ability to compromise the availability of a system... that's a security issue...

    I'm not saying that every bug is a security issue nor should the developers go out of their way to find out the full effects of a bug. I'm saying that if they have a Denial of Service, as they did... that's a security issue... You'll be hard pressed to find someone in security, who understands security who disagrees with the standard CIA triangle... as has been pointd out many times already.

    The OpenBSD team f'd up... they really did... They need to admit, accept it, and stop trying to reclassify vulnerabilities just to keep their precious vuln count down. You'd think they'd be willing to do this... Microsoft may be a bit harder to convince.
    • ^
    • v
    I think it's important to note that crashing stuff is fun.

    Also, I can kill you with my brain.
    • ^
    • v
    Are you really arguing that fail-stop is less serious than Byzantine failure? Because a failure in integrity or confidentiality can very often be exploited to effect availability, I think it make perfect sense for confidentiality/integrity bugs to be rated as more severe.
    • ^
    • v
    You're changing the question. We're not arguing about relative severity. We're arguing about whether availability faults are properly classified as security vulnerabilities.
    • ^
    • v
    Thomas,
    If that is the case, a better question might be: will administrators who care deeply about availability ignore "reliability" fixes? If they consider availability to be security, then I would argue that they would automatically consider reliability fixes to be security fixes.

    Personally, I patch everything and so don't care whether the OpenBSD terminology is CISSP-compliant.

    Tyler,
    I don't think OpenBSD down-rates availability problems to keep our "precious vuln count down". Even if we did call every DoS a "security vulnerability" on our errata page, then the count that you are probably referring to (the usually-contentious one on the front page) would still not increment - it talks of "remote holes", which I would consider to be a far more constrained class than "security vulnerabilities".

    You are also making an unfair comparison between OpenBSD releasing reliability patches vs Microsoft's service packs. Hint: one happens as soon as we learn of a bug, the other occurs once every several years.
    • ^
    • v
    i've never understood how there could ever be any contention over the classification of (local or remote) kernel crashing bugs. there's one damn simple test already to decide it: check what the (equivalent of the) system shutdown syscall does, if it requires an authorized user, you have your answer. on multi-user systems i've ever seen, system shutdown was a privileged operation requiring the credentials equivalent of the unix root user. therefore if due to a bug someone else is able to do the same, he's effectively acquired root privileges for system shutdown purposes and that in everyone's book is a security bug (privilege elevation), no if's and but's.

    alternatively, if you still think it's not a security bug, then 1. remove any authorization checks in said system call(s), 2. provide a remote unauthenticated service for system shutdown, and post the IP address (start with cvs.openbsd.org for kicks) and we'll see how quickly it becomes a security problem ;).
    • ^
    • v
    Anyone who thinks DoS is not a security problem has obviously never tried working on any sort of hands on R&D project on a Linux platform under constant teardrop attacks back in 1996 (BTW, thanks for that one Mike :)). Or, how about a Windows machine under constant WinNuke attack in the same time period.

    More to the point, it's obvious that anyone who believes this (that availability should not be considered a mandatory and essential component of the security trinity) never existed within the security bubble (or maybe even the general computing population) at a time when kernel level DoS's were rebooting just about every box on the planet.

    As for this James Holt guy, Tom definitely said it best. I fully agree with his statement that all current RNG's require a source of "unpredictable" entropy to start the generation sequence. Hence the term PSEUDO RNG, and that's what all modern RNG's are, they just happen to be PRNG's with algorithms sufficiently complex enough to avoid predictability (generally, I think common attractor, and other distribution field anaylsis of most modern PRNGs shows that they're [mostly] doing their jobs). Until we have machines that can identify and plot location information for subatomic particles, there will be no such thing as a "true" RNG, unless you count the human brain.

    Maybe I'm being a bit naive here, but it seems to me the general problem here is the degree of extent to which the term "availability" implies. Persistent availability, and temporal [instantaneous] availability should probably be treated as independant concepts, but the CIA trinity doesn't really treat it that way. I would like to think that a crash to maintain confidentiality and integrity of certain information assets is not neccessarily a bad thing (provided that a persistent availability of the information asset is maintained), but it's not exactly an elegant solution to the problem either. The question becomes at that point:

    If there is a sufficiently high degree of certainty that integrity and confidentiality can be maintained, is it valuable enough to the security model to justify sacrificing temporary availability of preservable assets in order to maintain the confidentiality and integrity of those assets?

    I mean, how important does information asset availability become once the integrity or confidentiality of the asset is put in question. If an asset's desginated level of confidentiality OR integrity is compromised, isn't availability our enemy at that point?


    The preceeding is probably flawed logic, but I like playing the devil's advocate sometimes. There is one thing we can definitively say about all this though: When the availability of a service or machine is brought into question, we must digress and quote the good doctor by saying, "No good can come of this.".

    The 30,000ft. view:
    If no good can come of it, that means only bad things can come of it. If only bad results can be expected from an event's occurance that, subsequently, and very clearly, violates your designated security policy it has to be considered a security issue.

    Example:
    Joe writes an SQL server replacement called jSQL. jSQL works great, but has a bug that allows unauthenticated users communicating with the server to trigger an infinite loop condition in a loop which allocates memory. This causes a resource starvation/memory exhaustion attack, which invariablly leads to a breakdown in the availability of his DB server; and every 60-90 seconds he needs to reboot his server to resume functional operation of the database.

    Ask Joe if he thinks the fact that he needs to reboot every 60-90 seconds every time some undesirable delinquent with a packet generator triggers the condition, constitutes a security problem.

    Now picture the database software he's using not as a private in-house "jSQL" implementation, but a commercially acquired professional database solution; one which the acquiring party has absolutely no influence on code review OR quality assurance.

    The point at the end of the day is that "reliability fix" should be synonymous with "security fix" and vice versa. You're not accomplishing any heightened level of understanding, or removing any sense of convolution amongst the "partially" security aware populus by seperating and isolating reliability from security, because based on the CIA model reliability is a key component of security.
    • ^
    • v
    The position that opposes the idea that unauthenticated users being able to indefinitely hang, or prematurely and abnormally terminate processes/services, or the kernel itself, constitutes a clear cut and dry security issue is 100% indefensible.
    • ^
    • v
    Correction, fixes for reproducable user initiated reliability issues should be synonymously classified as security fixes. The threat model of the applying organization should then be consulted to determine the overall severity of that issue.

    I've always found it funny that so many shops like to pass the burden of threat analysis back to the vendor. They look to the vendor for severity classifications as though the vendor should have a better knowledge of their environment than they do.

    Just label them as security fixes and let the end-user decide its severity in their own environemnt. Or, as the vendor, develop your own vulnerability classification scheme to better explain to people the impact that a particular exposure has, if you want to bear the burden.

    If the user can't distinguish between "this allows people to arbitrarily control this device" and "this allows people to arbitrarily make this device unavailable" (and its importance to their use of said device), or can't be bothered; then its their own fault.
    • ^
    • v
    The availability of systems can be construed as both a reliability issue and a security issue. If you have a single server running a critical app and it suffers a hardware failure, that affects the availability of that critical app. The security team will likely call out that having just one server is a security issue which should be mitigated by having multiple servers for failover/balance. The reliability team will likely agree and they can gently push the job to each other to get accomplished. I would consider such a situation to be the realm of both teams.

    But what if someone or something can influence your machine and thus bring it down? A DoS condition is typically not just some random occurrence like the power going out or the hard drive breaking down. This is some outside entity influencing the availability of your service and/or product. An attack, if you will. If something else can bring down your server and adversely affect your company, I would definitely lean that much farther into the security field than the reliability field.

    Like I said in my original comment on the other site, creators calling these issues "non-security" issues are just playing semantics and marketing, nothing more. They're defining security in a way that is convenient to them so they can remain seen as secure...

    But I will say that Availability when it comes to security and DoS conditions are not always so obviously a security problem and can be easily mistaken and/or argued in different ways. Vendors take advantage of this.
    • ^
    • v
    Jon: I agree. It drives me fucking nuts when vendors say they're coordinating timelines and withholding details on fixes to help protect their customers; by and large, the people making those decisions have no idea what smart enterprises need to secure their own networks.

    I wrote about this a while ago:

    http://www.matasano.com/log/25/its-that-time-ag...
    • ^
    • v
    My biggest concern is that this is going to become a slippery slope. If Denial of Service attacks are no longer vulnerabilities, how long would it take for other types of vulnerabilities to be considered less severe or nothing at all?

    Well, take a look at what Michael Howard said on one of the MSDN blogs about the severity of Buffer Overflows in Vista

    http://blogs.msdn.com/michael_howard/archive/20...

    I'm starting to warm up to Tyler's suggestion of an IT Watchdog group. I'm a little concerned that everything has been a little too quiet on the worm front and that people are using that to justify the changing of how things are defined.
    • ^
    • v
    No one made a big stink about it but there was a DOS on Sun machines in Jan/Feb via ICMP packets. I blogged about it and this subject then as well ->
    http://em386.blogspot.com/2007/02/quiet-reporti...

    To SUN's credit, they labeled the impact as a security vulnerability and not a reliability issue.
    • ^
    • v
    Tell Pepperidge Farm the week before Christmas that a denial of service attack on their web site that keeps it down is not a security issue. How about telling American Airlines that a critical machine in their scheduling system being down on demand by an attacker isn't a security problem. This would be a loss of over a million dollars a day.

    In CVSS, confidentiality, integrity, and availability are modified by an impact bias to give weight to one of the classic security dimensions. I would agree that confidentiality or integrity should typically be biased higher when data matters but sometimes your threat model would trade this off for availability. I think an IDS or firewall would have a availability bias.

    -Chris
    • ^
    • v
    Andrew made the most relevant point. It depends on the system and that’s why things like threat modeling are useful. A DoS may not matter so much for me on my home PC, but it does matter for critical systems. Do you think it would matter for some soldier on the battlefield if the enemy could control when his radio goes does? Even if you don’t care about availability in your system, allowing an attacker to crash your system gives them one more thing to control in mounting other attacks. An analogy to this would be allowing an attacker to find collations in the hash function you are using. It may or may not create a vulnerability for any given system or protocol, but if you are not going to go through the effort of modeling how the ability to calculate collations will effect the security of your protocol (AND assuming you are smarter than your attacker), it’s much smarter to use hash functions that are not vulnerable.

    Another thing is that crashing the system or service is the first thing an attack gets when finding code execution type vulnerabilities. When a vendor publishes an DoS advisory we are assuming that they did their due diligence and have determined that its *only* a DoS and nothing else can be done. I don’t think this is necessarily always the case.

    Security folks tend to be (and in my opinion should be) conservative, glass half full type of people.
    • ^
    • v
    I agree with the whole idea that it depends on the nature of the DoS vulnerability and how the system in question is being used. OS vendors have no idea how their software is going to be used. So how conservative or aggressive should they be?
    • ^
    • v
    Um...

    "Just ask yourself, “if the alarm goes off and all means of access to a bank are cut off, sealing the facility, has it been compromised?” I would say no, the bank is locked down, secure, nothing can get in to cause damage at that point. That is how risk mitigation works."

    I must have missed the memo, but can you define "damage" -- which I can only infer you also mean "loss?" You mix two different verbs/scenarios: compromise and damage. The two can be mutually exclusive.

    If delivering service is a function of the business (or asset) and it can't deliver based upon DoS/Compromise/Damage, then you have loss.

    Loss is bad. Loss is a factor that affects risk.

    Also, by the way, even we Yanks (and I'm 1/2 Yank, 1/2 Kiwi) recognize that mitigating risk is only one possible outcome, you can avoid, accept or transfer risk, also, so your argument (if that) is extremely one dimensional.

    If you DoS a component of a transactional system, then loss of availability can ultimately affect the integrity of the system as a whole.

    Availability of a system as an attack vector is also a security element; a system being up or down can be good or bad depending upon whether it can be used to effect an attack/compromise/damage.

    Tell me again how your statement makes sense.

    I suppose confidentiality doesn't matter, either?

    Am I being punked?

    Chris "I got your Axiom right here" Hoff
    • ^
    • v
    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.


    I was just wondering, if it isn't a vulnerability, maybe it's a feature?

    Imagine, what if the system is not available half of the time and it's catering to thousands of clients? I just don't see the point of it not being a vulnerability issue. If the system is supposed to be up and running then it should be.

    CIA is a triad. They must be balanced and they must be together all the time. Security is CIA with the C, the I, and the A.

    Just my humble opinion. But hey, what do I know? I'm just student...
    • ^
    • v
    Many years ago, I had a conversation about this with the President of Zebec Inc (Then Zebec Data Systems, a small but very successful IT service organization. In his view: "Security helps me keep my services online, disaster recovery helps me get services back online quickly when something goes wrong."

    We all recognize that pulling the plug and locking the door represents the highest degree of security, but also the lowest degree of utility. Accordingly, effective security strives to establish a balance between security needs and "reasonable availablity" or utility needs.

    One of my early clients implemented MVS mainframe security with the primary goal of preventing the inadvertent deletion of a limited number of critical production files...an availability goal.

    At a more detailed level, I caution my clients to be careful with their ACL's and not be too free with Create and Delete access, especially on critical permanent files that are not normally deleted in the course of business. How often, for example, would you delete your Personnel Master or Client database? You preserve data and system "availability" with judicious security by avoiding accidents.

    Security does preserve and promote Confidentiality, Integrity, and Availability.

    My two (or three) cents worth.

    Live long and prosper!

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus