Responsible disclosure on a timetable

In response to its haphazard patch release cycle in the late 1990s, Microsoft launched an every second-Tuesday-of-the-month "Patch Tuesday" program in 2004. Last week, on February 14 to be exact, Microsoft abruptly canceled its current monthly set of patches and said that its slate of new patches would return on March 14. The problem is the day before was the end of a 90-day window that Google had established as part of its disclosure policy and so the security researchers at Google Project Zero went ahead and released details of the still open vulnerability.

Now a fully-documented Windows gdi32.dll heap-based out-of-bounds vulnerability that includes memory disclosure in EMR_SETDIBITSTODEVICE among others is in the wild. While there is no active exploit against what is known as CVE-2017-0038, the situation nonetheless points to a delicate balance between researchers and vendors with the public caught in between. Should disclosures be automatic when vendors are working toward a solution?

Coordinated Disclosures

Many researchers today do responsibly disclose new vulnerabilities to the vendor. This is a process that can't be open-ended. After years of discussion the industry has settled on 90 days during which the vendor must patch or otherwise have a workaround in place for the public disclosure. And at Google, if the vulnerability is being exploited in the wild, then the affected company has only seven days to respond (for example, Cloudbleed).

Basically, the clock starts ticking whenever a vulnerability is reported. But there are several assumptions here. One, it is assumed that the company has a means to report a vulnerability to one of its products. And two, it is assumed that there's a team of internal security gurus to confirm the vulnerability and set in motion the means to remediate it. That isn't always the case.

Newbies

Some organizations legitimately can't meet the deadline because they lack the security experience or the prior need. A lot of companies that fall into this camp traditionally didn't traditionally connect their products or services to the internet. They are now learning about risk and threat models the hard way.

Legacy software may have been configured with ports open and old protocols in the past because, if it didn't rely on the internet, it didn't matter. Today adding an TCP/IP stack in a new release means these companies much perform due diligence. They need to have the ability to look at the code holistically and determine where vulnerabilities and potential risks might come into play. Again, if the organization didn't previously have to worry about such risks then this it is vital that they conduct an audit or pen test as soon as possible.

Frustration with vendors

More important, perhaps, is how to communicate a new vulnerability. Having an all-purpose contact@somecompany.com or technicalsupport@somecompany.com is not enough. There needs to be an abuse@somecompany.com as well, and someone knowledgeable on the other side of that to filter out the spam and realize when a valid issue is first presented.

In frustration, some researchers attempting to contact companies without any mean of visible support disclose their findings out of frustration arguing it is the only way to get the vendor's attention. This is certainly not good for the organization affected. Nor is it good for the security community - if only because it gives researchers a bad name.

Microsoft's a leader

Microsoft is no stranger to vulnerabilities so the above conditions don't apply. Worse, what Google found, and reported to Microsoft 90+ days ago, was a problem with an existing patch. According to MITRE's CVE database, the new Microsoft vulnerability is a result of "an incomplete fix for CVE-2016-3216, CVE-2016-3219, and/or CVE-2016-3220."

Mateusz Jurczyk with Google Project Zero wrote in a technical description, "As part of MS16-074, some of the bugs were indeed fixed, such as the EMR_STRETCHBLT record, which the original proof-of-concept image relied on. However, we've discovered that not all of the DIB-related problems are gone."

With the new vulnerability, Jurczyk said, "It is possible to disclose uninitialized or out-of-bounds heap bytes via pixel colors, in Internet Explorer and other GDI clients which allow the extraction of displayed image data back to the attacker. I have confirmed that the vulnerability reproduces both locally in Internet Explorer, and remotely in Office Online, via a .docx document containing the specially crafted EMF file."

Perhaps there's a clue in that the vulnerability touches upon both Internet Explorer and Outlook. Microsoft previously said it was changing its Patch Tuesday releases as of February 2017, releasing Internet Explorer's updates in a separate package from the OS fixes. So it's ironic that there was no February 2017 Patch Day.

Sometimes responsible disclosure works well

Last year researchers Mike Ahmadi of Synopsys and Billy Rios of WhiteScope disclosed 460 vulnerabilities in Philips Xper Connect, an optional bidirectional hospital information system (HIS) interface. Previously Ahmadi and Rios identified 1,418 vulnerabilities in the CareFusion Pyxis SupplyStation. Both disclosures were coordinated through the Department of Homeland Security's ICS-CERT. And, it should be noted, both disclosures took more than ninety days to fully negotiate.

Amadhi wrote "I sent the CareFusion Pyxis SupplyStation results with over 1400 vulnerabilities to the FDA as a reminder that a bit more urgency was perhaps in order. They sent the report to DHS ICS-CERT, and this began a process between me, ICS-CERT, and CareFusion (now owned by BD). The person I worked with directly at BD was Rob Suarez, who I had worked with (briefly) while he was with another medical device vendor. What struck me about working with Rob and his team at BD is that they did not deny any of the vulnerabilities existed, and also offered up all affected systems (6 total), voluntarily for use in the advisory.

Bad patch

It's possible, as ZDNet's Mary Jo Foley suggests, Microsoft pulled the patch because of stability issues. A valid concern. It happens infrequently but Microsoft has had to pull a released patch now again.

According to MITRE, impacted software versions are Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, Windows 10 Gold, 1511, and 1607, and Windows Server 2016. Given the diversity of systems represented, it's plausible that the company wanted to but didn't have the confidence to release.