Chris Mosby at myITforum.com

Zero Day Threats: Part 3.5 (addendum to part 3)

Wednesday June 27, 2007 at 6:31 pm CST
Posted by Craig Schmugar

Trackback

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.

Source: Computer Security Research - McAfee Avert Labs Blog