Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Morpheus Turns a CPU into a Rubik’s Cube to Defeat Hackers

spectrum.ieee.org

Post reply on HN
Print view View original

21–30 of 31 posts

Re: Morpheus Turns a CPU into a Rubik’s Cube to Defeat Hackers

#21

Post by bawolff »

joshka wrote: post #17
voldacar wrote: post #6

I'm a bit confused - how do you do pointer arithmetic if the cpu encrypts pointers for your automatically and doesn't let you know the actual address in memory that they point to?

I know nothing of the implementation, but hypothetically a compiler could translate: p++ to instructions that effectively do: p = enc(dec(p)+1) Without exposing p outside the CPU. The implementation described (seems to be) new instructions for incrementing and dereferencing pointers.

In which case, can't you just use it in your shell code? I guess the defense is info leaks are useless so you can't defeat aslr(?)

Re: Morpheus Turns a CPU into a Rubik’s Cube to Defeat Hackers

#22

Post by k_sze »

dejj wrote: post #2

> you change what it means to add a value to a pointer. Morpheus encrypts pointers. How does it allow C to access an array or a struct and prohibit access beyond bounds to the return address somewhere beyond the bounds of said array or struct, I wonder.

Maybe it uses homomorphic encryption?

Re: Morpheus Turns a CPU into a Rubik’s Cube to Defeat Hackers

#23

Post by k_sze »

dejj wrote: post #20
jstanley wrote: post #8

Earlier quoted context omitted.

Perhaps it could have pointer arithmetic instructions, where "ptr + n" makes code that uses special instructions to decrypt "ptr", add "n", and encrypt the result before giving it back to you?

Homomorphic encryption does that, yes. But in the interview, he talks about it hypothetically.

That’s not really homomorphic encryption, IIUC. In homomorphic encryption, you don’t even need decryption and re-encryption steps.

Re: Morpheus Turns a CPU into a Rubik’s Cube to Defeat Hackers

#24

Post by bawolff »

k_sze wrote: post #22
dejj wrote: post #2

> you change what it means to add a value to a pointer. Morpheus encrypts pointers. How does it allow C to access an array or a struct and prohibit access beyond bounds to the return address somewhere beyond the bounds of said array or struct, I wonder.

Maybe it uses homomorphic encryption?

That would be a much more impressive breakthrough if they did with only 10% overhead.

But it also is not a good match for the problem they are trying to solve (the attacker is not the cpu in this situation)

Re: Morpheus Turns a CPU into a Rubik’s Cube to Defeat Hackers

#25

Post by bawolff »

dejj wrote: post #20
jstanley wrote: post #8

Earlier quoted context omitted.

Perhaps it could have pointer arithmetic instructions, where "ptr + n" makes code that uses special instructions to decrypt "ptr", add "n", and encrypt the result before giving it back to you?

Homomorphic encryption does that, yes. But in the interview, he talks about it hypothetically.

Normal encryption does that. The entire point of Homomorphic encryption is that it does not do a decrypt step.

Re: Morpheus Turns a CPU into a Rubik’s Cube to Defeat Hackers

#26

Post by huonib »

teddyh wrote: post #3

> What is the overhead for Morpheus? > Todd Austin: It’s about 10 percent slower on average. If you accept that kind of overhead, why not just go the Burroughs B5000/Lisp Machine/etc. route and have a hardware instruction set which is essentially byte code for a safe machine, which cannot be tricked into reading and writing in arbitrary places. Of course, then you would still have the problem of actual security holes…

Are you talking about about both Burroughs B5000 and Lisp Machines having a tagged architecture[0]?

[0]: https://en.wikipedia.org/wiki/Tagged_architecture

Re: Morpheus Turns a CPU into a Rubik’s Cube to Defeat Hackers

#27

Post by teddyh »

huonib wrote: post #26
teddyh wrote: post #3

> What is the overhead for Morpheus? > Todd Austin: It’s about 10 percent slower on average. If you accept that kind of overhead, why not just go the Burroughs B5000/Lisp Machine/etc. route and have a hardware instruction set which is essentially byte code for a safe machine, which cannot be tricked into reading and writing in arbitrary places. Of course, then you would still have the problem of actual security holes…

Are you talking about about both Burroughs B5000 and Lisp Machines having a tagged architecture[0]? [0]: https://en.wikipedia.org/wiki/Tagged_architecture

Mostly, yes. But it’s not just tags, it’s the whole notion of a machine instruction set designed for post-von Neumann-architecture programming. I.e. the instruction set knows that there are such things as functions, objects, processes, users, etc. instead of the OS having to emulate all these things on top of an agnostic and uncaring machine code running on raw RAM.

Re: Morpheus Turns a CPU into a Rubik’s Cube to Defeat Hackers

#28

Post by kazinator »

voldacar wrote: post #6

I'm a bit confused - how do you do pointer arithmetic if the cpu encrypts pointers for your automatically and doesn't let you know the actual address in memory that they point to?

This is, from what I gather from the paper, because the pointers are not individually encrypted via cipher. Rather, pointers in the same domain (domains being identified via a tagging scheme) are all displaced together by a common value, which comes from that encryption engine. So imagine that some pointers p and q are actually p + c and q + c under the hood. When the machine churns, c will change, and so all pointers have to be updated. There is some sort of moving barrier which indicates which parts of memory are "clean" (ready for use) and which are still using the old key.

Re: Morpheus Turns a CPU into a Rubik’s Cube to Defeat Hackers

#29

Post by kazinator »

bawolff wrote: post #18

I wish this was more a technical paper. The interview tries to dumb it down to the point where you can't follow what they actually did, or what type of attacks are actually in scope. Is this just encrypting pointers, where the encryption key changes very frequently?

There is a technical paper; just that's not it.

Re: Morpheus Turns a CPU into a Rubik’s Cube to Defeat Hackers

#30

Post by joshka »

bawolff wrote: post #21
joshka wrote: post #17

Earlier quoted context omitted.

I know nothing of the implementation, but hypothetically a compiler could translate: p++ to instructions that effectively do: p = enc(dec(p)+1) Without exposing p outside the CPU. The implementation described (seems to be) new instructions for incrementing and dereferencing pointers.

In which case, can't you just use it in your shell code? I guess the defense is info leaks are useless so you can't defeat aslr(?)

(that should have read without disclosing dec(p))

But yeah, you'd have to end up with equivalents to p* = 123 which becomes (dec(p)* = 123 etc. My guess is that due to the simon cipher they're allocating full blocks whenever you do the safe version of malloc, and then do a range check to ensure that there is no overrun when storing / incrementing etc.

Post reply on HN