SAN FRANCISCO -- Five months after his vulnerability discovery rocked the technology industry, security researcher Paul Kocher shared his thoughts on
SAN FRANCISCO — Five months after his vulnerability discovery rocked the technology industry, security researcher Paul Kocher shared his thoughts on the Spectre flaws and the troubled vulnerability disclosure and mitigation efforts that followed.
Kocher, an independent security researcher
Like the Meltdown vulnerability affecting Intel chips, Spectre flaws involve abusing speculative execution, which was designed to speed up processor performance. The crux of the issue, Kocher said, is that 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.
“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 place 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, other types of modern software such as databases and web servers are much harder to apply Spectre fixes for 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
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 chip makers will never abandon speculative execution since 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
But the bad news, according to Kocher, is that chip makers 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
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
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.