Once theoretical, the practical implementation of Spectre haunts web applications
A special thanks to Adam Chaudry for his contribution to this blog.
There is a common refrain in security that says, ‘attacks always get better, never worse’. When Spectre became widely reported in 2018, many chip manufacturers were relieved that despite the vulnerability’s severity, it was hard to exploit. That is no longer the case now that there is a method of execution via web browser. Fair warning — this blog gets technical in describing the problem. If you feel confused, remember that the most important thing is to focus on what to do about the problem.
Spectre Background
In early 2018, vulnerabilities were disclosed in the execution of transient instructions by microprocessors, which impacted the confidentiality of all data accessible to the kernel and microprocessor. Nearly all microprocessors developed by various vendors in the past 20 years were susceptible to these vulnerabilities including those resulting from speculative execution utilized by Spectre. In this case, Spectre, later identified by CVE-2017–5753 and CVE-2017–5715, utilizes speculative execution to expose sensitive data and bypass/subvert access control over restricted resources and transfer these data/resources, via an established side-channel.
In the three years since the discovery of these vulnerabilities, technology organizations and microprocessor vendors rushed to implement various guidance, patches, and mitigations in either microcode, OS, software, or hardware. However, the threat of these vulnerabilities may remain until there is a complete hardware architectural redesign of microprocessors due to origin of the flaw.
You can learn more about transient execution vulnerabilities by reviewing this paper from Intel.
The JavaScript Proof of Concept
Google has demonstrated that Spectre and its side-channel attack are still a looming and practical threat over the industry, with a released proof of concept (PoC) of Spectre variant 1 (CVE-2017–5753) for the web development and browser community. The PoC targets “a browser’s JavaScript engine to leak information from its memory” by taking advantage of gaps in protection from existing Web APIs, allowing implicit data leakage of memory across process spaces. To test this for yourself, visit https://leaky.page — also, here is the video demo and the detailed PoC writeup. The key takeaway with this PoC is that further improvements are required in existing application-level mitigations.
Spectre Mitigation for Developers
Google’s JavaScript PoC of Spectre v1 shows that Spectre can circumvent even more recent software/application-level mitigations in web browsers such as site isolation and cross-origin read blocking. These can only partially protect sensitive data in memory and do not completely prevent exploitation because of implicit data leakage into attacker processes in existing APIs as well as various other limitations.
Keep in mind, if you are building hardware or a web application, paying attention to theoretical attacks is important as they may eventually become practical, costing you in redesign to keep your hardware secure.
Guidance for Technical Staff & Leadership
For Leadership:
1. Conduct a risk assessment of Spectre and its variants to determine allocation of resources towards mitigations, etc.
2. Approve the usage of tools like Google’s Spectroscope to scan applications for Spectre vulnerabilities.
For Technical Staff:
1. Evaluate existing Spectre mitigations for all variants to ensure they are implemented or implemented correctly.
2. Evaluate and limit, when possible, sharing of resources: buffers, cache, etc., between web browsers and OS as well as between Cloud VMs.
3. Carefully design web APIs to prevent accidental data leakage into unauthorized/malicious processes.
4. Configure privilege checks if possible, upon Cache Flush and Eviction Instructions and similar instructions that manipulate shared memory resources.
5. Implement non-inclusive cache/cache inclusion policy upon microprocessor.
Note: CPU/Microprocessor recommendations might only be possible by the hardware vendor/manufacturer.
List of Relevant CAPECs (we may release new Spectre related CAPECs in the future)
CAPEC-212: Functionality Misuse
CAPEC-124: Shared Resource Manipulation
List of Relevant CWEs
CWE-1037: Processor Optimization Removal or Modification of Security-critical Code
CWE-1303: Non-Transparent Sharing of Microarchitectural Resources
CWE-1264: Hardware Logic with Insecure De-Synchronization between Control and Data Channels
CWE-208: Observable Timing Discrepancy
