Unhackable: New chip stops attacks before they start
news.umich.edu
news.umich.edu
The "Unhackable" title is obvious clickbait and very easily proven wrong. Lets say you run nginx on this chip. You accidentally configure nginx so it is serving your config file on a route. The someone finds this out and breaks in by requesting that resource and then logs in to your server. No amount of memory shuffling will do anything about this unless nginx is totally broken every 50 milliseconds and in that case you may as well run your program on a rock from your back yard.
The only possible thing I see this fixing is when you have direct access to the memory at some kind of hardware level like if you have probes on the memory chip which can read and write but you don't have any way of accessing the memory mapping that allows programs to actually work on the chip.
From the abstract:
> Morpheus defenses offer strong protection against control-flow attacks
The core feature is Domain Tagging. The architecture adds 2 bits to data that define its 'domain' (code, code pointer, data, and data pointer). On its own this does nothing for security but it allows the churn unit to implement the two moving target defenses.
Pointer Displacement is the first moving target defense. It obscures pointer values by adding a random display to them and is domain dependent. So, the churn unit is able to find all code and data pointers and obfuscate them. Basically the same as encrypted pointers except they can be encrypted with a new key at run time.
Domain Encryption is the second moving target defense. It'll encrypt each domain with its own key. Details are sparse on how the encryption works, just the following quote:
> the domain encryption defense randomizes the representation of code, code pointers, and data pointers in memory using a strong cipher. These assets are encrypted in memory under their own distinct domain keys.
Both of these are actions performed by the churn unit which can be turned to run at a desired frequency or when certain rules are violated.
On the topic of rules, there are two types of rules the architecture enforces. ABORT and CHURN. Abort does the obvious and terminates the program, CHURN causes a re-randomization.
Aborts can be caused by:
- Attempting to execute anything not in the Code domain
- Use a Code data (not code pointer) in any instruction
- A jump target that isn't tagged as a Code Pointer
- A Load/Store address that isn't tagged as a Data Pointer
CHURNS can be caused by
- Performing an inter-domain comparison, the tags must match
- Any Code pointer arithmetic
- Any Data pointer arithmetic
- Any overflow occurs
- Invalid shift length (shifting by more bits than there are)
So on-to your question regarding ret2libc and friends. Basically, its an extra layer. A lot of attacks require that you leak some memory address (assuming ASLR is enabled) that is then used in the attack to, for example, craft a ROP or JOP chain. With pointer encryption you also need to leak the encryption key in order to craft a valid pointer.
Then you need to do so without causing violating an abort rule (shouldn't be too hard) and without violating a churn rule. The churn rules are potentially problematic as overflows are a common trick to getting certain values, and pointer arithmetic in general. As both cause churn that could invalidate the data you just leaked.
As for the root question of how can a valid application look up the memory, well its the architecture that decrypts the pointers/data in the architectures instructions (not adding new instructions like some pointer encryption implementations for example). So the program just needs the right pointer at run time, and the churn unit will rewrite them when it runs and changes the keys.
Honestly, it seems like a pretty solid mitigation for the types of attacks its designed to mitigate. An impossible barrier, I doubt it, without being hands on and trying to exploit it I can't speak with absolutes, but it certainly would be a challenge.
Though as many other have said, there are plenty of attacks it does nothing against but the paper is far more modest and accurate about the intent than the .edu post.
From what I can tell the researchers have found that many attacks on C code involve using undefined behavior or very rarely used features. For example out of bounds array access. They seem to have some system that is looking out for these things which normal programs almost never do
"Morpheus similarly makes use of tag checkingpolicies to provide additional security guarantees via itsattack detector. This detector watches for suspicious oper-ations that are indicative of ongoing attacks and responds inone of two ways: raising an exception or triggering a churncycle. Morpheus raises security exceptions on a few grievousoperations, listed under the “ABORT” rules"
It seems like this chip is purely focused on trying to make C code safer.
Step 1: claim it’s unhackable.
Step 2: wait for the InfoSec community to lose their shit & share it widely.
Step 3: wait for tech journalists to write a piece about it.
Step 4: goto step 1
Win.
(Borrowed from Azeria @Fox0x01 on Twitter)
What if the exploit runs in 25ms ? What about partial attacks like heartbleed ?
Just scrambling a bunch of registers is supposed give us a sense of security ? Eliminate CVE digests once and for all ? Doesn't sound very serious to me. Nice cube, though.
So they created a modified RISC-V architecture and added a tagging infrastructure. 64-bit registers become 66-bits. L1/L2 cache are expanded to hold 2 extra bits per qword, etc. In DRAM, every process gets a chunk of memory where all the tags are stored in one area. So for example, if your virtual address space is 32-bits then you have 2^32/64 * 2 bits of storage or ~16MiB of storage.
That's the storage overhead. Now, their architecture also does a sort of taint tracking. When you compile your C code with their modified llvm compiler, it outputs a 2-bit tag for every pointer. So every qword is tagged with "code pointer" "data pointer" or "data" or "code". When the processor operates on a qword, it propagates the tag. For example "pointer + data = pointer" and "pointer & data = data" for example. At any point in time, that tag storage in DRAM will also store if everything in memory is a code/data pointer or code or data.
Periodically, it will traverse through the tag storage and for every code pointer and data pointer it finds, it will obfuscate it (I think it can relocate stuff too). For code/data it can encrypt it. Of course because all this stuff is transparent to the program, there's no extra work for the developer. (E.g. if you load data from a pointer, it tracks that it's a piece of data and decrypts it transparently with a key that can be changed during the "churn"). It's very similar to GC.
They also detail some optimizations such as accounting for context switches during the "churn" process. And how to not have to keep the process halted while DRAM is being churned. They claim the performance impact isn't too bad but of course we'll have to see how it works with something like Chrome.
tl;dr: Basically from what I gathered, it's an architecture extension to RISC-V (it can be introduced to other archs as well) which tracks basic type information for all memory locations. Periodically, the system will transparently shuffle code and data around safely by using the type information. It's harder to exploit vulnerabilities because addresses and data keep changing around.
(no paper access for me)
e.g. let's say you went whole hog (E.g. 128bit CHERI 64bit pointer + 64bit metadata) and periodically traverses the heap and swizzles/reencrypts/whatever the meta data? Seems to assume that it can traverse the heap, but I'll ignore that for now
> Attacks often succeed by abusing the gap between programand machine-level semantics– for example, by locating asensitive pointer, exploiting a bug to overwrite this sensitivedata, and hijacking the victim program’s execution. In thiswork, we take secure system design on the offensive bycontinuously obfuscating information that attackers needbut normal programs do not use, such as representation ofcode and pointers or the exact location of code and data.Our secure hardware architecture, Morpheus, combines twopowerful protections: ensembles of moving target defensesand churn. Ensembles of moving target defenses randomizekey program values (e.g., relocating pointers and encryptingcode and pointers) which forces attackers to extensivelyprobe the system prior to an attack. To ensure attack probesfail, the architecture incorporates churn to transparently re-randomize program values underneath the running system.With frequent churn, systems quickly become impracticallydifficult to penetrate.We demonstrate Morpheus through a RISC-V-based pro-totype designed to stop control-flow attacks. Each moving target defense in Morpheus uses hardware support to indi-vidually offer more randomness at a lower cost than pre-vious techniques. When ensembled with churn, Morpheusdefenses offer strong protection against control-flow attacks,with our security testing and performance studies revealing:i)high-coverage protection for a broad array of control-flowattacks, including protections for advanced attacks and anattack disclosed after the design of Morpheus, andii)neg-ligible performance impacts (1%) with churn periods up to50 ms, which our study estimates to be at least 5000x fasterthan the time necessary to possibly penetrate Morpheus.
Without access to the paper it's hard to say how granular the randomization is, and what is static. It's apparently transparent to software but there needs to be some source of relative location information that can be accessed.
It also mentions detecting imminent attacks and increasing randomization rates.