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/
So you get a new kernel each time. I got that from the 78 times they said it. What are the advantages and what are the disadvantages?
Don't fight for your country, if your country does not fight for you.
Those are not the real sources, just selected quotes. The Bleeping article links to the real sources which are de Raadt's announcements. Here and here.
All OpenBSD needs now is to adopt systemd. Then it wil be totally secure. And more cromulent.
The difference is merely in granularity; one is performed in the build time linker (aka static, ld), the other in the run time linker (aka dynamic loader, ld.so). The latter can be done in advance (prelinking), the former has to. The run time linker doesn't have information on all the intra-object links, so cannot operate at the level the build time linker does. That granularity might make a difference; it moves from up to about three (code, data, rodata) randomized pointers per program file to the same per object file (or possibly function, if the compiler splits them). The sort of exploit code this is supposed to mitigate doesn't need to hunt for all of those but typically a specific one, though, and the mitigation has been found to be fairly weak.
....apart from wearing ssds and make the authors look interesting?
systemd is RedHat's attempt to fracture Linux. Divide and conquer.
Because systemd is a solution in search of a problem. Something inspired by Microsoft's "registry" is nothing but thoroughly evil.
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.
Interesting that nix advocates were always mocking Windows for not being able to hot patch without needing a reboot and yet here we are, a nix based OS that needs reboots to stay patched, fwiw this is why updates get disabled (and people get pwned), we are not running silly games or wordy processors in BSD but usually devices that need uptimes of months, preferably years, i don't want to intentionally reboot at all.
are there any stable and secure nix distros left ?
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
Secure Boot is not about security, it's about control. It only verifies the signature of the kernel loader against a list of 'approved vendors', once the kernel is loaded, you can do pretty much anything you want with the computer.
Custom electronics and digital signage for your business: www.evcircuits.com
" Microsoft has used KASLR for many years." and Linux kernel just added it.
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
Well, an actively evil hypervisor is indeed more problematic (where someone has full access to it), I was more thinking of an automated exploit, automated exploits will be much more difficult to execute, you will require someone with deeper understanding of the kernel to manually intervene on every exploitable machine.
And Intel SGX has been broken and will probably be further broken in the future, it is also a double-sided sword. You can hide attack code in an enclave and nobody will ever be able to find it and from there on you can load side channel attacks.
Custom electronics and digital signage for your business: www.evcircuits.com
Nonsense. It does not verify the signature agains a list of 'approved vendors'. It verifies the signature against a list of approved signers. While some crappy consumer brands may have built-in keys that can't be changed, real computers (servers) allow you, the machine owner, to install your own keys.
As to what happens once booted, that depends on what you booted. GRUB will verify the signature of the kernel and initrd before it loads them. If Linux is configured for IMA (Integrity Management Architecture) it will verify the signature of files upon an 'open', including the kernel modules. And it you use remote attestation you can verify that you are not running previously signed but vulnerable code.
The amount of FUD surrounding secure boot is astounding.
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.
Yeah, but Grub or Linux using or verifying signed code has nothing to do with Secure Boot. Secure Boot ends when Grub loads.
Custom electronics and digital signage for your business: www.evcircuits.com
If you don't have secure boot turned on, how do you know that the GRUB you are loading is not compromised to load an unsigned kernel? In fact, if secure boot is not turned on GRUB will NOT verify the kernel.
With secure boot turned off, the shim can't be trusted. If the shim can't be trusted then GRUB can't be trusted. If GRUB can't be trusted then the kernel can't be trusted. And if the kernel can't be trusted then any verification of signed code that it does can't be trusted.
Saying secure boot is not about security is nuts. It IS about security. The fact that is can ALSO be used for other purposes does not diminish its security usefulness.
Hope this gets copied over to linux ASAP...
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.
Who wants their processor to be idle all the time?
People who understand that excessive energy use contributes to making the planet's climate less hospitable.
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
Do you even know what FUD means? It means Fear, Uncertainty, and Doubt.
Now, let's look at what you call 'no FUD':
'need someones permission...redmond' FEAR! Be very afraid!!!
'maybe be MAFIAA' UNCERTAINTY! They could be watching!!!
'MAYBE is your work really hard...' DOUBT! You'll never be able to run anything bu Windows!!!
Your entire post is nothing but FUD.
Non-production targets are good, having them in the **mix** of test platforms is a good thing. They help find bugs in your code. Bugs that manifest infrequently on one platform sometimes manifest frequently on another. I've seen numerous "how the f' did this ever work" bugs discovered over the years.
There is little cost in doing so going from one posix platform to another and targeting something from the Linux camp and something from the BSD camp can be helpful. Again, note I used "mix of test platforms". Of course the target platform should be the main test platform, but a non-target should get some attention especially for automated testing.
Personally I take things a little farther and try to keep UI and core code separate and the core code portable. Even when targeting a Windows only environment I'll build the core code on Linux and run its regression and fuzzing tests. My supervisor and co-workers at the time thought it unnecessary, they changed their opinions over time. Occasionally asking to have their forked code tested under Linux before merging. Note this indicates nothing special about Linux. Same thing happens when port from one OS to another, say Windows to Mac, it really about a different environment than the main developers. Helps address the "works on my system" issues.
Make a blob that has the same checksum (the checksum routine is in the source, meh) and you're all set.
Except the "checksum" is likely not a checksum because malware could add padding to create the desired checksum just as well. Its likely the "checksum" is a hash and a collision (a match) is not easily created.
Time to inject something into the kernel linker. This random order thing should make it very easy to high all sorts of fun gadgets.
“Common sense is not so common.” — Voltaire
Uptime is a defining characteristic of OpenBSD - Netcraft will prove this. How often are OpenBSD machines rebooted to take advantage of this feature? It would be understandable on a Windows system.