OpenBSD recently added a bunch of new security mitigations most hardening processes against remote code execution. As of the latest release (OpenBSD 7.4) the ru

OpenBSD recently added a bunch of new security mitigations most hardening processes against remote code execution. As of the latest release (OpenBSD 7.4) the runtime linker registers all system call entry points per memory mapping with the kernel (offset in the mapping + the system call number). They also removed the indirect system call (where the syscall number is the first argument). With this in place a process can only perform those system calls still allowed by its pledge()+unveil() for which there exists an entry point. If dead code elimination removed all fork() and exec() syscalls from your process your attack won't be able to turn the compromised process into a (useful) reverse shell. The idea appears something like this: You have a very small TCP listener that probably that forks+execs per accepted connection. The reduced complexity of this piece makes it both easier to audit and harder to exploit. * The per session binary only contains the code to handle authentication and authorization (and accounting) of a single connection and fork/exec() into the next stage. * The listener could also re-exec() itself every so-and-so number of connection attempts to replace its image with a newly randomised instance of the same executable. This would limit the number of attempts an attacker has to reuse any information learned about the current listener process's memory layout should such a leak be found. The goal is to provide defense in depth instead of a single "magic bullet" e.g. rewriting it a "safe language" (trading new logic bugs in new code against memory safety bugs not yet found in old code). Splitting the OpenSSH server into multiple smaller processes also allows existing mitigations (some of them OpenBSD specific) to become more effective.