This is a fascinating topic, are there any practical real life implementations of this?
OpenBSD?
Synthetic Memory Protections: An update on ROP mitigations [pdf]
11–20 of 56 posts
Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]
#12The fact that you must trust programs to do the right thing is the root cause of the problem. There exist operating systems and security models that stop this type of attack dead in its tracts.
This is fallout from the failure of Multics, and the rise of Unix.
Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]
#13Earlier quoted context omitted.
no actually after 50 years of "how to shoehorn memory into something C can use" we reap the rewards
I'm wondering what an alternative model would look like, not oriented towards C.
One alternative CPU model were the various Lisp machines.
A really amazing example, though, was Intel's first 32 bit CPU, the iAPX 432 [1] -- it was actually object oriented. And it supported garbage collection (like Lisp machines).
It was kind of beautiful from one point of view, but it was absurdly impractical and complicated and slow. It was an extreme example of CISC, and the (simple and fast) RISC revolution killed off such things. Well, the iAPX killed itself, but...
Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]
#14> iOS is execute-only; Android tried a few years ago (abandoned) Wonder if the author is aware of the reasons why this was disabled (it's functionally gone on both platforms). On iOS newer processors have PAC which provides much stronger guarantees against ROP and Linux disabled it because execute-only mappings bypass PAN: https://blog.siguza.net/PAN/ . > Dumb applications that invent their own ABI (very few) I mean…
> Wonder if the author is aware of the reasons why this was disabled (it's functionally gone on both platforms). On iOS newer processors have PAC which provides much stronger guarantees against ROP and Linux disabled it because execute-only mappings bypass PAN: https://blog.siguza.net/PAN/.
Yes, of course he is. He even mentions PAN being broken in the recording. What doesn't make sense is the Android/Linux decision to entirely abandon execute-only. Let PAN be broken, newer chips will eventually fix it in hardware (EPAN) and older chips without PAN (notably, the Raspberry Pis) still get full protection.
Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]
#15Earlier quoted context omitted.
I'm wondering what an alternative model would look like, not oriented towards C.
Some of the 8-bit micros without many general purpose registers are relatively C unfriendly.
I've seen even those forced to C, with such gems I've run into like:
Link-time stack resolution(and aliased even, so pretty good density)
Default int is char. Please use short or ANSI int.(because 16-bit int would be painfully slow)
Recursion is not supported in this memory model(because the stack is resolved at link time, so...)
Function pointers must be compile-time resolvable(I think this machine didn't have a way to represent program counter values in GPRs/variable jumps)
"Function prototypes are an ANSI feature"(part of compiler the front-end also used on a bunch of UNIX box compilers).
Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]
#16Was lucky enough to watch this in person. One of the best talks of the conference.
The immutable bit together with the syscall bit is going to be a real pain for shell code
Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]
#17This is a fascinating topic, are there any practical real life implementations of this?
This presentation is an overview of many different mitigations spanning ~27 years. Some are quite widely implemented. I'm less familiar with the newer stuff, but here's some I've run into.
No-exec stacks: some UNIX machines, tons of systems today.
w^x: win xp+, Linux, several RTOS, OpenBSD, lots of others
aslr: requires MMU. OpenBSD, contemporary Windows(but partially opt in?), Linux.
X-only: Arm has supported X-only for their embedded stuff for a while, and it's fairly lightweight, though you lose PC-relative loads.
Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]
#18Earlier quoted context omitted.
Some of the 8-bit micros without many general purpose registers are relatively C unfriendly.
I've seen even those forced to C, with such gems I've run into like: Link-time stack resolution(and aliased even, so pretty good density) Default int is char. Please use short or ANSI int.(because 16-bit int would be painfully slow) Recursion is not supported in this memory model(because the stack is resolved at link time, so...) Function pointers must be compile-time resolvable(I think this machine didn't have a way…
Wow. Have you got a link? I hadn't heard about that. That's kind of a mind blowing list.
Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]
#19This looks really nice, I'll have to dig into it more later.
Always nice to see the OBSD team actually implementing protections and controls instead of relying on audits.
Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]
#20The fact that you must trust programs to do the right thing is the root cause of the problem. There exist operating systems and security models that stop this type of attack dead in its tracts. This is fallout from the failure of Multics, and the rise of Unix.
Could you please elaborate? One must trust programs that handle data to handle data, that requirement is difficult to get around.