Hacker News Reader

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

Have you, or someone else as knowledgeable as you, been able to provide a succesful POC doing this? I admit that I haven't gone about looking for results on this topic and method of attack but I would be very interested in reading about it and see a practical example achieving it, since it's (in your own words) trivially defeated and simply needs just this or that thing.

Fine, you've nerd sniped me. I'll write a blogpost defeating both mitigations next week :)

i really hope you do this because it's super annoying to see all these folks talk about how these mitigations don't work but nobody really _shows_ it.

it's always the same thing whenever openbsd is mentioned.

"these mitigations don't work."

- "okay, please show us that they don't work"

"well, i don't use openbsd"

rinse. repeat.

it would also be nice to see some patches/fixes/suggestions/etc submitted after you've bypassed/defeated/whatever these things sent to the mailing lists. i don't suppose you'd agree to that?

I don't believe these mitigations are fixable, they are based on a fundamental misunderstanding of how people actually write exploits and what attackers are capable of. The issue is that it is extremely hard to try and limit what an attacker can do once they already have code execution in a process. There is a reason why most low level exploit mitigations apply before this point--once they have code execution, it's largely a lost cause to try and protect the integrity of the compromised process. The way we mitigate after code execution is by taking a step up and using things like sandboxing to try and prevent the compromise from impacting the rest of the system.

Also, I don't think it is quite right of you to be miffed that people aren't writing exploit PoCs to prove these mitigations are moot. These mitigations are trivially wrong to anyone who has any experience with exploit development, and being told to "show proof then" is baffling. It's like trying to explain to your uncle that no, vaccines will not make your child autistic, and him demanding proof. Obviously, that's neither how autism or vaccines work and trying to demonstrate that takes significantly more effort than most anyone cares to put in to a random (internet) argument. But, I am a fool who has too much time, so I'll bite.

can't wait!

Thank you! I'll keep an eye out. I'm genuinely interested.

> trying to block code execution against an attacker who already has kernel read/write is an utterly ridiculous idea

iOS does this. Kernel code is immutable (obviously), page tables are locked at reset and cannot be modified except by PPL code. ROP and JOP are mitigated against using hardware CFI (PAC). As you mentioned, when vendors actually understand what exploits look like and what attackers need to do, it enables them to do a good job. OpenBSD remains a system with a few good ideas and a model of what exploits look like that appears to be informed by dreams and idle musings, rather than actual research.

I believe I should have couched that statement with a "for most everyone else" :)

The PPL is a strong mitigation, I agree, but it is definitely one that is really only supported through their ability to ship custom hardware. Pulling off a PPL-like thing using MPK or a hypervisor is technically possible but in practice no real platform other than Apple is actually able to enforce memory mappings on all devices on an SoC and so anything you dream up to protect page tables is as durable as a wet paper bag since there's usually a half dozen other chips that will hapilly DMA any and all parts of physical memory for you. I dream of a day where we have an SMMU in front of every single device on a regular smartphone SoC (or, hell, even a PC platform), but that day has not yet come and I'm not really holding my breath either. As such, nobody else can actually meaningfully guarantees kernel code integrity under kernel R/W and so even if they had a perfect PAC implementation (which, as I'm sure you know, is incredibly difficult), you could just corrupt the backing code pages and sidestep it.

Right, iOS definitely has a different threat model which requires (and takes advantage of) Apple's ability to make custom hardware. In this case, though, OpenBSD is looking to protect userspace, and they could provide guarantees for that (iOS does this via codesigning, but you could also just force security-sensitive programs to stop using dlopen).

> you can simply JOP to one of the authorized syscall instructions and entirely defeat the mitigation

But now you need to know where the libc is mapped in order to find those syscalls instructions yeah? Which increases the complexity of the exploit, because instead of making a syscall you have to find where the libc is mapped, and the entire point of ASLR is making that difficult, no?

If you've managed to map shellcode at all, you necessarily already know where a valid syscall instruction is since otherwise you would not have been able to trigger the mmap syscall to map the shellcode. In any event, mapping shellcode is entirely optional anyways since to even get to that point you must already have full control through ROP, at which point you could do everything the program could (albeit in a significantly more annoying way).

The main binary has to be able to call into libc somehow, and thus it's typically easy to get a libc pointer if you have an existing method of code execution.

I don't know how it works on OpenBSD, but on Linux there's a section of memory called the PLT that contains pointers for all the functions from dynamic libraries, including those from libc. Also, there's typically libc pointers all over the stack.

If you look at the mitigations OpenBSD is doing as attack surface reduction, it means ultimately fewer tools in the attackers toolbox.

It seems many of you are missing the forest for the trees.

The question we have to ask ourselves is whether OpenBSDs mitigations are taking away enough attack surface (or in this case, exploitation tools) to make it worth the engineering and user cost.

I'd argue that things like msyscall and mstack don't at all because they cost attackers only a couple of minutes of time once to develop a bypass technique (ie move the stack pointer before a syscall, reuse the authorized syscall instruction) that they can apply everywhere. This greatly contrasts with mitigations like ASLR where each time an attacker wants to bypass the mitigation they are forced to develop a novel, program dependent strategy to leak some information. This is a huge pain and has definitely killed some otherwise exploited bugs because no such leak could be devised.

> I'd argue that things like msyscall and mstack don't at all because they cost attackers only a couple of minutes of time once to develop a bypass technique (ie move the stack pointer before a syscall, reuse the authorized syscall instruction) that they can apply everywhere.

If you read up on library order randomization/re-link and retguard, you may find your technique won't be so reusable, even once you do manage to locate a syscall stub in libc.

It also means fewer tools in developers' toolboxes. Not being able to make your own system calls directly, or exercise control over your own address space, means that anything that doesn't conform to a C runtime won't run in OpenBSD. Perhaps that's a tradeoff that the OpenBSD developers are willing to make, but even so, these particular "mitigations" do not address the root cause of many security vulnerabilities: failure to verify untrusted input.

I think that only Linux had some syscall stability. Every other operating system provides libc or other kind of library with stable interface but syscalls are not stable. Yes, technically you can execute those instructions and your software will work on a fixed kernel version, but that's not what people do.

Lack of syscall stability isn’t a showstopper, it just means that the functions invoking the syscall need to be versioned according to uname(). The uname() call itself can be done via direct syscall if you’re confident that its ABI won’t change; or, if you want to be extra sure, you can use the libc wrapper for uname() and then munmap() the C runtime to replace it with whatever. Either way requires the maintainer to be proactive with implementing code paths for upstream upcoming kernel versions before they are mainlined.

OpenBSD will make the above approach impossible, because with mimmutable(), libc will not be unmappable.

> The uname() call itself can be done via direct syscall if you’re confident that its ABI won’t change; or, if you want to be extra sure, you can use the libc wrapper for uname() and then munmap() the C runtime to replace it with whatever.

I would ask why you would want to do this.

So just ROP to the syscall you want in libc. Instead of targeting the syscall instruction, directly call mmap. System call randomization is a feature designed to discourage legitimate software from hardcoding syscall numbers. It is not meant as an exploit mitigation.