I’m trying to understand this from an attacker’s perspective. If the attacker has gained arbitrary code execution, the attacker already has… code execution. The attacker would simply need to make use of a syscall gadget (doesn’t have to be the actual syscall libc stubs).
The only case where this makes sense is when both of these conditions are met:
OpenBSD’s address space randomization is disabled. I don’t think that’s even possible.
The attacker is too lazy to use ret2libc techniques even in a RWX memory mapping.
Neither of those conditions would particularly be met in the real world. Lazy attackers don’t go after OpenBSD systems.
So the kernel will kill a process that makes a syscall from a writeable page, but what’s to stop the process from just calling libc and making the syscall indirectly?
EDIT: I just recalled that library aslr somewhat (but not entirely) mitigates this.
I’m trying to understand this from an attacker’s perspective. If the attacker has gained arbitrary code execution, the attacker already has… code execution. The attacker would simply need to make use of a syscall gadget (doesn’t have to be the actual syscall libc stubs).
The only case where this makes sense is when both of these conditions are met:
Neither of those conditions would particularly be met in the real world. Lazy attackers don’t go after OpenBSD systems.
So the kernel will kill a process that makes a syscall from a writeable page, but what’s to stop the process from just calling libc and making the syscall indirectly?
EDIT: I just recalled that library aslr somewhat (but not entirely) mitigates this.