Live data from Hacker News

Synthetic Memory Protections: An update on ROP mitigations [pdf]

openbsd.org

21–30 of 56 posts

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#21

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

> The fact that you must trust programs to do the right thing is the root cause of the problem.

Well, yeah, that's the issue. That's why relying on simple DAC is so inadequate. Really, some kind of MAC is needed. Things like pledge and unveil are nice but clearly inadequate (I actually had a pretty braindead discussion on that recently, with someone not understanding the differences and trying to equate them out of ignorance, sigh).

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#22

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

The Xonly stuff they talk about is so weird to me, because almost no one cares about exfiltrating assembly for dynamic ROP creation or whatever? Even if you are doing fingerprinting of binaries to pick an exploit version, you do that with a stack leak for return addresses to get relative offsets for a ROP or figure out a version. If someone is doing a ROP for an exploit they probably already have a built ROP chain to use with it!

Execute-only makes more sense for kernel exploits, and especially for the BSDs that do extremely aggressive per-codeunit kASLR at startup, but the fact Android dropped it should make you double think how worthwhile it is.

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#23
post #5
post #4

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

Some real world examples I have used:

Harvard architecture machines (which are not uncommon in microcontrollers)

Segmented memory, or any non-flat memory

Addressable memory with non-uniform access time (cache doesn't count because cache lines can't be addressed directly)

Address spaces not a factor of 2. Variable byte sizes ("byte" did not mean "8 bits" until the 360, and even in those days, just in the IBM world)

Word length larger than address length.

Some hardware-tagged architectures.

Machines with hardware-supported transporting GCs.

Different regions of memory that are architecturally distinct (shared memory with machines of different architectures, which these days can mean GPUs).

And one I haven't used yet:

distributed-computation-in-RAM

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#24
post #11

This is a fascinating topic, are there any practical real life implementations of this?

OpenBSD?

It's worth noting that the new mitigations discussed in the talk are only available in -current. They'll be in the next release though (which should be coming in the next few months).

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#26

Was 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

This is literally going to be a minor annoyance at most for the handful of attackers that go after OpenBSD.

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#28
post #20

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

Ideally, the scope of failure to do with the data what they should do, would be bounded. In reality, programmes asked to handle some data can fail to do the expected handling and produce undetermined side-effects.

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#29
post #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…

I suspect (though have no special knowledge) that the reason it's still off is that it just wasn't that valuable.

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#30
post #15

Earlier quoted context omitted.

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.

I think most of these solutions probably predate 8051 and ST7 cores(which both have stack pointers) where I ran into them but reduced memory models are still pretty useful for them, due to the overhead vs RAM usually fitted. It's too late to edit my comment. I'll mostly discuss the fallout from static stack variable allocation.

From https://www.st.com/resource/en/user_manual/um0015-st7-8bit-m... (8.3.5 Limitations put on the full implementation of C language)(I think this is talking about Hicross C, but COSMIC and Raisonance work the same depending on stack memory model): The ST7 family provides a limited RAM size, of which the stack takes only a part, that can be as small as 64 bytes. This does not allow the use of the stack for parameter passing. Thus, the implementation of C for the ST7 uses registers and a few memory locations to pass the parameters, and allocates local variables to RAM just like global variables. This works the same way as in a typical implementation, but with the following restrictions...

You can still get an evaluation copy of COSMIC C and try this out. Here I made a function call itself void port_init(void){port_init();}. Note that this error comes from the linker, clnk, not the compiler, because the linker is responsible for stack allocation globally, as described above): #error clnk vumeter.lkf:1 function _port_init is recursive.

There's a similar error if you call a function from anything called from main() and also from any interrupt entry point. This is because the memory model isn't re-entrant, so calling the same function from >1 path can cause them to overlap, corrupting their staticly allocated variables.

https://www.cosmicsoftware.com/pdf/RX.pdf has an explanation for "is recursive" and "is reentrant".

COMSIC C will also let you compile enum {x = x}, but I don't know what value x gets.

Post reply on HN