You must have heard of Spectre vulnerability which was revealed back in 2018, alongside Meltdown, and it still continues to be a threat till this day. Spectre is a vulnerability that affects modern microprocessors that perform branch prediction, and targets the process in modern CPUs called speculative execution to leak secrets such as passwords from one site to another malicious site.
These side-channel attacks, dubbed as Meltdown and Spectre, allowed malicious applications installed on a device to access data as its being processed. This can include passwords stored in a password manager or web browser, photos, documents, emails, and data from instant messaging apps.
Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets.
Google developed this proof-of-concept to demonstrate the danger Spectre attacks pose to the browser, in hopes of implementing a new defensive measure.
In the years since the initial Spectre and Meltdown revelations, this specific type of attack has never been seen in the wild, and it was unclear how practical the method would be.
An interactive demonstration of the attack is available at https://leaky.page/; whereas the code and a more detailed write-up are published on Github here. Google aims to give web application owners a better understanding of the impact Spectre vulnerabilities can have on the security of their users’ data.
By releasing this proof of concept (PoC) code Google wants to explain why it’s important to deploy application-level mitigations.
The company developed a new technique that overcomes this limitation in the PoC. By abusing the behavior of the Tree-PLRU cache eviction strategy commonly found in modern CPUs, researchers were able to significantly amplify the cache timing with a single read of secret data.
This allowed them to leak data efficiently even with low precision timers. For technical details, see the demonstration here at https://leaky.page/plru.html.
Google also noted that, while all of the mechanisms described in their blog are important and powerful security primitives, they don’t guarantee 100% protection against Spectre; since they require a considered deployment approach which takes behaviors specific to the given application into account.
Google is working through W3C, an international standards body, to propose guidelines and best practices for both browsers and web developers.
Google’s proof-of-concept against its own Chrome browser not only illustrates the feasibility, but also hints at methods and strategies for both browsers and web developers alike to guard more comprehensively against such attacks.
“When I shared the exploit with the Chrome security team and the product security team, at that point everyone was like, ‘OK, wow, it’s very clear this is the impact,’” says Stephen Röttger, security engineer at Google. “Based on this we made a bunch of decisions to put more resources into rolling out Spectre defenses across our web frameworks.
“We think we have wrapped our heads around what developers need to do to protect themselves and the set of things they need to do is not astoundingly large,” says Mike West, head of Chrome platform security and co chair of the World Wide Web Consortium web application security working group.
“The real work, and the reason that the browsers can’t do it on the developer’s behalf, is that the decisions that need to be made are application-specific. They’re going to involve an analysis of the things your server offers to the internet and the ways in which those things ought to be offered.”
It can even be done on Apple’s M1 Arm CPU with some modifications, albeit minor. According to Google, the test attack can leak data at a rate of 1kB per second on Chrome 88, Linux, and an Intel Skylake processor.
Google has also published a video of a successful test that you can watch below.
In addition to releasing the PoC, Google is making recommendations (Post-Spectre Web Development and Mitigating Side-Channel Attacks) on how web developers can improve site isolation to deny access to cross-origin resources, thus effectively mitigating Spectre-style hardware attacks
Such mitigations include Cross-Origin Resource Policy (CORP) and Fetch Metadata Request Headers, Cross-Origin Opener Policy (COOP), and Cross-Origin Embedder Policy (COEP), along with standard protections, such as the X-Frame-Options and X-Content-Type-Options headers, along with SameSite cookies.
While experimenting, Google also developed other PoCs with different properties. Some examples include:
- A PoC which can leak 8kB/s of data at a cost of reduced stability using now() as a timer with 5?s precision.
- A PoC which leaks data at 60B/s using timers with a precision of 1ms or worse.
The chief components of the PoC are a Spectre version 1 “gadget” or code that triggers attacker-controlled transient execution; and a side-channel or a way to observe side effects of the transient execution.
Stephen Röttger and Artur Janc, Google information security engineers explain, “While Google and other browser vendors have developed mitigations for Spectre, such as Site Isolation, they don’t prevent exploitation of Spectre.”
“Rather, [these mitigations] protect sensitive data from being present in parts of the memory from which they can be read by the attacker,”
They continue to explain further that, while operating system and web browser developers have implemented important built-in protections where possible (including Site Isolation with out-of-process iframes and Cross-Origin Read Blocking in Google Chrome, or Project Fission in Firefox), the design of existing web APIs still makes it possible for data to inadvertently flow into an attacker’s process.
Google’s push for additional Spectre defense recommendations is still under preliminary consideration through W3C. Google has also released a new prototype Chrome extension called Spectroscope that scans an application to find resources that may require enabling additional defenses.
Stay tuned for more tech news!