Zero Day Threats: Part 3.5 (addendum to part 3)
Wednesday June 27, 2007 at 6:31 pm CST
Posted by Craig Schmugar
This is just a quick update to clarify a couple points and respond to some comments / posts I’ve read on the matter.
First off, the definition:
| The public availability of exploit information on the same day that a vulnerability is publicly disclosed. |
So what’s wrong with this definition? Well, someone can exploit an unknown and unpatched vulnerability to attack someone else, without any public disclosure or even knowledge. This is true. Of course, without being aware of the details (or even existence) one could not validate and label the threat as a zero day. But after you have this information my simple definition is satisfied. In other words, a zero day is not a zero day until it’s a zero day.
Another likely point of contention is the inclusion of the word public. Public is included for the specific reason of dismissing vulnerabilities and exploits that are privately reported to the vendor; and without the term being included, virtually all vulnerabilities shared with anyone are zero days, including those found by the vendor themselves.
While it is not perfect, I do think it’s a good–simple–general purpose definition.
Second, the inclusion of low-risk vulnerabilities in the stats, such as those limited to local denial of service:
I didn’t make assumptions as to the motivations of those who disclosed zero day information. If someone was out to create a headache for Microsoft by generating more work or publicity at “a bad time” they might strategically release their DoS-only exploit around Patch Tuesday.
Clearly a vulnerability that allows for arbitrary code execution is significantly more critical, and valuable, than something that is limited to DoS. Many vulnerabilities are reported as DoS, which may potentially be exploitable (allow for remote code execution). It can take significantly more effort to confirm code execution and, depending on the motivation of the reporter, they may not make the effort. You have cases where some vulnerabilities may or may not be limited to DoS.
So for the sake of the blog, I did not discount any vulnerability types. FWIW here’s a breakdown of only those threats categories as remote code execution discovered/disclosed ±3 days of Patch Tuesday.
- 2005 0% (8)
- 2006 41% (40)
- 2007 30% (10) as of April 15
As I stated in my previous post, the dates associated with threats discovered though active exploitation are unreliable.
Third, “Exploit Wednesday”
My post really didn’t cover this. Exploit Wednesday is less about malicious attackers sitting on exploits until the day after Patch Tuesday, and more a result of those who previously, and responsibly, reported a vulnerability to Microsoft and then waited until Patch Tuesday before going public. After Microsoft releases a patch, they then disclose enough details that allow for the creation of an exploit. Another factor is those who reverse engineer the patch to discover the vulnerability and then write, and release, an exploit.
The 4th and final part of this blog series is in the works.
June 28th, 2007 at 3:20 pm
I love your definition, but your language in the rest of this post bounces between `information’ (a bad word in the first place), `vulnerability’, and `exploit’.
Vulnerability, to me, means the existence of vulnerability information. You can’t have zero-day vulnerability information because you can’t have non-zero-day vulnerability information. Therefore, “zero-day” only applies to exploits. Your definition of zero-day is simply one of the best I’ve seen in at least 7 years. But it begs a question, what is a pre-zero-day and how do we detect/prevent them?
You also bounce between `exploit’ and `exploit information’ a lot. I guess the distinction you are trying to make is that vulnerability information just gives information that the vulnerability exists and has been fixed with the forthcoming patch. `Exploit information’ tells you how the vulnerability works enough to write a proof-of-concept that would activate the vulnerability in practice. The patch itself can be considered `exploit information’ (and therefore “zero-day”), but is not in and of itself a zero-day because the purpose of the patch is not to activate the vulnerability, but to de-activate it.
The problem with a lot of this is that when you start to assume the motivations of the owners that release either the vulnerability information or exploit information, including whether or not either information option was the responsible vendor - you get into a lot of strange situations that, in my opinion, shouldn’t change any of the definitions.
[Responsible] vulnerability disclosures are interesting because almost no two are alike. Vendor attitudes change, their relationship with the third-parties that disclose to them change, and the vulnerabilities are different with varying levels of criticality and importance to everyone involved. If the vulnerability gets media attention, this could rapidly change the situation even further because they may have a completely different view of how this affects consumers (or other third-parties involved). Because of the pre-knowledge of random media and consumer reaction to vulnerabilities - vendors and security researchers are left to formulate their disclosure strategies around what the public is going to do or say. This affects how they disclose (pre-disclosure information, vulnerability information, patch that contains the least amount of exploit information as possible, etc), when they disclose (Patch Tuesday or out-of-cycle), etc.
I think many researchers make the distinction that a `vulnerability’ exists when they feel confident that the vulnerability will work for exploit purposes, and an `exploit’ is when they actually write the payload to do it (usually in shellcode). Zero-day to them would mean that they write that exploit code at all. Some are opposed to doing this for ethical reasons. Some feel that it would only be worth writing if somebody paid them to do it.
Vulnerabilities are often found by accident, and “DoS conditions” (as you describe) could be simply an internal report of a crash followed up by an administrator trying to prevent his/her user (or userbase) from experiencing another crash. Almost all of of these crash events turn into security vulnerabilities if they can be reproduced, and at that point - according to your definitions [that include DoS exploits], it can become a zero-day as soon as publicly disclosed with the full-information about how to reproduce.
There are also many different types of vulnerabilities that represent orders of magnitude of vulnerability information for future vulnerability purposes or multiple ways of exploitability. A buffer overflow security “bug” is totally different than an XSS threat, which is different than a logical flaw, which is different than a design exposure. For example, can one disclose a zero-day “coding weakness”? What if it does include an actual exploit?
The different types of vulnerabilities, the criticality (and false criticality) that is placed on them, and the motivations of everyone involved make defining words like “zero-day” very difficult. What you are up against is a consistently-changing gray area, as organizations like MITRE begin to re-classify what the definition of vulnerability even is… even they know that they got CVE wrong the first time. Also see the definition of: hacker.