15 ms·

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

96 points by notaplumber1 3y ago

notaplumber1 3y ago
Dragos Ruiu (@dragosr) also provided the video recording on his Twitter account. https://twitter.com/dragosr/status/1639015014177841153 https://twitter.com/dragosr/status/1639015014177841153
hvs 3y ago
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 3y ago
  no actually after 50 years of "how to shoehorn memory into something C can use" we reap the rewards
  - ogogmad 3y ago
    I'm wondering what an alternative model would look like, not oriented towards C.
    - loeg 3y ago
      Some of the 8-bit micros without many general purpose registers are relatively C unfriendly.
      - DougMerritt 3y ago
        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. :)
      - rsaxvc 3y ago
        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 3y ago
        Wow. Have you got a link? I hadn't heard about that. That's kind of a mind blowing list.
        rsaxvc 3y ago
        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-mcu-family-user-guide-stmicroelectronics.pdf 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 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.
    - DougMerritt 3y ago
      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 https://en.wikipedia.org/wiki/Intel_iAPX_432
    - gumby 3y ago
      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
  - pnm45678 3y ago
    perhaps it's time we stopped shoehorning memory to fit C and just used more memory-safe languages?
    - anthk 3y ago
      Multics had both. It's the Unix inspiration. Imagine something more secure and with a better hardware design than Unix.
saagarjha 3y ago
> 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/ 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 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.
Alifatisk 3y ago
This is a fascinating topic, are there any practical real life implementations of this?
- mburee 3y ago
  OpenBSD?
  - t-3 3y ago
    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).
    - tete 3y ago
      April being the best guess currently, though end of likely, because May 1st is the usual goal. The best guess being April, because it's what the (non-finished) 7.3 page says for the month right now. Of course that's not a guarantee, but it makes it likely. Also a branch of 7.3 already exists.
- rsaxvc 3y ago
  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.
mikewarot 3y ago
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 3y ago
  Could you please elaborate? One must trust programs that handle data to handle data, that requirement is difficult to get around.
  - muyuu 3y ago
    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.
    - ngneer 3y ago
      Precisely! We need to structure programs so as to behave within a well defined transitive data closure.
  - mikewarot 3y ago
    First let me offer an analogy What would the use of electricity be like without circuit breakers? You'd have to carefully and completely vet each new device you wanted to connect to your house, and make sure that you weren't going to burn the wires up, or even take down the power grid. (AKA the power in the 1960s TV show Green Acres) With circuit breakers, you carefully limit the availability of current to loads, and protect the wiring inside the house from many forms of trouble. -- When you run a program on a PC, by default it runs with all of your credentials. There's nothing stopping it from ANY side effects. You're restricted to carefully considering each piece of software, and hoping it doesn't take your system down, or worse. A system that specifies at/during runtime what resources a program is allowed to access and how (via capabilities) can't be subverted to reach outside those restrictions, no matter how clever or confused the program gets.
IAmLiterallyAB 3y ago
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
- itsokimbatman 3y ago
  This is literally going to be a minor annoyance at most for the handful of attackers that go after OpenBSD.
  - anthk 3y ago
    Today even doing something outside the syscalls is not allowed.
    - saagarjha 3y ago
      Which syscalls?
Zurrrrr 3y ago
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.
itsokimbatman 3y ago
Honestly the only thing that really needs to be said: https://nso.group/@qwertyoruiop/110086216898968720 https://nso.group/@qwertyoruiop/110086216898968720
- matrix12 3y ago
  Are there any real CTF's done against OpenBSD to present this evidence?
  - itsokimbatman 3y ago
    Not that I'm aware of, but as someone who works in security, I've exploited a bunch of bugs against real world, hard targets both for my own educational purposes and also as part of my job with client engagements. I'm not going to pretend I'm the best in the world, but I'm decent. More importantly, I know a lot of folks with hats of many colors who are a lot better than I am. When Luca Todesco (the person who wrote that toot) tells you your exploit mitigations are trash, you listen. Like I said, I'm not going to make any claims to being an elite hacker. I have a cool job that I love, and I enjoy doing this stuff for fun too to keep my skills sharp. But reading through that presentation, there's nothing that made me pause and think "This is a game over scenario." If you have a moderately powerful bug with halfway decent primitives these mitigations aren't really going to stop anyone. An elite team like NSO group? This isn't going to effect them one bit.
    - anthk 3y ago
      If you think Theo and co. are newcomers to security, y'all gonna have a bad time. You and the NSO group.
- blacklion 3y ago
  Could you explain what does "boomer" means here? I think I understand "Ok, boomer" in general but can not extrapolate this understanding to security talk.
  - 3y ago

96 points by notaplumber1 3y ago

Dragos Ruiu (@dragosr) also provided the video recording on his Twitter account. https://twitter.com/dragosr/status/1639015014177841153 https://twitter.com/dragosr/status/1639015014177841153

hvs 3y ago

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 3y ago
no actually after 50 years of "how to shoehorn memory into something C can use" we reap the rewards
- ogogmad 3y ago
  I'm wondering what an alternative model would look like, not oriented towards C.
  - loeg 3y ago
    Some of the 8-bit micros without many general purpose registers are relatively C unfriendly.
    - DougMerritt 3y ago
      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. :)
    - rsaxvc 3y ago
      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 3y ago
        Wow. Have you got a link? I hadn't heard about that. That's kind of a mind blowing list.
        rsaxvc 3y ago
        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-mcu-family-user-guide-stmicroelectronics.pdf 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 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.
  - DougMerritt 3y ago
    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 https://en.wikipedia.org/wiki/Intel_iAPX_432
  - gumby 3y ago
    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
- pnm45678 3y ago
  perhaps it's time we stopped shoehorning memory to fit C and just used more memory-safe languages?
  - anthk 3y ago
    Multics had both. It's the Unix inspiration. Imagine something more secure and with a better hardware design than Unix.

saagarjha 3y ago

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

Alifatisk 3y ago

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

mburee 3y ago
OpenBSD?
- t-3 3y ago
  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).
  - tete 3y ago
    April being the best guess currently, though end of likely, because May 1st is the usual goal. The best guess being April, because it's what the (non-finished) 7.3 page says for the month right now. Of course that's not a guarantee, but it makes it likely. Also a branch of 7.3 already exists.
rsaxvc 3y ago
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.

mikewarot 3y ago

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 3y ago
Could you please elaborate? One must trust programs that handle data to handle data, that requirement is difficult to get around.
- muyuu 3y ago
  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.
  - ngneer 3y ago
    Precisely! We need to structure programs so as to behave within a well defined transitive data closure.
- mikewarot 3y ago
  First let me offer an analogy What would the use of electricity be like without circuit breakers? You'd have to carefully and completely vet each new device you wanted to connect to your house, and make sure that you weren't going to burn the wires up, or even take down the power grid. (AKA the power in the 1960s TV show Green Acres) With circuit breakers, you carefully limit the availability of current to loads, and protect the wiring inside the house from many forms of trouble. -- When you run a program on a PC, by default it runs with all of your credentials. There's nothing stopping it from ANY side effects. You're restricted to carefully considering each piece of software, and hoping it doesn't take your system down, or worse. A system that specifies at/during runtime what resources a program is allowed to access and how (via capabilities) can't be subverted to reach outside those restrictions, no matter how clever or confused the program gets.

IAmLiterallyAB 3y ago

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

itsokimbatman 3y ago
This is literally going to be a minor annoyance at most for the handful of attackers that go after OpenBSD.
- anthk 3y ago
  Today even doing something outside the syscalls is not allowed.
  - saagarjha 3y ago
    Which syscalls?

Zurrrrr 3y ago

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.

itsokimbatman 3y ago

Honestly the only thing that really needs to be said: https://nso.group/@qwertyoruiop/110086216898968720 https://nso.group/@qwertyoruiop/110086216898968720

matrix12 3y ago
Are there any real CTF's done against OpenBSD to present this evidence?
- itsokimbatman 3y ago
  Not that I'm aware of, but as someone who works in security, I've exploited a bunch of bugs against real world, hard targets both for my own educational purposes and also as part of my job with client engagements. I'm not going to pretend I'm the best in the world, but I'm decent. More importantly, I know a lot of folks with hats of many colors who are a lot better than I am. When Luca Todesco (the person who wrote that toot) tells you your exploit mitigations are trash, you listen. Like I said, I'm not going to make any claims to being an elite hacker. I have a cool job that I love, and I enjoy doing this stuff for fun too to keep my skills sharp. But reading through that presentation, there's nothing that made me pause and think "This is a game over scenario." If you have a moderately powerful bug with halfway decent primitives these mitigations aren't really going to stop anyone. An elite team like NSO group? This isn't going to effect them one bit.
  - anthk 3y ago
    If you think Theo and co. are newcomers to security, y'all gonna have a bad time. You and the NSO group.
blacklion 3y ago
Could you explain what does "boomer" means here? I think I understand "Ok, boomer" in general but can not extrapolate this understanding to security talk.
- 3y ago