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.
The rebuilding process shouldn't be that long. Especially if most of the modules are (mostly) precompiled. But with the random order that things will be re-compiled, will a bad order effect the overall performance of the system?
You say things that offend me and I can deal with it. Can you?
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/
New is always better.
All OpenBSD needs now is to adopt systemd. Then it wil be totally secure. And more cromulent.
I wouldn't see how if they only change the order in which object files are linked, the routines themselves should be the same and have the same exploit working for them unless the exploit relies on changing code in a fixed position of ram, but then a simple search function to locate the routine to be exploited can be added.
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
Since a lot of servers are up and running for seriously long times, the kernel won't change often. Also, since there are a finite number of permutations, it wouldn't be that hard to find the memory location you are looking for.
Yes, z/OS.
Had it on my 486 that ran Gentoo, and not just with the kernel but most of apps. By the time Emerge World completed and I'd need to reboot for the upgraded kernel to start up, a new version was already available, and Emerge World ran right after start, on whatever updates happened during the previous run would finish about the time another kernel was available.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Not that I know a lot about it but...
You sign the new kernel with the same signing key as the previous one.
But, that's not how it works. It's the kernel loader that's signed for Secure Boot, and then the kernel loader is free to use any further verification it likes of what it loads, what it checks, and how.
Part of why Secure Boot is "no more secure" in most configurations, because you're just certified that you're booting GRUB/whatever in most circumstances, which can be misconfigured to be quite open (which is what most people want - just a way to boot a free OS using a signed bootloader).
But even if it was signed, it doesn't mean that it can't be unique to the machine in question, it's just a matter of using a chain of certificates, but that's out of "Secure Boot"'s hands and into the hands of the kernel loader configuration.
I don't see how 3-year uptime correlates with the oft-repeated "just save your session, log out, shut it down, and start it back up again" workaround for missing or broken hibernate support on particular chipsets in laptop or desktop computers.
If I understand this correctly, the kernel is being relinked and rewritten to the boot partition. That's instant fail in my book.... at least for us, the boot partition is sacrosanct. We do *NOT* write to it except when specifically upgrading a system. We do not do ad-hoc or automated writes to it because years of experience has shown that most corrupted boots (aka machine -> non-working) are due to unexpected events occurring while a filesystem is being written to.
The rename trick is not a solution (there's the 'ideal' atomic, and then there is the reality. That storage devices can fail in many different ways even while writing a particular sector, that are unrelated to that sector).
So, honestly, I think OpenBSD is making a huge mistake here. I can see randomization at load-time, but relinking and rewriting the kernel binary on every boot? No. Bad bad bad idea.
ASLR or equivalent is close to useless anyway. Malware has found ways around it, it makes debugging and bug reproducability difficult (which arguably is more important... that bugs get found and fixed, not simply detected). It also tends to fragment memory which can cause serious problems for long-running systems. And the vast majority of systems will simply restart the service anyway. They might log the seg-fault from the malware, but maybe 0.001% of system owners actually look at those logs.
-Matt