Google’s Chrome devs ponder limited options for thwarting Spectre attacks

The Spectre and Meltdown speculative side-channel CPU attacks have forced Chrome security engineers to reassess how they can protect sensitive data in the browser.  

Google introduced a number of browser mitigations in response to the Spectre attacks, chiefly in the form of site isolation, but also mitigations in Chrome’s V8 JavaScript renderer, and as all browser makers did, by making high-resolution timers accessible by JavaScript code more “coarse”.      

While these offered some protections in certain circumstances, Google’s V8 engineers have concluded that site isolation for now is the only viable “systematic" mitigation to speculative side-channel attacks, which has implications for how Chrome handles autofill data, such as payment card data and passwords.   

"In this new mental model, we have to assume that user code can reliably gain access to all data within a renderer process through speculation,” a V8 engineer is quoted as writing in a new document covering various approaches in Chrome to mitigating Spectre. 

“This means that we definitely need some sort of ‘privileged/PII data isolation’ guarantees as well, for example ensuring that password and credit card info are not speculatively loaded into a renderer process without user consent.”

Spectre forced Chrome engineers to assume that any active web content, including JavaScript, Adobe Flash and Chrome’s PDF rendering engine, PDFium, “will be able to read any and all data in address space of the process that hosts it” even if the pages are from different origins. 

“The loss of cross-origin confidentiality inside a single process is thus not merely theoretical. The implications of this are far-reaching,” Chrome security engineers note.

That is particularly tricky because a successful Spectre attack can bypass exploit mitigation techniques used by the underlying operating system, such as address space layout randomization (ASLR), and control flow integrity, which in Windows 10 is known as Control Flow Guard.

Hence the need for site isolation in Chrome, which puts pages from different sites in their own sandboxed processes.

Site isolation not enabled by default yet but eventually will be, and with this week’s release of stable Chrome 67 was enabled it by default for a small group of users. The option to enable it has been available since Chrome 63.

Site isolation’s main downside is that iit can cause Chrome to consume at least 10 percent more memory when many tabs are opened. The problems are worse on Android where site isolation remains an experimental feature, while Chrome on iOS relies on Apple’s WebKit mitigations.

Site isolation also doesn’t currently work for all content types. For example, Flash content for all sites currently runs in a single process. Even though Flash will be dead by 2020, Google is considering isolating Flash content on a per site basis.       

And site isolation may not protect sensitive data in all circumstances. Chrome developers raised concerns about passwords and payment card data shortly after the Meltdown and Spectre attacks were publicly revealed in early January. 

This centered on Chrome’s autofill feature, which sends a preview of autofill data, such as credit card numbers, to the renderer process when the user hovers over the suggestion to autofill data. This happens even if the user hasn't clicked on a button to explicitly confirm the action, meaning an attacker could use JavaScript code to read memory in the renderer process and steal credit card numbers without user action. 

Chrome developers believe they’re in a “pretty good place” with respect to this issue except where usernames and passwords are concerned, though there are limitations to how this could be exploited. 

The goal they’ve set is to “enable a good user experience with autofill, payments, and passwords, while also not ending up with a browser that leaks these super-important classes of data.”