
Unhackable: New chip stops attacks before they start - jdmark
https://news.umich.edu/unhackable-new-chip-stops-attacks-before-they-start/
======
baroffoos
I was expecting something with a little more substance from an .edu domain.
This didn't really give much detail. Randomly storing data in memory is not a
new idea, this has been done for many years on game consoles to prevent people
reverse engineering raw memory/disc dumps.

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.

~~~
kdbg
I don't think they care about that type of attack, they specifically call out
control flow attacks.

From the abstract:

> Morpheus defenses offer strong protection against control-flow attacks

~~~
ungamedplayer
So, i get the concept of CF attacks, I just don't get how it can protect
against them when if valid applications need to look up memory locations, how
this would be different than current CF side-step attacks like ret2libc and
friends ?

~~~
ungamedplayer
I can't get the pdf due to lack of subscription or paying for a document that
likely will sidestep my questions anyway.

~~~
bigDICK
[https://sci-hub.tw/https://dl.acm.org/citation.cfm?doid=3297...](https://sci-
hub.tw/https://dl.acm.org/citation.cfm?doid=3297858.3304037)

------
baroffoos
I had a skim over the full PDF (Thanks scihub)

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.

------
whatamidoingyo
How to get free marketing for your product:

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)

------
nurettin
>> even if a hacker finds a bug, the information needed to exploit it vanishes
50 milliseconds later.

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.

~~~
turndown
I noticed that issue in the headline it had on reddit, why would an expert in
the subject think that 50 ms is so little time to a machine that _runs_ at 2-3
GHz...

------
yifanlu
The article is garbage so I skimmed the paper. Here's what I gleaned
(apologizes for any mistakes).

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.

~~~
olliej
So it sounds like it's CHERI-style, only "randomizing" things over time?

(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

------
Hello71
Abstract:

> 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.

------
jtl999
Glorified ASLR at runtime?

~~~
kdbg
That's how it reads. one important distinction is that it continually
randomizes itself not just one time like ASLR.

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.

------
kwccoin
The battle of sex in evolutionary game is precisely along this angle. Well it
is a better defense as the surface of attack change. But then the
virus/bacteria evolve as well. Just like firewall, it block a bit but all
attack now concentrate on html/click-bait/social ... all legitimate path.
Never unhackerable.

------
weld
This would only seem to protect from memory corruption vulnerabilities that
are exploited. I don't see how this would protect from the most common vulns:
SQLi, command injection, crypto implementation weaknesses, OWASP top 10. Would
this even protect against sensitive data leakage like the Heartbleed vuln?

------
nullc
This seems a lot less exciting than CHERI (
[https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/](https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/)
)

------
Yaa101
So now we will have buggy systems that defend themselfs, what ever could go
wrong here? What's next? giving laserguns to psychopaths?

