Spectre can trick vulnerable applications into leaking the contents of their memory.
The UVA team found a way to exploit what is called a micro-op cache which speeds up computing by storing commands early in the speculative execution process. Micro-op caches are present in Intel processors produced since 2011.
Ashish Venkat, an assistant professor of Computer Science at UVA Engineering, said in a statement: "Think about a hypothetical airport security scenario where TSA [Transport Security Administration] lets you in without checking your boarding pass because (1) it is fast and efficient, and (2) you will be checked for your boarding pass at the gate anyway.
“A computer processor does something similar. It predicts that the check will pass and could let instructions into the pipeline. Ultimately, if the prediction is incorrect, it will throw those instructions out of the pipeline, but this might be too late because those instructions could leave side-effects while waiting in the pipeline that an attacker could later exploit to infer secrets such as a password.”
The defences created against Spectre are useless in the face of the new attacks as they come into play during a later stage of speculative execution.
“Intel's suggested defence against Spectre, which is called LFENCE, places sensitive code in a waiting area until the security checks are executed, and only then is the sensitive code allowed to execute,” Venkat said.
“But it turns out the walls of this waiting area have ears, which our attack exploits. We show how an attacker can smuggle secrets through the micro-op cache by using it as a covert channel.”
Xida Ren and Logan Moody, both doctoral candidates, and master's degree holder Matthew Jordan worked with Venkat to find the flaws.
The team collaborated with Dean Tullsen, professor of the Department of Computer Science and Engineering at the University of California, San Diego, and his doctoral student, Mohammadkazem Taram, to reverse-engineer certain undocumented features in Intel and AMD processors.
“In the case of the previous Spectre attacks, developers have come up with a relatively easy way to prevent any sort of attack without a major performance penalty," said Moody. “The difference with this attack is you take a much greater performance penalty than those previous attacks.”
Ren, the lead student author, added: “Patches that disable the micro-op cache or halt speculative execution on legacy hardware would effectively roll back critical performance innovations in most modern Intel and AMD processors, and this just isn’t feasible."
Venkat said: “It is really unclear how to solve this problem in a way that offers high performance to legacy hardware, but we have to make it work. Securing the micro-op cache is an interesting line of research and one that we are considering.”
Update, 4 May: An Intel spokesman said it had reviewed the report and and informed the researchers that existing mitigations were not being bypassed and that this scenario was addressed in its 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," he added.
Update, 5 May: Venkat responded: "We're aware of these guidelines from Intel suggesting software developers to write code in a way that is not vulnerable to side-channel attacks. Here's an excerpt from the Intel article: 'Developers who wish to protect secret data against timing side channel methods should ensure that their code runtime, data access patterns, and code access patterns are identical independent of secret values'.
"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."