Intel isn't afraid of new Spectre vulnerabilities, but researchers say they should be

mongeese

Posts: 515   +110
Staff member

A few days ago, a report was published detailing three novel Spectre vulnerabilities that exist inside the micro-op cache of all modern processors. Shortly after we wrote about it, Intel reached out to say that they don’t think the new vulnerabilities are a big problem. Their official statement reads: "Intel reviewed the report and informed researchers that existing mitigations were not being bypassed and that this scenario is addressed in our secure coding guidance. Software following our guidance already have protections against incidental channels including the uop cache incidental channel. No new mitigations or guidance are needed."

Put simply, updated software running on updated hardware should be impervious to the new exploits. I asked Assistant Professor Ashish Venkat, who lead the team that discovered the vulnerabilities and exploits, for his opinion on Intel’s statement. He conceded that Intel is right about the effectiveness of some existing countermeasures.

Intel’s secure coding guidance recommends three principles to prevent side-channel attacks. They’re for programmers to implement. If they’re all employed correctly, then they protect the software from all traditional side-channel attacks and most speculative execution side-channel attacks including micro-op cache attacks.

The principles:

  • Ensure runtime is independent of secret values.
  • Ensure code access patterns are independent of secret values.
  • Ensure data access patterns are independent of secret values.

In theory, they’re simple enough, but Intel admits that they can be difficult to implement in practice. Compilers with optimizers will sometimes break the principles to make the code more efficient, thus reintroducing the vulnerabilities. Venkat and his team don’t like that Intel is relying on programmers to update their software when the vulnerabilities they’ve discovered are ultimately a hardware issue.

"Constant-time programming is not only hard in terms of the actual programmer effort, but also entails high performance overhead and significant deployment challenges related to patching all sensitive software," Venkat said. "The percentage of code that is written using constant-time principles is in fact quite small. Relying on this would be dangerous. That is why we still need to secure the hardware."

The reluctance of government branches, banks, and large companies to update their low-level software is infamous. And it’s these sorts of organizations that these vulnerabilities pose the most risk to, because their servers are running a lot of different software all at once, and because they deal with a large volume of secrets.

When I spoke to Venkat, I asked if the average user should be worried, and he said that they "should continue to focus on where they’re most vulnerable, including viruses and malware on the internet." But to secure the digital services everyone uses, hardware vendors need to place a renewed emphasis on hardware security moving forward.

Image credit: Ryan

Permalink to story.

 

Theinsanegamer

Posts: 2,645   +4,121
Well duh. Researchers see things only from the point of view of a security researcher. Kinda reminds me of the medical "researchers" who said the most logical course of action was to completely lock down for years on end with absolutely no consideration for humans, just numbers.

These new spectre vulnerabilities would take serious effort to exploit, enough effort that it'd honestly be far easier to get in through any number of other systems. They are not remote execution and can be blocked with high level software security like antivirus.

Given the severe performance penalties for any low level firmware fix for this problem, yeah fixing it would not be worth the trouble, and given how hard it is to use it's likely not worth it to intel to fix, nor is it worthwhile to most of their customers, who will have other mitigations in place already. .
 

wiyosaya

Posts: 6,375   +4,692
Well duh. Researchers see things only from the point of view of a security researcher. Kinda reminds me of the medical "researchers" who said the most logical course of action was to completely lock down for years on end with absolutely no consideration for humans, just numbers.

These new spectre vulnerabilities would take serious effort to exploit, enough effort that it'd honestly be far easier to get in through any number of other systems. They are not remote execution and can be blocked with high level software security like antivirus.

Given the severe performance penalties for any low level firmware fix for this problem, yeah fixing it would not be worth the trouble, and given how hard it is to use it's likely not worth it to intel to fix, nor is it worthwhile to most of their customers, who will have other mitigations in place already. .
Yes. Preventing deaths is no consideration for humans. Got it. Freedom for dead people is more important.
 

wiyosaya

Posts: 6,375   +4,692
As I see it, more Intel BS. There is a switch in the Intel compiler that I use that apparently mitigates Spectre Variant 1 attacks. It is, apparently, up to developers to notice, learn about, and use this switch - if your code falls in one of their three categories.

From the options for the switch, it automatically reports potentially offending patterns to the developer during compilation, or employs one of several methods to ensure that the pattern is mitigated in some fashion. I have not investigated this more deeply because the code I work on does not involve secure or sensitive data.

Its there, but IMO, it is placing responsibility for Spectre mitigation to the developer. In other words, if your code is somehow compromised, I bet Intel will just point their finger back at any developer having problems and say something along the lines of "you know, we implemented a switch in the compiler you are using to mitigate that. Why are you not using it?".

I agree with the researchers that it is ultimately a hardware issue, and it is obvious Intel is not interested in fixing the hardware issue. Heaven forbid, it takes them some thought and design time to do so.
 

Bobbydpue

Posts: 216   +145
As I see it, more Intel BS. There is a switch in the Intel compiler that I use that apparently mitigates Spectre Variant 1 attacks. It is, apparently, up to developers to notice, learn about, and use this switch - if your code falls in one of their three categories.

From the options for the switch, it automatically reports potentially offending patterns to the developer during compilation, or employs one of several methods to ensure that the pattern is mitigated in some fashion. I have not investigated this more deeply because the code I work on does not involve secure or sensitive data.

Its there, but IMO, it is placing responsibility for Spectre mitigation to the developer. In other words, if your code is somehow compromised, I bet Intel will just point their finger back at any developer having problems and say something along the lines of "you know, we implemented a switch in the compiler you are using to mitigate that. Why are you not using it?".

I agree with the researchers that it is ultimately a hardware issue, and it is obvious Intel is not interested in fixing the hardware issue. Heaven forbid, it takes them some thought and design time to do so.

I feel like you didn't read the article. This new vulnerability isn't really exploitable in the real world so there isn't really anything to mitigate. Also why are you pointing your finger at intel? This is not just an intel issue it's an issue that also affects AMD, but just like I said not really.
 

HardReset

Posts: 1,237   +893
I feel like you didn't read the article. This new vulnerability isn't really exploitable in the real world so there isn't really anything to mitigate. Also why are you pointing your finger at intel? This is not just an intel issue it's an issue that also affects AMD, but just like I said not really.
Proof that it affects AMD?

Right. It theoretically affects AMD. Just because AMD uses uOP cache like Intel does not mean this attack works for AMD.
AMD has reviewed the research paper and believes existing mitigations were not being bypassed and no new mitigations are required.