An attacker can simply write code to a writable memory mapping, create a ROP chain to transition the mapping to executable and
then execute their shellcode from there. Many exploits in the wild have been shown to do this instead of purely relying on ROP
since that takes more effort.
Another of OpenBSD's mitigations is TRAPSLED.
This aims to neutralise NOP sleds, but this mitigation doesn't really do
anything since the adoption of ASLR. TRAPSLED can be useful for some non-security use cases, but it is absolutely
not an exploit mitigation.
As well as developing half-baked mitigations, OpenBSD also lacks plenty of modern mitigations completely. Again, this is a
non-exhaustive list and there are still plenty more examples than the ones listed here.
Verified boot is an important security feature that eliminates privileged
malware persistence by verifying the integrity of the entire base operating system. This is most commonly used on mobile devices
with Android and iOS both having solid
implementations, but desktop operating systems have made substantial progress on this as well; mainly macOS,
Windows and ChromeOS, whereas any
form of verified boot is nonexistent on OpenBSD.
Trusted Path Execution (TPE) prevents an attacker from executing arbitrary code
from the filesystem and can be used as a supplement to proper W^X to prevent dynamic native code execution in both memory and the
filesystem, but — like the lack of actual W^X — OpenBSD also has no TPE.
OpenBSD has no Mandatory Access Control (MAC) system like
AppArmor or
SELinux which prevents you from fully locking down user space. In comparison to, for example, Android in which it uses a
strict, full system SELinux policy to confine every single process in
user space and is a core part of the security model. Pledge and Unveil, while being great sandboxing tools, are not a replacement
for a proper MAC system. It still fully trusts the applications as it has to be implemented within its source code and it isn't
nearly as fine-grained as a good SELinux setup.
OpenBSD also lacks any form of GUI isolation which will make sandbox escapes incredibly easy. It uses Xenocara, a fork of X11 which is
notorious for being insecure and not implementing GUI isolation
and OpenBSD does not support Wayland.
Although despite the many issues with it, some of OpenBSD's mitigations are pretty solid like their malloc implementation and OpenBSD excels in their
cryptography and standalone tools, just not really when it comes to general OS security.
A more promising alternative to OpenBSD is HardenedBSD. There are
advantages and disadvantages of HardenedBSD over OpenBSD. HardenedBSD has many mitigations OpenBSD does not, such as CFI,
SafeStack, SEGVGUARD, a proper W^X implementation and more, but it lacks things OpenBSD has, such as LibreSSL, a
hardened memory allocator, etc.