Archive
The Known Costs of Security Embargoes
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
Recent Posts
- FreeBSD Bootonly ISO failures PXE booting under UEFI
- The Known Costs of Security Embargoes
- Windows 10, VirtualBox 5.2.0 w/ FreeBSD 12.0-CURRENT Guest
- Internet Privacy: Who Do You Trust?
- Disk I/O Performance Under Filesystem Journaling on FreeBSD 10.3
- Integrating FreeBSD w/ FreeIPA/SSSD
- Verisign Announces vBSDcon 2015
- Starting A Daemon via daemon(8) in FreeBSD
- QEMU: Convert non-Sparse Image to qcow/qcow2 Sparse Image
- Troubleshooting Large, Stalling git/ssh Transfers
- Manual Package Builds For FreeBSD < 10.0-RELEASE
- BSDCan 2014 Travel Woes
- FreeBSD 10.0: release.sh mapped
- FreeBSD Ports: Managing Custom Ports/Physical Categories
- vBSDcon Wrap-Ups
Top Posts & Pages
Archives
- September 2018
- February 2018
- October 2017
- April 2017
- December 2016
- March 2016
- May 2015
- January 2015
- December 2014
- July 2014
- May 2014
- February 2014
- December 2013
- November 2013
- October 2013
- September 2013
- August 2013
- July 2013
- May 2013
- April 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012