5 ms·

mimmutable() for OpenBSD

112 points by signa11 4y ago

bawolff 4y ago
Im not a c programmer or otherwise work this low level, so im probably missing something obvious. What is the point of making something immutable if you can just create a new write-exec region? Surely if you have enough control over the process to change permissions on an existing memory segment you have enough to mmap a new region with the permissions you want?
- charcircuit 4y ago
  >What is the point of making something immutable if you can just create a new write-exec region? You aren't the only thing using the memory. If you create a new region only you will be the one using it.
- saagarjha 4y ago
  No, you're not missing anything. The primary reason this thing was designed was so try to patch out some holes in another unusual "mitigation", where system calls are checked to make sure they come from OpenBSD's libc. In this case adding new pages with syscalls in them would not work, but it seems like Theo read a paper at some point where they mprotected libc and patched its code and this spooked him into realizing that if you can mprotect libc itself this address range could be rewritten to contain attacker-controlled code, and make syscalls, which would break msyscall. So mimmutable prevents an attacker from ever remapping those pages, so they can never modify them even with mprotect. Of course, msyscall itself is a weak mitigation, because an attacker can (as you mentioned) allocate another page with arbitrary code in it save for the syscall instruction, construct a call state with it, and then jump to any syscall instruction in libc. So this doesn't protect against much, anyways. mimmutable itself is not really a dud, it's just not that great if you try to layer it on top of something already useless. It's great if you want to make sure a page (of data, usually) really stays immutable. But using it to prevent the introduction of new code is not all that effective, unless you are far more stringent about how you allow processes to allocate executable regions. For example, if you prevent a program from mapping in any new PROT_EXEC pages after it's initialized itself and then mimmutable all its code, then no new code can be introduced, which is a useful property. But you need that extra bit which mimmutable by itself doesn't give you. (FWIW, macOS already has something similar to this called VM_FLAGS_PERMANENT, which prevents a mapping from being removed. This, together with the maximum protection on a mapping, can be used to prevent a region from ever gaining a certain permission. I believe you can reduce it to PROT_NONE though.)
  - notaplumber1 4y ago
    > But using it to prevent the introduction of new code is not all that effective, unless you are far more stringent about how you allow processes to allocate executable regions. For example, if you prevent a program from mapping in any new PROT_EXEC pages after it's initialized itself and then mimmutable all its code, then no new code can be introduced, which is a useful property. But you need that extra bit which mimmutable by itself doesn't give you. You mean like pledge(2)? The vast majority of the base system is pledged. So programs without the prot_exec promise cannot make new PROT_EXEC mappings, or add it to any existing pages. https://man.openbsd.org/pledge#prot_exec https://man.openbsd.org/pledge#prot_exec Perhaps you should spend more than 5 minutes reading about OpenBSD's layers of mitigations.
    - saagarjha 4y ago
      I think your comment would stand on its own better if it didn’t include the last line, both before and after you edited it. I do actually read up on what other OSes are doing, you know. And I look at what attackers target. What you’re missing here is the actual threat model this is supposed to protect against, and how this doesn’t actually work to protect against it, despite using building blocks that are “valid” in the sense that they can be used to build other, legitimate mitigations. pledge is a good mitigation by itself. It’s a great way to sandbox things, and solve the problem of “this process no longer has any need to do these operations, so let’s just remove its capabilities to do that”. If you use it correctly it’s one of the strongest ways to make your program secure. mimmutable by itself can be used to force a mapping to remain non-writable. This can be valuable because if you make the code that reads from that data also immutable, you know it will always read the same data, regardless of what an attacker can do in your address space. That is also a useful thing to have in certain cases. If you read the thread where mimmutable was introduced you can see that the primary usecase proposed by Theo is to shore up msyscall. The threat model he has in mind is an attacker who can mprotect libc to be writable, which if I remember correctly was some minor detail of a Linux writeup once. However, there are several problems here. One is that mimmutable by itself doesn’t actually fix the problem here because of the concern brought up at the top of this thread. You will note that the thing you quoted practically screams “but what if there was a way to prevent new executable mappings?” I actually did this intentionally, with full knowledge of how you can use pledge to do this. I think it is important for people who are not security experts to be able to follow the thinking that goes into analyzing these things, and be able to synthesize the usecase I mentioned at the start of this comment for themselves. You will still note that I called msyscall weak in my original comment, and it still remains weak even after mimmutable+pledge is implemented. As others have mentioned as well using ROP to jump to the syscall instructions in libc with your own arguments (it’s not special…) bypasses restrictions in the current design. In fact I can extend it with something OpenBSD does not have a good implementation of yet, strong CFI, which would prevent jumping into the middle of a function to execute that syscall instruction. But there are more fundamental reasons why this doesn’t work. Protecting certain “sensitive” operations is actually something you can do. PPL as I mentioned below does this. It’s built on top of strong CFI (PAC) and code integrity guarantees (KTRR), which we are assuming you can construct in userspace on OpenBSD. The difference is that PPL has a tiny surface, and OpenBSD’s libc has a large one. In practice this means that libc cannot actually tell whether a request coming from an application is legitimate or not. If you look at the threat model for mimmutable again, consider that it assumes an attacker has enough control to call mprotect with controlled arguments: this means they know the layout of the address space and they can subvert control flow. With this kind of control, it’s not that hard to just decide to do other system calls instead. And who needs a syscall for that? You can literally just call the libc function which is a wrapper around the syscall. How is it to know that my call to write is malicious and the seven thousand the program already made was not?
ggm 4y ago
Can't stop the instruction set being able to write. Can stop higher logic invoking them, sometimes. Good to do. I really like the level of integration with compiler, low level boot, trusted code regions, "you will almost never call this, but your OS might on your behalf" Live patching un-stoppable systems may be a challenge unless you code to passing live IO and state across process boundaries
Sirened 4y ago
>One of those marks executable memory that is empowered to call into the kernel; on OpenBSD systems, only the C library is given that capability. That will prevent hostile code loaded elsewhere from making direct system calls; protecting the rest of a process with mimmutable() will prevent the changing of protections to allow system calls from elsewhere (such changes would be done with msyscall() on OpenBSD). This is, unfortunately, a continuation of OpenBSD's long tradition of security "mitigations" that are entirely detached from any actual understanding of exploitation [1]. The above suggestion that attackers can no longer make syscalls from their shellcode, while ostensibly true, is moot because you can simply JOP to one of the authorized syscall instructions and entirely defeat the mitigation. Even if mimutable outright prevented any new code from being mapped, this still wouldn't really stop anyone; just look at iOS where attackers have thrived despite there only being one process on the entire OS which is able to map arbitrary code. > Whenever a process enters the kernel, its stack pointer is checked to see whether it is, indeed, pointing into a stack region; if not, the process is killed. This too is trivially defeated. You simply need to add another stage to your payload in which you copy your ROP payload onto the legitimate stack, pivot, and continue executing. If you managed to pivot off the original stack, you already have a pivot gadget and so you only then need to trigger a call to memcpy. This mitigation isn't stopping any real attacker. While I never hope to discourage kernel developers from thinking about security mitigations, I think it is really important that people working on these mitigations actually converse with people who write exploits. Other vendors have seen considerable success with their mitigations [2] in that they specifically target things that attackers need and want to do, such as heap spray. [1] See: ROP gadget elimination, a feature which does not actually stop ROP but merely hopes that "a substantial reduction of gadgets is powerful." <https://marc.info/?l=openbsd-tech&m=150317547021396&w=2 https://marc.info/?l=openbsd-tech&m=150317547021396&w=2>. Speaking from experience and having written plenty of actual exploits on attacker hostile platforms, trying to block code execution against an attacker who already has kernel read/write is an utterly ridiculous idea because even if you manage to stamp out every single ROP gadget, they can just go and stomp on your kernel page tables to map new kernel code. Even baring that, kernel R/W is still a complete compromise even if kernel code execution is somehow impossible because you can still just use R/W to bypass any control the kernel could ever hope to enforce. [2] Life and death of an iOS attacker by Luca Todesco <https://www.youtube.com/watch?v=8mQAYeozl5I https://www.youtube.com/watch?v=8mQAYeozl5I>, a discussion of exploit mitigations on iOS and the exponential cost of defeating mitigations on iOS. Luca's company writes exploits for iOS devices as a service and he is extremely knowledgable in this area.
beachhead 4y ago
someone show us bypasses for all these mitigations that don't mitigate anything please

112 points by signa11 4y ago

Im not a c programmer or otherwise work this low level, so im probably missing something obvious. What is the point of making something immutable if you can just create a new write-exec region? Surely if you have enough control over the process to change permissions on an existing memory segment you have enough to mmap a new region with the permissions you want?

charcircuit 4y ago
>What is the point of making something immutable if you can just create a new write-exec region? You aren't the only thing using the memory. If you create a new region only you will be the one using it.
saagarjha 4y ago
No, you're not missing anything. The primary reason this thing was designed was so try to patch out some holes in another unusual "mitigation", where system calls are checked to make sure they come from OpenBSD's libc. In this case adding new pages with syscalls in them would not work, but it seems like Theo read a paper at some point where they mprotected libc and patched its code and this spooked him into realizing that if you can mprotect libc itself this address range could be rewritten to contain attacker-controlled code, and make syscalls, which would break msyscall. So mimmutable prevents an attacker from ever remapping those pages, so they can never modify them even with mprotect. Of course, msyscall itself is a weak mitigation, because an attacker can (as you mentioned) allocate another page with arbitrary code in it save for the syscall instruction, construct a call state with it, and then jump to any syscall instruction in libc. So this doesn't protect against much, anyways. mimmutable itself is not really a dud, it's just not that great if you try to layer it on top of something already useless. It's great if you want to make sure a page (of data, usually) really stays immutable. But using it to prevent the introduction of new code is not all that effective, unless you are far more stringent about how you allow processes to allocate executable regions. For example, if you prevent a program from mapping in any new PROT_EXEC pages after it's initialized itself and then mimmutable all its code, then no new code can be introduced, which is a useful property. But you need that extra bit which mimmutable by itself doesn't give you. (FWIW, macOS already has something similar to this called VM_FLAGS_PERMANENT, which prevents a mapping from being removed. This, together with the maximum protection on a mapping, can be used to prevent a region from ever gaining a certain permission. I believe you can reduce it to PROT_NONE though.)
- notaplumber1 4y ago
  > But using it to prevent the introduction of new code is not all that effective, unless you are far more stringent about how you allow processes to allocate executable regions. For example, if you prevent a program from mapping in any new PROT_EXEC pages after it's initialized itself and then mimmutable all its code, then no new code can be introduced, which is a useful property. But you need that extra bit which mimmutable by itself doesn't give you. You mean like pledge(2)? The vast majority of the base system is pledged. So programs without the prot_exec promise cannot make new PROT_EXEC mappings, or add it to any existing pages. https://man.openbsd.org/pledge#prot_exec https://man.openbsd.org/pledge#prot_exec Perhaps you should spend more than 5 minutes reading about OpenBSD's layers of mitigations.
  - saagarjha 4y ago
    I think your comment would stand on its own better if it didn’t include the last line, both before and after you edited it. I do actually read up on what other OSes are doing, you know. And I look at what attackers target. What you’re missing here is the actual threat model this is supposed to protect against, and how this doesn’t actually work to protect against it, despite using building blocks that are “valid” in the sense that they can be used to build other, legitimate mitigations. pledge is a good mitigation by itself. It’s a great way to sandbox things, and solve the problem of “this process no longer has any need to do these operations, so let’s just remove its capabilities to do that”. If you use it correctly it’s one of the strongest ways to make your program secure. mimmutable by itself can be used to force a mapping to remain non-writable. This can be valuable because if you make the code that reads from that data also immutable, you know it will always read the same data, regardless of what an attacker can do in your address space. That is also a useful thing to have in certain cases. If you read the thread where mimmutable was introduced you can see that the primary usecase proposed by Theo is to shore up msyscall. The threat model he has in mind is an attacker who can mprotect libc to be writable, which if I remember correctly was some minor detail of a Linux writeup once. However, there are several problems here. One is that mimmutable by itself doesn’t actually fix the problem here because of the concern brought up at the top of this thread. You will note that the thing you quoted practically screams “but what if there was a way to prevent new executable mappings?” I actually did this intentionally, with full knowledge of how you can use pledge to do this. I think it is important for people who are not security experts to be able to follow the thinking that goes into analyzing these things, and be able to synthesize the usecase I mentioned at the start of this comment for themselves. You will still note that I called msyscall weak in my original comment, and it still remains weak even after mimmutable+pledge is implemented. As others have mentioned as well using ROP to jump to the syscall instructions in libc with your own arguments (it’s not special…) bypasses restrictions in the current design. In fact I can extend it with something OpenBSD does not have a good implementation of yet, strong CFI, which would prevent jumping into the middle of a function to execute that syscall instruction. But there are more fundamental reasons why this doesn’t work. Protecting certain “sensitive” operations is actually something you can do. PPL as I mentioned below does this. It’s built on top of strong CFI (PAC) and code integrity guarantees (KTRR), which we are assuming you can construct in userspace on OpenBSD. The difference is that PPL has a tiny surface, and OpenBSD’s libc has a large one. In practice this means that libc cannot actually tell whether a request coming from an application is legitimate or not. If you look at the threat model for mimmutable again, consider that it assumes an attacker has enough control to call mprotect with controlled arguments: this means they know the layout of the address space and they can subvert control flow. With this kind of control, it’s not that hard to just decide to do other system calls instead. And who needs a syscall for that? You can literally just call the libc function which is a wrapper around the syscall. How is it to know that my call to write is malicious and the seven thousand the program already made was not?

ggm 4y ago

Can't stop the instruction set being able to write. Can stop higher logic invoking them, sometimes. Good to do. I really like the level of integration with compiler, low level boot, trusted code regions, "you will almost never call this, but your OS might on your behalf" Live patching un-stoppable systems may be a challenge unless you code to passing live IO and state across process boundaries

Sirened 4y ago

>One of those marks executable memory that is empowered to call into the kernel; on OpenBSD systems, only the C library is given that capability. That will prevent hostile code loaded elsewhere from making direct system calls; protecting the rest of a process with mimmutable() will prevent the changing of protections to allow system calls from elsewhere (such changes would be done with msyscall() on OpenBSD). This is, unfortunately, a continuation of OpenBSD's long tradition of security "mitigations" that are entirely detached from any actual understanding of exploitation [1]. The above suggestion that attackers can no longer make syscalls from their shellcode, while ostensibly true, is moot because you can simply JOP to one of the authorized syscall instructions and entirely defeat the mitigation. Even if mimutable outright prevented any new code from being mapped, this still wouldn't really stop anyone; just look at iOS where attackers have thrived despite there only being one process on the entire OS which is able to map arbitrary code. > Whenever a process enters the kernel, its stack pointer is checked to see whether it is, indeed, pointing into a stack region; if not, the process is killed. This too is trivially defeated. You simply need to add another stage to your payload in which you copy your ROP payload onto the legitimate stack, pivot, and continue executing. If you managed to pivot off the original stack, you already have a pivot gadget and so you only then need to trigger a call to memcpy. This mitigation isn't stopping any real attacker. While I never hope to discourage kernel developers from thinking about security mitigations, I think it is really important that people working on these mitigations actually converse with people who write exploits. Other vendors have seen considerable success with their mitigations [2] in that they specifically target things that attackers need and want to do, such as heap spray. [1] See: ROP gadget elimination, a feature which does not actually stop ROP but merely hopes that "a substantial reduction of gadgets is powerful." <https://marc.info/?l=openbsd-tech&m=150317547021396&w=2 https://marc.info/?l=openbsd-tech&m=150317547021396&w=2>. Speaking from experience and having written plenty of actual exploits on attacker hostile platforms, trying to block code execution against an attacker who already has kernel read/write is an utterly ridiculous idea because even if you manage to stamp out every single ROP gadget, they can just go and stomp on your kernel page tables to map new kernel code. Even baring that, kernel R/W is still a complete compromise even if kernel code execution is somehow impossible because you can still just use R/W to bypass any control the kernel could ever hope to enforce. [2] Life and death of an iOS attacker by Luca Todesco <https://www.youtube.com/watch?v=8mQAYeozl5I https://www.youtube.com/watch?v=8mQAYeozl5I>, a discussion of exploit mitigations on iOS and the exponential cost of defeating mitigations on iOS. Luca's company writes exploits for iOS devices as a service and he is extremely knowledgable in this area.

beachhead 4y ago

someone show us bypasses for all these mitigations that don't mitigate anything please