News & Events

Daniel Genkin on Spectre and Meltown security flaws

January 17, 2018

On January 3rd 2018, a team of researchers including Dr. Daniel Genkin published Spectre Attacks: Exploiting Speculative Execution, as well as Meltdown, two notable papers that details security flaws in the world’s computer processors. The papers detail inherent security flaws in speculative execution, a technique used by virtually all modern processors to increase performance by guessing future paths of execution by executing them early. As speculative execution makes machines work faster and more efficiently, it is used in a variety of microprocessors from Intel, AMD, and ARM, which are used in billions of devices from laptops, to cell phones, to cloud service systems. Spectre and Meltdown detail how any unprivileged process (such as a Javascript ad running within the browser) running on the target device can read a victim’s confidential information, thereby breaking hardware and software isolation barriers. Genkin, a postdoctoral research fellow with Professor Jonathan Katz of the Maryland Cybersecurity Center (MC2), agreed to an interview about the work he did with a team of researchers from all over the world.

What exactly initiated this research? In other words, what are Spectre and Meltdown's origin stories?

The whole topic of microarchitectural attacks has been researched in the community for quite a while. What you see here is a number of ideas coming to fruition. Many side channel attack researchers have suspected various related issues for quite a while. I remember discussing some of these ideas with colleagues as far back as 2016, and I’m sure I was not the first. Of course, none of us actually knew how big the problem is.

As you have discovered this flaw in security using an attack that you've constructed, what are the chances that this or other "microarchitectural attacks" could actually happen in the wild? Particularly now that this flaw has been made eminently public?

It’s not only me, it’s a team effort, involving many people and a lot of work. I cannot speculate about the chances, especially since there are other attacks out there which are easier to exploit and are just as effective (e.g., getting information via phishing).

This flaw may have come at a hardware/software development phase of the Intel and AMD processors (among others) because teams who work on these parts of the processor may not be in conversation with each other. What do you suggest happen during the development of these processors now?

These teams are talking to each other when needed, in particular on security related topics. This is an industry-wide issue, and as such the entire industry comes up with ways to deal with it. The reason why we have this flaw is much deeper, and has nothing to do with miscommunications between teams. No one stopped to consider the effects of speculative execution of instructions on hardware security. It was widely believed that speculative execution had no security implications, and that belief turned out to be false.

In your paper, you mention that the KAISER patch, which can mitigate the Meltdown attack, does nothing for the Spectre attack. The next question is, what can be done?

Spectre is much harder to mitigate, and will take time to properly understand what the effects are, and how to defend against these attacks. There is no simple fix here.

Companies, including Google, have intimated that fixes to these flaws are easily executed. Is that true? If not, why not?

It is not easy, as any update involving millions of machines is never easy. That said, it is possible to make these attacks harder. Mitigating the issue completely will take some time, however.

What can a 'regular user' of computing devices do in the face of possibilities of these sorts of attacks?

Nothing besides making sure that you have installed the latest updates.

Do you plan on giving talks about this research in the immediate future?

I’m currently traveling in Israel and already gave a few talks here. As invitations come in, we distribute them in the team given availability.

Finally, tell me a little bit about yourself. What drew you to security research? When you decided to attend graduate school at the Technion, was that your original plan? What next lies in store for you?

I have enjoyed tinkering and fiddling with things all my life, and trying to see what can and cannot be done is something I simply like doing. Security research fits in with these goals as you are often trying to push the boundary of scientific knowledge. I’m also in debt to my advisors: Professors Eran Tromer (Tel Aviv University) and Yuval Ishai (Technion) for instilling within me the drive and pursuit of science. I should also thank my postdoc hosts Professor Jonathan Katz (UMD) and Professor Nadia Heninger (UPenn) for supporting me and providing a perfect working environment. I’m currently looking for a tenure-track academic position for next year.