Once theoretical, the practical implementation of Spectre haunts web applications

“Microchip e microciop” by Un ragazzo chiamato Bi is licensed under CC BY-SA 2.0

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-74: Manipulating State

CAPEC-141: Cache Poisoning

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

--

--

--

Lead author: Steve Battista. Support: Steve Christey Coley, Adam Chaudry, Rich Piazza, and Alec Summers. https://cwe.mitre.org + https://capec.mitre.org

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Cyber security: It’s time for a check-up

New Token Listing Announcement — ELON

Top 9 Love Scams You Might Not Know

The Corona tracing app and the question of trust

Write up of two HTTP Requests Smuggling

{UPDATE} Memories Off 6 ~T-wave~ Hack Free Resources Generator

Instructions to claim the Pioneer and Ocean Heroes

6 Questions Every Seclorite Wants to Answer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
CWE/CAPEC

CWE/CAPEC

Lead author: Steve Battista. Support: Steve Christey Coley, Adam Chaudry, Rich Piazza, and Alec Summers. https://cwe.mitre.org + https://capec.mitre.org

More from Medium

Handle Incidents like a Pro!

Criminalizing Ransomware Payments

What is 5G Security?

Traceroute