Microsoft is disappointed

Update: It looks like the press wars are starting. Network World and
Information Week have published mostly one-sided articles about our exploit release, while The Channel Insider/PC Mag/eWeek/TechWorld articles cover both sides and even link back to this blog. A few of the articles are so wrong as to be funny, such as TechSpot (they fixed it), which claims that Microsoft released the exploit code. If you have worked with the MSRC in the past and would like to share your experiences, please post a comment!


On June 22nd, we released three new modules for the Metasploit Framework, one of which covered the recent Remote Routing and Access service vulnerability (MS06-025). Today, I received two email messages. One from a Microsoft Security Response Center (MSRC) team member and another from the primary author of the module we released.

The email from MSRC reads: "I recently saw your addition to the framework concerning MS06-025. In talking to REDACTED he mentioned that you may have also identified some addition issues with RRAS that were not addressed by this months release. I just thought I would check in with you and see if it would be possible to get additional details so we investigate and address them accordingly. I hope all is well and appreciate any insight you may be willing to share."

No problem there, a friend of mine relayed that there were some unfixed issues in RRAS, and the MSRC team member is doing their job and following up. I was starting to enjoy getting email from MSRC that didn't end in a vague threat. I replied back with some information about a still-present vulnerability in this service.

Then I read the next email. Nicolas points me to a new Microsoft security advisory and specifically mentions the third paragraph:

Microsoft Security Advisory (921923)

"Microsoft is disappointed that certain security researchers have breached the commonly accepted industry practice of withholding vulnerability data so close to update release and have published exploit code, potentially harming computer users. We continue to urge security researchers to disclose vulnerability information responsibly and allow customers time to deploy updates so they do not aid criminals in their attempt to take advantage of software vulnerabilities."

This sounds familiar...

Lets take a closer look at this paragraph:

"Microsoft is disappointed that certain security researchers..."

This is easy enough, there is only one publicly available exploit, it was written by Nicolas and myself. Lets assume they are referring to us.

"...have breached the commonly accepted industry practice of withholding vulnerability data..."

Microsoft claims that there is a "commonly accepted industry practice", but my own experience contradicts this. To support this statement, lets review the business services of a few companies in the security industry:

Verisign pays for exclusive rights to new vulnerabilties and sells a limited version of this data to their subscribers. Digital Armaments pays for exclusive rights to new vulnerabilities and then shares the data with its members. Immunity sells access to exploits and vulnerability information, often before the vendor is notified.

This covers the direct sale of information, but what about product vendors that include detailed vulnerability information with their subscription services? A vulnerability scanner can disclose vulnerability details through the act of checking for the flaw. IDS vendors that provide user-visible signatures disclose the exploit vector through the structure and content of their signatures. The vendors behind the two most popular products in each of these categories (Snort and Nessus) both charge for timely access to the most recent plugins and signatures.

A large portion of all vulnerabilities are discovered by "security researchers". How many of these researchers publish detailed vulnerability information on the same day that the vendor releases a patch? A quick review of the last 50 OSVDB entries shows that in almost every case, complete vulnerability details were available on or before the day that a vendor solution was released. The exceptions? Large proprietary software vendors.

We have identified three primary sources of vulnerability information; information brokers, security software vendors, and security researchers. The defacto standard seems to be quite different from what the MSRC is calling the "industry standard". Could it be that they are referring to the commercial software industry and not the security industry? Microsoft has coerced a handful of software vendors to join their Organization for Internet Safety (OIS). The OIS initially consisted of 12 companies, but this has dwindled down since the software vendors began aquiring the security service companies. The result is a group of vendors that actively suppress vulnerability disclosure within their organizations. Jericho (of Attrition/OSVDB) published an excellent description of how the OIS was formed, before the official name of the organization was even known.

"...so close to update release and have published exploit code, potentially harming computer users."

The vulnerability was disclosed on June 13th and the Metasploit exploit was released on June 22nd. This nine day period is a significant delay in the security world and nine days longer than nearly all of the recent vulnerabilties added to the OSVDB. Even dial-up users can complete an automated update in nine days.

To make things interesting, the exploit we released was actually for a different bug than the one mentioned in the advisory. Nicolas discovered this flaw while trying to figure out the vector for the "official" vulnerability. This is a common occurrence with proprietary software vendors, since the process of looking for one bug often turns up a dozen more that were never mentioned in any public documents.

Microsoft never mentioned this specific vulnerability in the advisory or to the Microsoft 0-Day Club (Microsoft Security Support Alliance), which meant that no intrusion detection systems were able to detect the Metasploit module at the time of this writing.

The mitigating factors for the RRAS vulnerabilties prevent an anonymous user from exploiting any version of Windows 2000 and all versions of Windows XP that have been upgraded to Service Pack 2. The anonymous cracker risk is limited to Windows XP users that have not upgraded to Service Pack 2 and were unable to install the latest updates during a nine day period.

"We continue to urge security researchers to disclose vulnerability information responsibly and allow customers time to deploy updates so they do not aid criminals in their attempt to take advantage of software vulnerabilities."

Totally irrelevant. We didn't report this bug and nine days is a longer grace period than most vendors receive.

The point of this rant is that Microsoft is doing themselves a disservice by asking for vulnerability information on one hand and then condemning the folks who provide it with the other. The MSRC obviously has some communication issues to resolve and we should take any commentary in their advisories with a large grain of salt.