Intel Says New Spectre Chip Flaw Is Already Fixed But Security Researchers Say Not So Fast

At the start of May, researchers at the University of Virginia announced that current Spectre chip vulnerability mitigations could be bypassed entirely, bringing the ghostly security flaw back to life. Intel has now officially responded by claiming that software coded following its specific security guidance protects against these new vulnerabilities. However, UVA  researchers seem to disagree with the general sentiment. The question now is, who is right and what needs to happen to protect end-users?

Here's Intel's full statement on the matter...

“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."

After the initial story broke about Spectre, Intel released the above statement in response to the report and heightened, renewed concern. At a high level, this secure coding guidance explains that confidential information needs to be accessed independent of the runtime, code access patterns and data access patterns. If developers follow these rules, no new mitigations or guidance is necessary as there is nothing still vulnerable, in theory.
In practice, however, it may not matter. Ashish Venkat, researcher and Assistant Professor of Computer Science at UVA Engineering, explained that the uncovered vulnerability still lies within the hardware. Furthermore, while he concurs that software should be designed more securely as Intel guides here, it can be difficult “in terms of the actual programmer effort” and can entail “high performance overhead and significant deployment challenges related to patching all sensitive software.” If this is truly the case, then only a fraction of code that's out in the wild is actually written to this standard Intel is referencing, and chip hardware also needs to be secured as much as, if not more than, the software is.

To the contrary, the UVA team notes... 

"Certainly, we agree that software needs to be more secure, and we agree as a community that constant-time programming is an effective means to writing code that is invulnerable to side-channel attacks. However, the vulnerability we uncovered is in hardware, and it is important to also design processors that are secure and resilient against these attacks.

In addition, 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. 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."

Interestingly, surrounding all of this is the discussion about protecting confidential end-user information from vulnerabilities like this, some end-users apparently do not seem to care. Perusing social media sites like Reddit, Facebook, Twitter, and others, the common rhetoric is that people do not want to lose performance to better security, and that this will not affect them. In fact, in some instances, people stated they would hand over data if they were asked, which seems ridiculous considering how concerned most are with privacy topics these days. 

While it is important to discuss which parties are responsible for fixing these new vulnerabilities, especially when Intel believes it should be up to developers, we also need to look at who the fixes will affect. Perhaps there will be performance hits as fixes come out, but that should be worthwhile for privacy’s sake until chip OEMs can create new and more secure processor architectures. Whatever ends up happening, let us know what you think of Intel’s stance, and how this may affect end-users, in the comments below.