Slashdot Mirror
OpenBSD Will Get Unique Kernels On Each Reboot (bleepingcomputer.com)
An anonymous reader quotes a report from Bleeping Computer: A new feature added in test snapshots for the upcoming OpenBSD 6.2 release will create a unique kernel every time an OpenBSD user reboots or upgrades his computer. This feature is named KARL -- Kernel Address Randomized Link -- and works by relinking internal kernel files in a random order so that it generates a unique kernel binary blob every time. Currently, for stable releases, the OpenBSD kernel uses a predefined order to link and load internal files inside the kernel binary, resulting in the same kernel for all users. Developed by Theo de Raadt, KARL will work by generating a new kernel binary at install, upgrade, and boot time. If the user boots up, upgrades, or reboots his machine, the most recently generated kernel will replace the existing kernel binary, and the OS will generate a new kernel binary that will be used on the next boot/upgrade/reboot, constantly rotating kernels on reboots or upgrades. KARL should not be confused with ASLR -- Address Space Layout Randomization -- a technique that randomizes the memory address where application code is executed, so exploits can't target a specific area of memory where an application or the kernel is known to run. A similar technique exists for randomizing the memory location where the kernel loads -- called KASLR. The difference between the two is that KARL loads a different kernel binary in the same place, while KASLR loads the same binary in random locations. Currently Linux and Windows only support KASLR.
And for that whirlwind tour of what's good in that system, take a peek at my OpenBSD and you slides.
-- That grumpy BSD guy - http://bsdly.blogspot.com/
Enough regression testing has been performed on the technology and no performance loss was noticed. I run a -current snapshot on my laptop and the boot speed and overall performance is just as good as OpenBSD 6.1 without KARL.
They won't be recompiled, they will be relinked. Hopefully this happens in the background when the system is up, not at boot time.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
well from TFS:
If the user boots up, upgrades, or reboots his machine, the most recently generated kernel will replace the existing kernel binary...
So it sounds the relinking happens when the system is running and the new kernel is used on next reboot.
Everything I write is lies, read between the lines.
Similar to the pluses and minuses of Address Space Randomization. Right now, in the static part of the kernel, different subsystems are linked together into 1 binary that is loaded into memory at boot. Along with the assumption that the different subsystems could be linked together in many valid orders, that link could be done when the kernel boots so the different sections of the kernel would load in different places relative to each other. in memory.
The problem would be when 1 compilation or binary kernel becomes widely distributed such that malware could rely on the relative positions of different subsystems in memory. Using that knowledge might make it easier for malware to make use of different subsystems at run time -- on the premise if you know where 1 is, you know where all the rest are. If you can load subsystems, unpredictably at boot, it would be harder for today's malware to make use of. Instead, the malware would have to replicated the loading algorithm and try to reproduce the load order by calculation to make the same use of those subsystems -- another level of difficulty for malware wanting to use existing subsystems.
Static load order would be most problematic for embedded binaries that come off a ROM and less so for binaries distributed by a large distro. It's also more problematic if the subsystems are linked together in the same order at compile time (which, AFAIK, they are for the linux kernel).
That link order could potentially be randomized at link time which would have a large amount of the same benefit as the boot-time randomization for end-user-systems that are locally compiled (with some pluses & minuses).
I don't know that the benefit of this feature has been quantified or is easily quantifiable. The deficits of this feature I would think minimal in a production (non-development/non-debuggable) product.
Lots of people here asking about the advantages - here is the laymans explanation.
So typically with ASLR you load a kernel blob into a randomized space and then it just sits there. An attacker (e.g. an evil hypervisor) could search the entire address space for the kernel or in some other way hook into the kernel binary and then simply count up or down address spaces or more likely pass an evil payload to load exploits against specific parts of the kernel from there. Since you always know which parts come first, you can craft payloads so that it gets passed or overflows until it reaches the vulnerable piece of code.
What this is doing, it randomized the kernel and subsequently the entire kernel even though it sits in the same spot and you could still find or hook into it, you can't simply count up and down anymore to find the bad piece of code nor can you be guaranteed that weak boundary checks will pass your payload, because even though the system has hooked your vulnerable piece of code somewhere, it's not going to be in the same spot.
It's basically more fine grained ASLR where you break the program (the kernel) down further in smaller pieces to be randomized.
Custom electronics and digital signage for your business: www.evcircuits.com
The idea is that when you have hundreds of machines, even though their uptime is high, they'll still all be running 'different' kernels.
To be able to find a memory location, you have to pretty much already run as root. This is to prevent exploits before they get to that point. Eg. if you have a weak TCP/IP stack and you send an 'evil bit' that overflows the buffer, you're no longer guaranteed that by filling the next n buffers you will be able to execute shell code.
Once you can search through the memory, you've gotten to a much farther point.
Custom electronics and digital signage for your business: www.evcircuits.com
This is a concern. The work appears to be based on work from UPenn, which compiled everything with -ffunction-sections and -fdata-sections (if you don't do this, it turns out that you leak enough information to find gadgets quite easily) and re-linked programs in a random order on each run (there's a lot of subsequent work on doing it more often, such as the ReRANZ paper at VEE this year). It's not too difficult to debug, because you record the random number seed with the binary and include it in core dumps, which lets someone else reconstruct the exact implementation. The other concern is that randomising the link order has been shown (ASPLOS 2015) to have around a plus or minus 20% impact on performance. Having that variation across reboots for the kernel could be quite frustrating.
I am TheRaven on Soylent News