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