Morpheus Turns a CPU Into a Rubik’s Cube to Defeat Hackers
University of Michigan’s Todd Austin explains how his team’s processor defeated every attack in DARPA’s hardware hacking challenge
Last summer, 580 cybersecurity researchers spent 13,000 hours trying to break into a new kind of processor. They all failed.
The hack attack was the first big test in a U.S. Defense Advanced Research Program Agency (DARPA) program called Security Integrated Through Hardware and firmware (SSITH). It’s aimed at developing processors that are inherently immune to whole classes of hardware vulnerabilities that can be exploited by malware. (Spectre and Meltdown are among those.)
A total of 10 vulnerabilities were uncovered among the five processors developed for SSITH, but none of those weak points were found in the University of Michigan processor, called Morpheus. Michigan professor of electrical engineering and computer science Todd Austin explained what makes Morpheus so puzzling for hackers to penetrate.
How Morpheus Works
IEEE Spectrum: What is Morpheus, essentially?
Spectrum: That does sound like a challenge. That sounds impossible, in a way.
Todd Austin: This is where the notion of undefined semantics comes in.
Spectrum: If you could define “undefined semantics” for us, that would be great.
Todd Austin: Think about driving a car: The defined semantics of your car are that it has a steering wheel; it has a left/right blinker; it may have a stick shift depending on the kind of car; it has as an on-off button. Once you know those basic features, you can drive your car. The undefined semantics are: Is it four cylinders or six cylinders? Does it run on diesel or electric? Does it have ABS braking or non-ABS braking? Attackers need to know all that underlying stuff, because they need to use that knowledge to step around the defenses. It is the telltale sign of an attack that it is dipping into the implementation details of a system.
Spectrum: So you can detect an attack just by looking at what’s being looked at?
Todd Austin: Yeah. Let me give you a classic example—the return stack. [When a program “calls” a subroutine into action, it stores the address the program should return to when the subroutine is over in the return stack.] This is a real popular place for attackers to manipulate to do what’s called a buffer overflow or a code injection. There’s only one part of the program that writes and reads from the return address, and that’s the beginning of a function and the end of a function. That’s really the semantics of the return address. But when you see a program attacking the return address to do code injection, for example, you’ll see writes from many different places in the program. So, these sort of unexpected, undefined accesses, normal programs never do. That’s a tell-tale sign that there is an attack going on. Now, some systems might try to detect that. And when they detect that, then they can kill the program. But that’s problematic, too, because things like operating systems and device drivers do some of this stuff, too.
So what we do instead is to make the underlying implementation of the machine—the undefined semantics—change every few hundred milliseconds. The underlying implementation will be so unique that you will never see the one that you’re on now again, ever, on any other machine in the future. It is completely unique in time and space.
Spectrum: There must be a lot of knobs to turn to be able to do that. [READ MORE]