During the Google I/O developer conference, Chris Palmer from the Chrome security team talked about how Google and other browser developers scrambled to protect web surfers from Spectre-based attacks. Of the two processor vulnerabilities reported in January, Spectre can theoretically allow hackers to access sensitive data through a compromised website, requiring a different approach in how browsers must now render your favorite sites.
As previously reported when Spectre was first revealed, part of a processor’s speed is based on predicting the quickest path to the current task’s end result. It tests the outcome using numerous “if/then” avenues, loading this data in local on-chip memory (aka cache). The problem in Spectre is that for all those avenues not taken, the data remains in the cache and can be seen across privilege levels, processes, and web page origins.
Based on that leftover data, an attacker could insert code into JavaScript that runs in a loop and eventually gains access to “out of bounds” sensitive information. There were solutions available, but they severely hindered the processor’s performance. There were alternatives, but they required cooperation between browser developers that normally were at odds.
Working together for the safety of the web
The alternative method would require changing how web browsers would render a webpage — and this is where competing browser developers worked together to solve the problem. For instance, a webpage is typically comprised of different parts from different origins and rendered as a single page. But there could also be a “hostile” origin in the mix containing an element that can exploit the Spectre vulnerability using what are called “gadgets.” These gadgets can read data generated by the “safe” origins.
Google’s first fix in Chrome was to turn off a feature called SharedArrayBuffer, so hackers couldn’t keep track of the timing used when data moves from the processor cache to the system memory. Palmer said this method was the easiest route to exploitation.
“Other browsers did similar things, and we all collaborated to sort of figure out how we were going to do this in a way that doesn’t hurt the web so that we are all on the same page,” he said. “It’s kinda of a happy story that comes out of this is a really good collaboration between the security teams of a lot of different browser vendors. It’s been a great experience for all of us and I think we’re gonna come out with a much better web thanks to the help of everyone.”
Another “fix” was to turn off processor speculation on a micro-scale and change the way code is compiled to prevent speculation gadgets. This didn’t provide 100 percent protection but gave Google’s team “breathing room” to develop long-term fixes.
Site isolation, shown above, was another useful tool against Spectre. It essentially isolates “good” from “bad” origins by assigning each origin with its own render process. Thus, origins are isolated from each other and protected against any origin that suddenly becomes evil. That evil origin can only read its own data.
Unfortunately, site isolation and the accompanying cross-origin read blocking component will require 10 percent more system memory use, he said.
