Paul Kocher weighs in on Spectre flaws, vulnerability disclosure
At RSA Conference 2018, Paul Kocher, who co-discovered the Spectre flaws, discussed the chip vulnerabilities and explained why disclosure and mitigation efforts were so troubled.
SAN FRANCISCO -- Five months after his vulnerability discovery rocked the technology industry, security researcher Paul Kocher shared his thoughts on the Spectre flaws, the mitigation efforts, the troubled vulnerability disclosure process and the difficult road ahead for modern processor development.
Kocher, an independent security researcher and consultant, spoke at RSA Conference 2018 on Tuesday and is one of two people who discovered the Spectre flaws in 2017 -- Jann Horn of Google's Project Zero also independently discovered the vulnerabilities, along with the Meltdown flaw.
Like the Meltdown vulnerability affecting Intel chips, Spectre flaws abuse speculative execution, which was designed to speed up processor performance. The crux of the issue, Kocher said, is speculation execution is so deeply ingrained in modern processor design that it's virtually impossible to remove. "If you build a processor the way textbooks tell you to do it to make it fast, you're going to build an insecure processor as a consequence," he said.
That fact has made short-term mitigation of the Spectre flaws, as well as long-term solutions, extremely challenging, Kocher said.
Mitigation efforts
"The mitigation for Spectre is extremely messy," Kocher said, adding that the fixes that have been introduced so far are not long-term solutions to the underlying issue.
Software vendors like Microsoft could put fixes for the Spectre vulnerabilities in the source code for any conditional branch path that might lead to something going wrong; Kocher called these "speculation barriers." But if those barriers are placed in every conceivable spot within the source code that might be vulnerable to the flaws, it will destroy performance. And if they are not applied, attackers will still be able to exploit the Spectre flaws.
"You're kind of damned if you do, damned if you don't," Kocher said.
As a result, vendors have to carefully pick and choose where they apply the fixes. Besides operating systems, he said, it's much harder to apply Spectre fixes to other types of modern software, such as databases and web servers, because those programs are used to receive data from untrusted sources.
Hardware vendors, on the other hand, have applied microcode updates that modify the way the branch predictor works in the processor, but Kocher said those modifications have led to stability problems for the chips.
Kocher called these fixes "a fairly unsatisfactory solution," because the microcode updates are only available to the operating system and not applications on the affected system. They also lead to performance hits. While Intel's microcode updates have had significant issues, Kocher said he'd rather have mitigations that come with problems than no mitigations at all, criticizing Arm Holdings' lack of response to Spectre.
The roadmap ahead
Is Spectre even a bug? Kocher said he's had conversations with several people about that question. On one hand, all of the elements involved in speculative execution are working the way they were designed to work. But regardless of whether speculative execution is working correctly or not, the issue remains. "It's a lot of eager implementation of things to make stuff faster, but not necessarily a lot of thinking about the true consequences of putting these elements together," he said.
That complicates long-term remediation efforts, Kocher said, because chipmakers will never abandon speculative execution, as it's become so intrinsic to processor performance. However, he offered some advice for the audience for short-term mitigation, starting with regularly applying updates as they become available.
Kocher also recommended improving process separation within enterprise infrastructure and to be "especially cautious about hyperthreading," because he said he expects more side-channel attacks that exploit that feature are coming in the near future.
But the bad news, according to Kocher, is chipmakers need to drastically alter their product roadmaps and fundamentally change how they design processors. Long term, all chips will need to be designed and built with security in mind; otherwise, the pursuit of faster speeds and performance gains is going to lead to more Spectre-like vulnerabilities.
Vulnerability discovery and responsible disclosure
Why wasn't Spectre found earlier? That's another question Kocher said he gets frequently, and he said several factors contributed to the matter. One major road block, Kocher said, was Intel and other chipmakers didn't consider side-channel attacks like Spectre to be out of scope for traditional vulnerabilities.
As for the vulnerability disclosure, the researchers and vendors were forced to go public early, he said, after media speculation about the vulnerabilities became too big to ignore.
The coordinated vulnerability disclosure process "was an absolute mess," Kocher said. Many organizations and people were involved. And, ultimately, more people than necessary were informed of the vulnerabilities; that led to information about Meltdown making its way into the media.
The way the vendors handled the process was also problematic. "Everyone was well-intentioned," he said, but there were so many questions about which third parties needed to be notified and involved in the process -- and whether or not governments needed to be looped in -- that it complicated and prolonged the process.
Eventually, so many people knew what was going on that word leaked to the media. "I had exactly the same thing happen with the differential power analysis [vulnerability]," Kocher said. "I don't know how to do vulnerability [disclosure] and manage a vulnerability like this."
If the disclosure process isn't done right, Kocher said, it will allow threat actors to get an early jump on exploiting a flaw. The industry needs to figure out a better way to do coordinated disclosure of that scale, Kocher said, because more Spectre-level vulnerabilities are sure to come.
