[HN Gopher] Synthetic Memory Protections: An update on ROP mitig...
___________________________________________________________________
Synthetic Memory Protections: An update on ROP mitigations [pdf]
Author : notaplumber1
Score : 81 points
Date : 2023-03-25 14:09 UTC (8 hours ago)
(HTM) web link (www.openbsd.org)
(TXT) w3m dump (www.openbsd.org)
| Zurrrrr wrote:
| This 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.
| hvs wrote:
| It's amazed me that the first 50 years of computers were "this is
| how to structure memory for operating systems" and the next 30
| have been "hackers take advantage of all of that so we need to do
| a bunch of convoluted stuff just to try to thwart them." Kind of
| unfortunate that so much energy has to be spent on this work, but
| I appreciate that it is.
| rini17 wrote:
| no actually after 50 years of "how to shoehorn memory into
| something C can use" we reap the rewards
| pnm45678 wrote:
| perhaps it's time we stopped shoehorning memory to fit C and
| just used more memory-safe languages?
| ogogmad wrote:
| I'm wondering what an alternative model would look like, not
| oriented towards C.
| loeg wrote:
| Some of the 8-bit micros without many general purpose
| registers are relatively C unfriendly.
| rsaxvc wrote:
| 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).
| DougMerritt wrote:
| Wow. Have you got a link? I hadn't heard about that.
| That's kind of a mind blowing list.
| DougMerritt wrote:
| Ok, but they're not friendly _to_ anything but assembler.
|
| Well, since they typically have memory that cycles in the
| ballpark of instruction cycle times (unlike desktop and
| server CPUs where there's two orders of magnitude
| difference), that's friendly to Forth I suppose. But that
| is a small minority of usage even in those environments.
| It's more like Forth is friendly to slow architectures.
| :)
| DougMerritt wrote:
| 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...
|
| [1] https://en.wikipedia.org/wiki/Intel_iAPX_432
| IAmLiterallyAB wrote:
| 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
| notaplumber1 wrote:
| Dragos Ruiu (@dragosr) also provided the video recording on his
| Twitter account.
|
| https://twitter.com/dragosr/status/1639015014177841153
| Alifatisk wrote:
| This is a fascinating topic, are there any practical real life
| implementations of this?
| rsaxvc wrote:
| 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.
| mburee wrote:
| OpenBSD?
| saagarjha wrote:
| > 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 I know this is meant to be bait but I'll take it,
| applications that use their own internal ABI are valid programs.
|
| > On every kernel entry, if the RPKU register has been changed
| kill the process
|
| > When a process does a system call, the SP register MUST point
| to stack memory!
|
| Has https://xerub.github.io/ios/kpp/2017/04/13/tick-tock.html
| vibes
|
| > Stack and Syscall Protection detect a variety of easier exploit
| patterns, pushing the ROP programmer to explore more challenging
| schemes, which may not be viable
|
| > Increasing exploitation difficulty is a valid strategy
|
| Ok so this is the actual interesting part of the paper, because
| it seems like they are trying to shore up their syscall-origin
| protections which are not very strong in the presence on ROP,
| except trying to do so on hardware that doesn't really have CFI
| protections.
|
| As far as I can tell, this Xonly protection only attempts to
| disrupt blind ROP ("you can't read the code anymore"), rather
| than construction of a full ROP chain. There are some attempts to
| validate things on entry to the kernel (pc, sp) but they are
| under control of userspace so what probably will happen here is
| that they get switched back to sane values prior to kernel entry
| and then adjusted to attacker-controlled values again. I expect
| this to require some cleverness on the side of attackers but this
| is typically how such checks are bypassed, assuming that there is
| not some other overlooked way to get around it.
|
| This brings us to OpenBSD's strategy for exploit mitigation,
| which is in my eyes has far too much tunnel vision: it tries to
| match on individual exploit strategies, rather than trying to
| protect against more general problems. The policy of "let's make
| exploitation harder" is actually very close to something I'm
| working on right now and it has a number of important caveats
| that I don't see addressed here.
|
| These things are true:
|
| * Reducing the reliability of an exploit makes it far less
| attractive.
|
| * Adding non-perfect mitigations against common exploitation
| strategies makes it so that people can't just throw a proof-of-
| concept against another platform against your system.
|
| However, these are also true:
|
| * Attackers are very, very good at turning "we made this 99%
| secure!" into "this will basically never work".
|
| * Attackers will construct new strategies that you didn't think
| of to attack the same underlying problem if you don't fix it, if
| given adequate time.
|
| I am not an exploit author, so take this with a grain of salt,
| but I would guess that an experienced team could probably come up
| with a way to do either of the above in maybe a year. And at that
| point, once it's broken, the cost from the OpenBSD side to
| improve upon this protection is high, because they will break the
| entire design of this thing, which requires a human to revisit
| this and create a new clever design to keep attackers at bay. In
| that way it will become just a routine step in an exploit to
| evade the protection, as opposed to say NX, which completely
| killed the ability to ever do shellcode execution from the stack,
| necessitating the development of ROP over multiple years. Good
| mitigations are highly asymmetric in terms of effort required to
| design them versus how long an attacker needs to take to fully
| bypass them. Usually this means that if you're spending
| significant time designing something it will probably want to be
| sound rather than reducing the window of opportunity for an
| exploit.
| brynet wrote:
| > 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.
| mikewarot wrote:
| 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.
| ngneer wrote:
| Could you please elaborate? One must trust programs that handle
| data to handle data, that requirement is difficult to get
| around.
| Zurrrrr wrote:
| > 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).
___________________________________________________________________
(page generated 2023-03-25 23:00 UTC)