How a bad microcode fix could brick billions of chips

Cryptographer Adi Shamir is worried that billions of microprocessors could be irreversibly bricked in future by a microcode update gone wrong.

Shamir - the ‘S’ in the RSA public key cryptosystem, and a computer science professor at the Weizmann Institute of Science in Israel - shared his concerns about how chipmakers are trying to patch hardware flaws at the RSA Conference overnight.

Already, there have been patches and “patches of patches” released by companies trying to work around the Spectre and Meltdown flaws disclosed earlier this year.

Some of the mitigations involve updates to the microcode - or firmware - that runs on the processors. Intel and AMD have released several sets of updates over the past few months.

But Shamir is worried that continuing to “play with the microcode” in this way could lead to a large-scale breakage in future.

“I’m worried we’ll get to the point at which billions of microprocessors are going to be bricked, and this will become irreversible,” he said.

“If you have a problem in software, you usually reinstall the operating system and everything is OK.

“But if you play with the microcode on the microprocessor there is a real possibility that there will be a huge disaster.”

Security researcher Paul Kocher, who was one of two people to independently find the Spectre chip flaws, said that the fallout of the CPU bugs is “still a pretty big mess” of “partial mitigations”.

However, he noted that hardware flaws still represented a relatively small proportion of security problems overall.

“In terms of looking at the risk in context, we have this giant problem with software bugs and while this particular hardware bug [Spectre] is interesting from a computer science perspective, it’s not a [case of] ‘go run for the hills because of this’,” he said.

Still, he saw plenty of room for hardware designs and devices to be hardened from a security perspective.

“I think better hardware is something that people are putting a lot more resources into and I’m optimistic that we can start getting some components where the probability of failure is low,” Kocher said.

“We’ve had it with cryptography for a while [where] the chance that AES256 will get broken in the next year is almost negligibly small in terms of a practical attack.

“We need to have more things than just the crypto algorithms that have this high probability of being robust.”

Part of the change process in that regard was to challenge and overturn legacy thinking on hardware design, he said.

“A lot of what I’ve been looking at over the past year involves trying to understand performance-security trade-offs,” Kocher told the conference.

“There’s been this idea in the technology industry that we can have this kind of ‘Goldilocks’ solution where we can have speed and safety at the same time, and I’m getting more pessimistic about that perspective.

“If I look at processors, operating systems, compilers and development methodologies, these things have all been optimised over the past 50 years to be as fast as possible with security as really a secondary objective.

“There’s also a cultural shift that I’ve been looking to try to figure out how to create, which is that the leadership in the technology industry all made our careers in an era where all of the value gains came from being faster and everything else was secondary.

“But now the economic importance of the issues has shifted. Security is a multi-trillion dollar problem. The value we get from performance gains is a rounding error compared to that.

“So I think we have to go back and revisit a lot of these choices we’ve made.”

Hardware embargoes

Kocher also outlined a need to refine the way future hardware flaws are disclosed in order to allow all parties involved enough time to mitigate against them.

He said that while the embargo process for dealing with software bugs was well understood and adhered to, “the embargo process for hardware bugs is something that we don’t know how to do”.

Part of the issue with hardware flaws is that so many parties potentially need to be brought into the loop on the discovery of a vulnerability.

“I’ve got a huge number of emails from people who were unhappy that I didn’t tell them [about Spectre],” Kocher said.

This was despite the fact that, in the case of Meltdown and Spectre, “more people were told than could keep a secret”, causing researchers to break the embargo early.

“Press leaks ultimately ended up in a panicked end to the embargo,” he said.

“You don’t want to be in a situation where the attackers have enough information to mount attacks and the defenders don’t know what’s going on, so... the decision was made to release the embargo early.”

Kocher said a similar situation happened when he uncovered a side-channel attack that impacted cryptographic hardware devices, with the embargo also broken early.

“So I don’t know what to do in that kind of situation, having basically failed twice with that kind of embargo [for hardware flaws],” he said.

“I think we need some ethicists and people thinking about what to do in these situations now because there are going to be more of these things.

“There are a lot of problems we have in systems that can’t be updated easily and as more of these vulnerabilities come out we need a roadmap of what to do.”