Security

Paul Kocher weighs in on Spectre flaws, vulnerability disclosure

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

and
consultant, is one of two people who discovered the Spectre flaws in 2017 (Jan Horn of Google’s Project Zero also independently discovered the vulnerabilities along with the Meltdown flaw). During an hour-long session on Spectre at RSA Conference 2018 Tuesday, Kocher shared his thoughts on the mitigation efforts, the vulnerability disclosure process and the difficult road ahead for modern processor development.

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.

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 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

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 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

side channel
attacks that exploit that feature are coming in the near future.

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

road block
, Kocher said, was that Intel and other chip makers didn’t consider side channel attacks like Spectre to 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.


Source link

Tags

About the author

GG

Add Comment

Click here to post a comment

Your email address will not be published. Required fields are marked *

Do NOT follow this link or you will be banned from the site!