Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Operating Systems Software Unix Windows Linux

OpenBSD Will Get Unique Kernels On Each Reboot (bleepingcomputer.com) 162

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.
This discussion has been archived. No new comments can be posted.

OpenBSD Will Get Unique Kernels On Each Reboot

Comments Filter:
  • by randomErr ( 172078 ) <ervin DOT kosch AT gmail DOT com> on Thursday July 06, 2017 @05:11AM (#54754863) Journal
    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?
    • by DaMattster ( 977781 ) on Thursday July 06, 2017 @05:18AM (#54754875)
      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.
      • by Z00L00K ( 682162 ) on Thursday July 06, 2017 @05:34AM (#54754915) Homepage

        My concern over the technology is that it also can cause a non-deterministic behavior for the platform making it hard to capture elusive bugs. This means that you would need to have a way to be able to load a kernel that's mapped identically to the last time when you perform your test and development.

        Bugs that only appears when you have a certain constellation and load order are sometimes wasting weeks of work.

        • If the bugs are already there, they are bound to appear some day. Maybe even with the next kernel version.

          • But with a random kernel that "some day" can be a very long wait.
            • Actually, with a random kernel that kind of bug will occur much faster than previously so it will get fixed sooner and not after several years of lying dormant somewhere, probably used by some black hat hackers.

        • by windwalkr ( 883202 ) on Thursday July 06, 2017 @07:34AM (#54755339)

          This is certainly true (and I'd assume that kernel devs might be running with this turned off, or some kind of historical logs kept to track what state their kernel was in during a bug) but it's equally true that exercising things in this way could reveal bugs which were otherwise exceedingly rare, leading to better overall code quality.

          In practice, I would think that read-write data structures are more likely to exhibit this kind of problem though, not the read-only code. There are certainly edge cases (timing changes, etc.) but it's not like an off-by-one error is going to affect you, like it might with data.

          • I'd make the order depend on a hash(filename+seed). Thus, kernel #13 will be always the same, and patched versions of kernel #13 will be similar. On regular builds, the seed will be a long (non-bruteforcable) random string, that's still saved with debug info so you can reproduce the kernel you are running.

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          My concern over the technology is that it also can cause a non-deterministic behavior for the platform making it hard to capture elusive bugs. This means that you would need to have a way to be able to load a kernel that's mapped identically to the last time when you perform your test and development.

          Bugs that only appears when you have a certain constellation and load order are sometimes wasting weeks of work.

          This kind of thing might also expose bugs that were not exposed before, and that, in itself is a good thing. Of course they would likely be very hard to find bugs...

        • Re: (Score:3, Interesting)

          My concern over the technology is that it also can cause a non-deterministic behavior for the platform making it hard to capture elusive bugs. .

          Or they could just simply not fix the bugs to take care of that. True story here. I work for a Fortune 500 company in their IT department and I joined them when my previously employer, a startup, was bought out by my current employer. A guy in my management chain was a huge OpenBSD fan, so he made us run some servers using it. Nothing in production used it, but we had some test systems that did. I know I know. Running something in test that isn't like production.... So anyway, he loved OpenBSD with

          • by unrtst ( 777550 )

            You filed a bug report, right? Where is that? (you didn't really provide enough info so that it could be found, even if it existed - like what hardware caused the bug?)

          • I don't see the issue. Some guy was playing around with an isolated OpenBSD machine and found a bug that results in a DoS, and you go directly to Theo rather than filing a bug report (on the project that founded transparent development decades ago). I'm sorry but shit story.
          • by antdude ( 79039 )

            And Theo still cared not after that. :P

          • 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"
        • You can say that about nearly every feature put into an Operating System. Changes to Memory Management, Changes to the multi-processing algorithm. Every time you add a level of complexity there is a chance you could create a problem, that is more difficult to fix.

        • My concern over the technology is that it also can cause a non-deterministic behavior for the platform making it hard to capture elusive bugs.

          Actually, one might argue that non-deterministic execution makes elusive bugs manifest.

        • Re: (Score:3, Informative)

          by TheRaven64 ( 641858 )
          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 dum
          • by aiht ( 1017790 )

            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.

            That variation is already present in every linked program anyway. This just changes the dice-roll from only once at build time to each and every boot time. Surely it would suck more to get a randomly slow link at build time and then be stuck with it?

            • That variation is already present in every linked program anyway.

              To a degree, yes, though in practice it's fairly deterministic and so you tend to only explore a smallish part of the overall space by accident.

              This just changes the dice-roll from only once at build time to each and every boot time. Surely it would suck more to get a randomly slow link at build time and then be stuck with it?

              Not really - predictable slowness is a lot easier to reason about and work around than unpredictable slowness. On a single machine, knowing that something will take 12 minutes is a lot easier to deal with than finding that yesterday it took 8 but today will take 12. Trying to debug a performance problem in userspace code can be very painful if the OS is unpredicta

        • by gmack ( 197796 )
          That is a known trade off and was also noted by some of the kernel devs when Linux started adding randomization but in the end, in Linux case, the extra security was considered more important.
        • by AmiMoJo ( 196126 )

          It seems like the scope for non-deterministic behaviour should be very, very small. All it is really doing is re-linking the kernel in a random order, so basically running the last stage of the build process (linking) again but with an additional RNG thrown in.

          In practice this will mean slightly different behaviour due to the way CPU caches work, but beyond that I can't really see much scope for variation. The caching will have a very small effect, so I suppose it is possible that some race condition or sim

        • On the other hand it makes it more likely that such kinds of bugs manifest themseves.

        • by rthille ( 8526 )

          If you install a kernel manually, it'll be used until you re-activate the random-kernel setup.

    • by Zero__Kelvin ( 151819 ) on Thursday July 06, 2017 @05:19AM (#54754877) Homepage
      They won't be recompiled, they will be relinked. Hopefully this happens in the background when the system is up, not at boot time.
    • I would say the extra time used for this process is an acceptable trade-off for enhanced security. Uniformity is the biggest security risk that these systems face. If the bad guys knows where all the pieces are on a lot of systems, then they know how to successfully target their attacks.

      That being said, there is a lot of effort in protecting the core system, but protecting your home directory, is where the valuable data normally is. I would like to see Operating systems setup with Application level securi

    • 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?

      Wouldn't the 'performance' just be an issue during boot time, or upgrade time? In other words, I'd expect slower reboots. Which then brings to question the usage. If it's being used in an always-on router, doesn't sound like a big deal. If it's on a laptop that one reboots frequently, I'd think it would

    • by tlhIngan ( 30335 )

      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?

      It's not recompiling, it's re-linking. The code's already compiled and unchanging. Just instead of linking a.o, b.o, c.o and d.o in that order, you link a.o, c.o, d.o, b.o.

      The result may not LOOK too different, but most linkers work linearly - so all the sections in the second binary

  • by badger.foo ( 447981 ) <peter@bsdly.net> on Thursday July 06, 2017 @05:15AM (#54754871) Homepage
    You will find more details over at the OpenBSD Journal site (undeadly.org [undeadly.org]), specifically the stories KARL - kernel address randomized link [undeadly.org] and the followup Kernel relinking status from Theo de Raadt [undeadly.org]. These and other items will also turn up on the project's Innovations [openbsd.org] page.

    And for that whirlwind tour of what's good in that system, take a peek at my OpenBSD and you [home.nuug.no] slides.

    • by Anonymous Coward
      Those are not the real sources, just selected quotes. The Bleeping article links to the real sources which are de Raadt's announcements. Here [marc.info] and here [marc.info].
  • 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?

    • by richy freeway ( 623503 ) on Thursday July 06, 2017 @05:52AM (#54754985)

      New is always better.

    • by lpq ( 583377 ) on Thursday July 06, 2017 @06:29AM (#54755119) Homepage Journal

      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.

    • If there's a bug in the kernel that allows arbitrary code injection (say, a buffer overflow), it'll be harder for that code to operate because it'll have no idea where anything is.

      Depending on the exploit, this may make it practically impossible to use the exploit in the real world.

    • by Wolfrider ( 856 )

      --Further along this line, how does this affect UEFI/Secure Boot, if at all?

  • by Anonymous Coward

    All OpenBSD needs now is to adopt systemd. Then it wil be totally secure. And more cromulent.

    • by Anonymous Coward

      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.

      • its standardised the distros not fracture it
        • Wasnt the point of linux to have choice? Systemd was straight up forced on us.
          • Wasnt the point of linux to have choice? Systemd was straight up forced on us.

            You have to earn your options.

            You can build an OS based on the Linux kernel. Linux itself doesn't require systemd; only the pre-built distros do.

            Now, all of their experts have decided that systemd should a required component of their operating systems. You are free to disagree.

            Complain to them if need be, but otherwise just shut up already. No one is going to change anything based on some random whine on Slashdot.

            To paraphrase for this situation: "You're not making Linux better. You're just making Slashdot

  • 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

  • ....apart from wearing ssds and make the authors look interesting?
  • The advantages (Score:5, Informative)

    by guruevi ( 827432 ) <evi@@@evcircuits...com> on Thursday July 06, 2017 @07:32AM (#54755327) Homepage

    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.

    • by lowen ( 10529 )

      Instead of 'evil hypervisor' think 'Intel Management Engine.'

  • by jfdavis668 ( 1414919 ) on Thursday July 06, 2017 @07:44AM (#54755397)
    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.
    • by guruevi ( 827432 ) <evi@@@evcircuits...com> on Thursday July 06, 2017 @08:28AM (#54755697) Homepage

      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.

    • by Anonymous Coward

      How many modules are there? If, say, 20 then 20! is about 2x10e18, and 30! is about 2.6x10e32

      Yes that's a finite number. So is a cryptography key.

      • Yes but then there is also the kernel base address randomization mentioned in the summary. Put the two together and you get a number that is larger than the total address space of the machine. So essentially all you know is that the problem space is 2^64 for each function whose address you'd like to determine.
    • As long as there's enough entropy in the state space, it will not be feasible to search it every time an exploit is tried. Since it's random knowing, the parameters of one system, won't give you any information about a different host since it was randomized at boot as well.
  • by Anonymous Coward

    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 [opengroup.org].
    • by radish ( 98371 )

      If your system relies on a specific machine being up at any given time it will fail. You say you don't want to intentionally reboot, but since you're guaranteed to unintentionally reboot it's better to design things so that doesn't matter. In which case, intentional ones don't matter either.

    • you are running you virtual mouth in ignorance. Updates in OpenBSD are not automatic, and the last version 6.0 had all of 28 patches of which 12 were for kernel. Whether or not those particular kernel patches would be needed (e.g. one was for a display driver) would depend on application.

      Uptime in years on a *node* means you are running an unpatched insecure application stack with a bad architecture. Uptime in years can be had with proper clustering, load balancing, etc.

  • Ooold. (Score:5, Funny)

    by SharpFang ( 651121 ) on Thursday July 06, 2017 @08:23AM (#54755661) Homepage Journal

    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.

  • " Microsoft has used KASLR for many years." and Linux kernel just added it.
    • by Anonymous Coward

      Microsoft's implementation was an obvious success, given how rarely malware infects Windows boxes.

  • Hope this gets copied over to linux ASAP...
  • by m.dillon ( 147925 ) on Thursday July 06, 2017 @11:00AM (#54757079) Homepage

    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

  • Time to inject something into the kernel linker. This random order thing should make it very easy to high all sorts of fun gadgets.

  • 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.

The last person that quit or was fired will be held responsible for everything that goes wrong -- until the next person quits or is fired.

Working...