Home > FreeBSD, Technical Miscellany > The Known Costs of Security Embargoes

The Known Costs of Security Embargoes

February 15, 2018 Leave a comment Go to comments

The Known Costs of Security Embargoes

A security embargo is an agreement between parties, typically a vendor and interested parties. The interested parties are generally individual(s) or organization(s) that discovered a security vulnerability in a vendor product. Security embargoes are not limited to two parties and may include multiple vendors and/or other stakeholders. Parties to an embargo generally agree to withhold disclosure of a security vulnerability until a mutually agreed upon date, which is often a date the vendor will publish patches.

Security embargoes primarily provide vendors time to research and patch vulnerabilities prior to public disclosure and limit the risk a malactor may exploit such a vulnerability before patches are available.

In February 2017, Mitre assigned CVEs to Intel for each of the vulnerabilities we now know as Meltdown and Spectre, CVE-2017-5715, 2017-5723, and 2017-5754. There exists ambiguity in the timeline of events surrounding disclosures. For example, The Guardian indicated Google disclosures were made to Intel in June and July 2017 while The Verge indicated December 2017. What is known as fact, however, is that the public was generally unaware until Google’s announcement on January 3, 2018, almost a week prior to the agreed upon disclosure date of January 9. In fact, Intel’s disclosure of Meltdown-Spectre is coming under increasing scrutiny after The Wall Street Journal on January 28 reported that Intel had made disclosures to Chinese organizations prior to notifying US authorities.

Also known is that Alex Ionescu publicly posted about a Microsoft work-in-progress that is suggestive that Microsoft and some Linux related project(s) were aware of the vulnerabilities in November 2017 and likely before.

Meanwhile, researchers were beginning to investigate — and ultimately exploited — these vulnerabilities disclosing them to Intel over a period of months. It follows that organizations who disclosed their findings to Intel likely became party to a security embargo at that time.

While the timeline is debatable, it’s suggestive that work to mitigate these vulnerabilities was in high gear as early (likely earlier) as September 2017 particularly with Microsoft and some Linux contingent, as alluded to earlier.

Despite the lack of clarity surrounding the disclosures, it is a fact that the FreeBSD project was not aware until late December 2017 while other BSD projects received no advance notice. This should have been disclosed to the BSD operating systems at the same time it was disclosed to Microsoft and Linux. Why? BSD is ubiquitous among many network and systems devices forming a foundation upon which Internet infrastructure is built. The failure to notify these projects has put undue risk on various pieces of the Internet.

When Meltdown-Spectre were finally disclosed, Microsoft and Linux were better prepared to deploy OS patches. After all, they had been working for months on the problem. Conversely, the BSD operating systems had only a week to prepare and are still catching up on patch integrations. Intel has even been ill prepared as they released microcode that was subsequently recalled then followed up with another release recently patching Spectre Variant 2 (CVE-2017-5715) at time of writing. Consequently, organizations likely continue to remain vulnerable.

This brings attention to the problems the community faces as it becomes increasingly obvious security embargoes do not scale to accommodate all possible stakeholders. There are no clear rules beyond an unenforceable agreement to disclose vulnerabilities, which fosters an environment where only some stakeholders are informed of newly discovered vulnerabilities.

In conclusion, there must be continuing discussions about these problems and their potential solutions. Failing to encourage continuing discussions will only maintain the status quo.

Discalimer

I have been a UNIX engineer for more than 20 years. Still, my experience is not generally within the security realm. This post describes a personal interpretation of problems regarding security embargoes particularly surrounding Meltdown-Spectre.

References

[1] https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
[2] https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
[3] https://www.theguardian.com/technology/2018/jan/04/meltdown-spectre-worst-cpu-bugs-ever-found-affect-computers-intel-processors-security-flaw
[4] https://www.wsj.com/articles/intel-warned-chinese-companies-of-chip-flaws-before-u-s-government-1517157430
[5] https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
[6] https://www.theverge.com/2018/1/11/16878670/meltdown-spectre-disclosure-embargo-google-microsoft-linux
[7] https://twitter.com/aionescu/status/930412525111296000?lang=en
[8] https://thehackernews.com/2018/02/intel-processor-update.html

Advertisements
  1. No comments yet.
  1. February 24, 2018 at 1:57 PM
  2. February 24, 2018 at 2:28 PM

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: