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/
Suprised they scrapped the original full name, Heuristic Output Timing Kernel Address Randomized Link
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.
Any kind of security scheme that depends upon the kernel hash not changing will be broken.
ASLR randomizes the general offset.
This randomizes the object file order.
Selfrando randomizes every single function.
https://github.com/immunant/se...
https://www.ics.uci.edu/~perl/...
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?
... to hopelessly scramble the message with gratuitous and wrong use of terms of art.
How does that relate to the efforts (e.g. by Debian devs and maintainers) to provide reproducible builds, to verify and authenticate not only sources, but output binaries which are publicly distributed?
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.
This is being done because people are assholes, right?
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
KAAAARRRL, That kills people!
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 ?
So how do you go about signing a kernel for 'secure boot' purposes, when the kernel changes all the time ?
Yes, z/OS.
Well if you have an evil hypervisor, you have bigger problems. Also Intel's SGX is for protecting guests from bad hosts and visa-versa.
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
This idea will mainly affect Windows users who have to reboot all the time. With a BSD machine that only reboots once in 3 years, it will not be noticeable.
" 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.
randomization kindly make me nervous I reckon, uhmmhmmm...
a related though not directly relevant thought for some time has been about llvm.
in general, if software is distributed in the llvm bitcode, or sometimes a higher level intermediate language, with enough build work done so that, downstream of it there are no performance issues, then e.g. different processes can use different syscall numbers when accessing kernel functions, and can have a syscall api custom built for it at build time that restricts it to only those syscalls that it needs, and also limits how it can use them. the old synthesis os project by massalin comes to mind, along with various ideas from capability security and principles like least authority.
this sort of process, naturally, is far better suited to open source software, where reverse engineering a binary to see how a program works is only necessary in the presence of either a: a compiler bug, when the binary does not do what the source code says it should; or b: there is a mental masochist of a user who wants the challenge, and for whom the source code is the answer at the back of the book.
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.
The amount of FUD surrounding secure boot is astounding.
Oh please, that your only argument?
"Secure Boot" still means you need some signer's permission, and for most people by far, that's going to be redmond. Remote attestation again means someone else agreeing you're running "attested" software, which for most people by far, will again be some vendor or other, most likely redmond. Or perhaps the MAFIAA.
That twice means the whole thing is about control, not about security.
There's no FUD in there, just simple reality. The argument that possibly, maybe, if you work really hard at it and do deeply techical things that most geeks don't understand, nevermind the "average user", you might regain control over the hardware you thought you owned, so you might install and use something besides redmond's finest, is a hopelessly pernicious argument.
And the time-tested way to draw attention away from your poor argument quality is of course to pre-emtively accuse the other guy of having "FUD" for arguments. It just so happens... it's already come about just as predicted in the real world. That means the objections you're trying to wave away were in fact justified.
Thank you for playing.
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
I've missed you!
This sort of "security by obscurity" isn't going to solve the malware problem. It's shutting the stable door etc.
Seems to me that the only reliable solution is a "whitelist" approach: run ONLY approved executables. Enforced by the OS.
The idea that any executable should be able to run was fine when computers were in the research stage. Not any more.
The current antivirus approach of scanning everything for known threats cannot possibly keep scaling.
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.