Confidentiality, Integrity, and AVAILABILITY

Confidentiality, Integrity, and AVAILABILITY

So Determina released an advisory about a bug they found in IE in Vista. They ran a simple ActiveX fuzzer against it, and it crashed. They were surprised that it worked, and so am I. However, that is not the whole story.

When they mentioned the problem to MSFT, they came to the conclusion that it is just a stability problem and not worthy of fixing in a security release. Determina agreed by this statement in the advisory:

We have confirmed that this issue can be used to cause the instance of Internet Explorer to exit when viewing the specially crafted Web page. We have confirmed that there is no possibility to use the bug to do anything beyond that, e.g. execute code.

As such it is more along the lines of a stability issue and would be treated along similar issues reported into Microsoft using the Online Crash Analysis system.

OK, this just befuddles me. Since when did people start ignoring the “A” in the CIA Triad? Availability is essential to security. I made this point in an email discussion thread I am currently involved in:

Microsoft complained that the flaws that flaws HD Moore found in IE were stability problems and merely resulted in crashes rather than actual vulnerabilities. Remember the CIA triad, people. Confidentiality, Integrity, and AVAILABILITY. If a company relies on web applications for its livelihood, you can bring said company to its knees if you make IE unavailable. It is still a security problem.

Any stability problem deserves to be classified as a security problem if the possibility of denying access to data or services exists. And there are many compnaies out there that rely on web services for their livelihood.

Microsoft, FIX IT!

Determina, go take a class in security.



5 Replies to “Confidentiality, Integrity, and AVAILABILITY”

  1. This is why I think FireFox will win over IE in security. Microsoft goes out of their way to figure out if they think it is exploitable or not, and ignore it if they think it’s not. The Mozilla guys say “We don’t know if it’s exploitable. We assume it is, so we fixed it.”

  2. @Michael,
    Hey, not so fast on giving up, already! I *am* having an angry day, and I was enjoying the rant on availability. In fact, I’d like to extend it to all software vendors that we depend on regularly for their stuff to work. I realize the point you were making is not such a big availability deal, but it happens enough in legitimate situations, it’s worth another swing at the pinata.

    OK, maybe I’m a bit biased because I’ve done third party Certification and Accreditation work on a number of large custom software projects. These projects have at least some budget for C&A; and within that, we manage to justify some time to review that the products actually work as they are supposed to.

    Availability should be based on some business requirements, primarily 1) percentage uptime per some time period (eg. 95% over a month), 2) maximum time to be out of service before SLA penalties are involved (mean time to repair – like 1 hour), and 3) average length of time a system can stay up and running (mean time between failures – eg. 20 days).

    Too often, I see system designers discounting the availability requirement if it is not clearly stated by the business folks. So, I encourage the business requirements people to be clear, or they may be very disappointed in the robustness of their systems. Not every system or piece of software has to have high availability, but there’s nothing like a piece of software that rarely crashes for building customer loyalty (and praise from bloggers).

    I will admit, too, that poor performance engineering can also look like an availability (therefore security) problem, but again, clarity in requirements helps a lot, regardless of whose department it is. You can at least blame the poor testers if they neglected to test the proper coverage. But testers are probably the purest among us, and if it’s in the requirements traceability matrix, they’ll test it.

    Not so angry now, even though I did not see any software getting more reliable since I began this post.

  3. LV,

    I see your point, and that makes a lot of sense. Hmmmm, I don’t think I was thinking correctly there. And, yes, I actually was having an angry day yesterday. Oh well…


  4. I’m not really sure this is worth fighting over. If someone goes to a specially crafted web page, then IE will crash and that’s it. Sure, you just crashed their browser, but how is that affecting the availability of the data? What sort of pages do your users go to that the “specially crafted page” would be in the way of your data? If that is the case and your web pages have been defaced to present code that crashes browsers, then you have deeper problems, and you should be happy your users are just being inconvenienced with a crashed browser.

    I’m not saying MS should leave the bug in place and not work on it, but it is very arguable that this is strictly a security concern. I think you would have more of a point if this were a DoS event on a server, or if the browser itself were hosting the content, or if legit data were causing the issue. Instead, this is a bug that will not be encountered in any legit site code.

    Are you just having an angry day today? 🙂

Comments are closed.