Intel Inside? Our Experts Debate Threat in New Chip Flaw

Bob Gourley
Former Chief Technology Officer, Defense Intelligence Agency
Michael Sulmeyer
Director, Belfer Center's Cyber Security Project, Harvard University

Cybersecurity researchers have discovered two major software vulnerabilities in the Intel microprocessors inside the vast majority of all computers. Dubbed “Meltdown” and “Spectre,” the vulnerabilities could allow hackers to siphon off the entire memory contents of computers, mobile phones and servers that run on cloud networks.

Two Cipher Brief experts – Bob Gourley and Michael Sulmeyer – offered distinctly different takes in conversation with The Cipher Brief, adapted below.

Bob Gourley, former director of intelligence (J2) at DoD’s first operational cyber defense organization: Everything is vulnerable now. Everything.

New computer security vulnerabilities affect every modern computer chip. Here is what to do about it.

The vulnerabilities in computer chips publicly disclosed on Tuesday are unlike anything I have ever witnessed before. Researchers call these vulnerabilities “Spectre” and “Meltdown.” I call them a hot mess.

Here is why this is unique: This is a vulnerability in hardware design. There is a feature in all modern computer chips that helps speed up the processing and optimize performance. This feature is called “speculative execution.” Security researchers at Google’s Project Zero found that this feature, which is designed into the hardware itself, can be exploited in ways that give unauthorized users access to information in the system’s memory, including passwords and encryption keys. That can open up the entire system to an adversary who seeks to exploit it.

The vulnerability applies to personal computers, computers in data centers and the cloud, mobile devices and many embedded systems. It applies to many medical devices, transportation systems and infrastructure systems. It applies across our energy distribution infrastructure. It applies to every base, post, camp, station, ship and depot in the U.S. military. They are all vulnerable now.

The Google team are community minded players and began working with others soon after their discovery. This means that a larger team of security researchers have been working on this for quite a while. Patches are coming to operating systems to mitigate these risks. The patches should be out in a matter of days.

However, in most cases these patches are going to reduce the functionality of the computers they are installed on. Essentially what they are doing is turning off the great feature everyone wanted. The computers will be less functional.  Imagine having a computer that you bought and paid for now operating at 30 percent less capability. How much do you feel you should have paid for that computer now?

The time it takes between a vulnerability being disclosed and exploited is shrinking. The countdown clock has started. Patches must be provided, tested, deployed, and systems patched fast. We have to fix this or attacks will occur in ways we have never considered before.

Over the last 20 years, we have seen the security community come together to work many other big vulnerabilities. This is certainly not the first and won’t be the last. But it is the first I have ever seen that has such widespread damage potential. And it is the first that is going to cause so much degradation once put in place. The patches themselves will be like a self-inflicted wound that makes computers perform worse. This is ugly.

My recommendation:

  • Review all your processes for patching now. You are going to patch everything.
  • Review your IT budget. You may very well be buying new computers sooner vice later
  • Prepare to accelerate your cloud transition. This is yet another reason to move to the cloud, where you can take advantage of the great engineering of a well-managed service provider.

Michael Sulmeyer, the director of the Belfer Center’s Cyber Security Project at Harvard University, is less alarmed, seeing this as part of the push-pull of technological advantages, taking a step back before moving forward again.

What these two new security problems reveal are opportunities for hackers to gain access to a part of the memory in a computer that ordinarily they shouldn’t be able to touch, they shouldn’t be able to gain access to.

On a standard, standalone computer – if you are just working at your personal laptop – you as the administrator are supposed to be able to view your own memory. But part of the idea of cloud computing is that if you and I and 50 others are actually storing information and running processes on what is in effect one shared computer – otherwise known as the cloud – it is conceivable that I can start to access information that you have processed on your side, even though it is still part of the same computer, even though you and I are not sitting near each other and not dealing with each other. So that is why it is particularly worrisome in the cloud environment.

It is now a race. It is a race for the patching community to apply their patches – and my understanding is that patches are becoming available to address these vulnerabilities.

On the other side of the race are those who seek to exploit the vulnerabilities. Part of the reason why we try to have a coordinated disclosure policy is to give enterprises – like the government – time to patch before news like this hits. Intel was trying to coordinate this for release next week, but unfortunately it started to leak out so they sped everything up. But it does appear as if this was not a completely unknown problem, so there have been mitigations discussed, which they have been trying to put in place for some time.

It will be interesting to see if Intel decides to do a recall, and treat this more like a consumer products liability issue, or if they merely say that they will make sure that in future chips this won’t be an issue. The expectation needs to be that they treat this like the former – such as Toyota with airbags. They have put a product out into the marketplace that has been shown to have a pretty serious vulnerability. If you do that in another industry, you are on the hook. And even though we don’t have a lot of the regulatory and legal frameworks for chips specifically, the broader principles are all there. So the question is, how will it get applied to Intel and the chip manufacturers in this particular situation?

Part of the challenge is that we are dealing with decisions that were made years ago by chipmakers—not just Intel—that they were going to prioritize performance and speed above all else when it came to new chip design. And, as usual, security is left behind. So what we’re seeing now is a result of that. This is the tradeoff that we always talk about between performance and speed on the one hand, and security on the other. You get to a point of wondering how many more of these types of incidents do we need for hardware and software developers to really see the importance of putting security on equal footing?

To be clear, regulation is not necessary for software and hardware developers to prioritize security. They make a choice not to, and I think it’s really important that we realize there’s no structural reason these kinds of vulnerabilities must exist. They exist because corporate priorities are elsewhere, and the incentives to have the priority be on security are absent.

The only reason we start talking about regulation is because we wonder after 30 years of dealing with these kinds of issues, are companies really so unwilling to do this themselves that they’ll have to be forced to in order to keep the rest of us more secure? But there’s nothing about regulation in and of itself that is required for security. It’s rather that regulation may be one step to take to better motivate companies to prioritize security.

To some extent, it’s important to recognize here that the majority of types of incidents that we’re likely to still see won’t take advantage of vulnerabilities like this. This is a sophisticated vulnerability to exploit. It’s not impossible. But what you’d hate to see is the perpetuation of the argument that there’s no point having two-factor authentication, there’s no point in having reduced privileges for users – which are good, standard security practices – because of the existence of flaws like this. The reality is that most attackers, most of the time, are still going to use techniques that are much easier to exploit, because they still work.

The Author is Bob Gourley

Bob Gourley is founder of the technology due diligence consultancy Crucial Point, where he provides CTO services and cybersecurity assessments in support of M&A transactions. Bob’s first career was as a naval intelligence officer, which included operational tours in Europe and Asia. Bob was the Director of Intelligence (J2) at DoD’s first operational cyber defense organization JTF-CND. Following retirement from the Navy, Bob was an executive with TRW and Northrop Grumman, and then... Read More

The Coauthor is Michael Sulmeyer

Michael Sulmeyer is the Belfer Center's Cyber Security Project Director at the Harvard Kennedy School. He is also a Contributing Editor for Lawfare. Before Harvard, he served as the Director for Plans and Operations for Cyber Policy in the Office of the Secretary of Defense. There, he worked closely with the Joint Staff and Cyber Command on a variety of efforts to counter malicious cyber activity against U.S. and DoD interests. For this work, he received the Secretary Medal for Exceptional... Read More

Learn more about The Cipher Brief's Network here.


Share your point of view

Your comment will be posted pending moderator approval. No ad hominem attacks will be posted. Your email address will not be published. Required fields are marked *

2 Replies to “Intel Inside? Our Experts Debate Threat in New Chip Flaw”
  1. One point on regulation. A reason that it may not actually be relevant here is that the particular features of Intel processors that empower the meltpoint and Spectre vulnerabilities may have been created to provide other services and data processing characteristics that *favor-*security along with future-proofing. It seems incorrect to associate these issues narrowly with a trade off between security and speed. There is simply much more going on that that in architecture decisions governing Intel chip designs. Policy needs to catch up with that reality – and adopt much more sophistication and awareness regarding supply chain risks and “on-chip” feature exploitation — at scale. I doubt those who propose regulation are actually up to the challenge.

    1. David, I sure agree. That is a very important point to make. Just to add to the discussion, although chip design gets complex very fast, the old Sun Microsystems made a point of making their chip designs open. They published the chip designs. My gut tells me that this is helpful in spotting flaws before production. I wonder if that is true. These things are so very complex it might just be that this sort of flaw is to be expected periodically.