KARL (Kernel Address Randomized Link)
While this might help against remote attacks, it’s subject to the same issues than KASLR (although I’ve heard good things about NetBSD’s implementation), and like libc symbols randomization, it’s defeated by a arbitrary reads. Speaking of KASLR, it’s interesting to mention that OpenBSD doesn’t do kernel memory randomization.
To prevent an attacker from simply reading the newly linked kernel and wait for the next reboot, the new kernel binary is unreadable by regular users.
It’s also incompatible with trusted boot, except if you’re willing to automatically resign your new kernel every single time you boot, which would kinda defeat the point.
There are a few mitigation strategies against BROP attack methodology. One can be summarized as “never reuse an address space”. If a freshly linked kernel of this type was booted each time, we would be well on the way to satisfying that. Then other migitations (sic.) efforts come into play.
But since BROP crashes the target a significant number of time, having your server rebooting for a whole week should be enough to tip you that something wrong is going on…
This mitigation is useful against exploits without large-enough infoleaks and attackers without a working a local arbitrary read (either via leaks, or CPU-side-channel-based). It makes relative overwrites harder to exploit, and renders single-pointers leaks moot. It doesn’t add much complexity code-wise nor impacts performances, but it makes debugging awful, since one has to provide their kernel along with every stacktrace.
Amusingly, IDA Pro is using a similar technique to watermark their binaries.
In June 2020, Kristen Carlson Accardi suggested “Function Granular Kernel Address Space Layout Randomization”, also known as FG-KASLR:
This patch set is an implementation of finer grained kernel address space randomization. It rearranges your kernel code at load time on a per-function level granularity, with only around a second added to boot time.
Unfortunately, not every symbol is randomized, leading to bypasses and CTF challenges:
Since the sshd binary becomes unique on every openbsd machine, we can also block a logged in user from inspecting it, and then using that information as part of a remote attack, so mode 511.
This threat model is a bit convoluted: preventing a local attacker from using knowledge of the binary layout to conduct remote attacks on the system.