OpenBSD Journal

KARL - kernel address randomized link

Contributed by rueda on from the Charlemagne dept.

In a message to the tech@ mailing list, Theo de Raadt (deraadt@) has announced a new randomization feature for kernel protection:

Over the last three weeks I've been working on a new randomization
feature which will protect the kernel.
[...]
Recently I moved all our kernels to a new mapping model, with patrick
and visa taking care of two platforms.
[...]
As a result, every new kernel is unique.  The relative offsets between
functions and data are unique.
[...]
However, snapshots of -current contain a futher change, which I
worked on with Robert Peichaer (rpe@):

That change is scaffolding to ensure you boot a newly-linked kernel
upon every reboot.[...]

Read the full message for the juicy details.

Note that, because of the new mechanisms, unhibernate does not work on -current (for now).

(Comments are closed)


Comments
  1. By Anonymous (185.104.120.4) on

    There really needs to be a better way to do this, rather than using GCC to relink the files every time the OS boots up. There is a huge potential for failure here if it goes wrong, all for little benefit (especially with the kernel, since userland applications cannot access kernel memory anyway, and if it can, they can do a colossal amount of damage).

    Being security-minded is great, but not if it leads to a false sense of security. If there is any attacks which can be prevented by this kind of tweakery (particularly when applied to the kernel) please let me know.

    Before I get ragey fanboys saying how "oh openbsd is for the DEVELOPERS not the USERS" and "How dare you defer from OpenBSD developer opinion you HERETIC!", let me make it clear that this just seems like a waste of energy to me.

    Comments
    1. By Anonymous Coward (77.88.97.134) on

      It seems more like an intermediate step, in that it's easier to shake out the bugs of randomly-linked kernels before adding code to the bootloader to do the job that the userland tools are doing here.

      More work is undoubtedly coming down the pike, so exercising some patience will probably pay off in a reasonable timeframe.

    2. By Anonymous Coward (24.113.18.65) on

      > There really needs to be a better way to do this, rather than using GCC to relink the files every time the OS boots up. There is a huge potential for failure here if it goes wrong, all for little benefit (especially with the kernel, since userland applications cannot access kernel memory anyway, and if it can, they can do a colossal amount of damage).
      >
      > Being security-minded is great, but not if it leads to a false sense of security. If there is any attacks which can be prevented by this kind of tweakery (particularly when applied to the kernel) please let me know.
      >
      > Before I get ragey fanboys saying how "oh openbsd is for the DEVELOPERS not the USERS" and "How dare you defer from OpenBSD developer opinion you HERETIC!", let me make it clear that this just seems like a waste of energy to me.

      Having a binary that knows how to shuffle its own deck would be more nifty. The GCC use sounds like a "Proof Of Principle".

    3. By phessler (phessler) on http://www.openbsdfoundation.org/donations.html

      > There really needs to be a better way to do this, rather than using GCC to relink the files every time the OS boots up. There is a huge potential for failure here if it goes wrong, all for little benefit (especially with the kernel, since userland applications cannot access kernel memory anyway, and if it can, they can do a colossal amount of damage).

      There are two potential failures that I can see.

      1) re-ordering the objects breaks things. this was already seen in the development of this feature, and all of those were bugs that have been fixed.

      2) power loss during the critical install step. this tool uses the same install mechanism as kernel builds do, and depends on a "mv" to move the kernel into /bsd. That's an atomic operation and is very fast.

      >
      > Being security-minded is great, but not if it leads to a false sense of security. If there is any attacks which can be prevented by this kind of tweakery (particularly when applied to the kernel) please let me know.
      >

      Before this change, all kernels would have precisely the same memory layout. If you know a single symbol, you can calculate everything else.

      The purpose of this, is to defend against attacks that use that information to attack. If every machine has a unique layout per boot, then those attacks cannot succeed.

      It is basically the equivalent of randomizing the objects in libraries.

      Comments
      1. By Anonymous Coward (128.52.128.105) on

        > There are two potential failures that I can see.
        >
        > 1) re-ordering the objects breaks things. this was already seen in the development of this feature, and all of those were bugs that have been fixed.
        >
        > 2) power loss during the critical install step. this tool uses the same install mechanism as kernel builds do, and depends on a "mv" to move the kernel into /bsd. That's an atomic operation and is very fast.

        It is only atomic as far as the OS is concerned. A partial write can render the system unbootable here, and all that is being done here seems to be adding another failure mode for the sake of more "randomization" without any real benefit.

        > Before this change, all kernels would have precisely the same memory layout. If you know a single symbol, you can calculate everything else.
        >
        > The purpose of this, is to defend against attacks that use that information to attack. If every machine has a unique layout per boot, then those attacks cannot succeed.
        >
        > It is basically the equivalent of randomizing the objects in libraries.

        Correct me if I'm wrong, but wouldn't anyone who has access to the symbol table be able to work out where things are regardless of the randomization? Again, another exercise in which a serious failure mode is added for apparently little benefit.

        It is nice to have extra security features, but not if the benefit is small compared to the severity of an incident resulting from added failure modes.

        Comments
        1. By Anonymous Coward (109.228.190.21) on

          > > There are two potential failures that I can see.
          > >
          > > 1) re-ordering the objects breaks things. this was already seen in the development of this feature, and all of those were bugs that have been fixed.
          > >
          > > 2) power loss during the critical install step. this tool uses the same install mechanism as kernel builds do, and depends on a "mv" to move the kernel into /bsd. That's an atomic operation and is very fast.
          >
          > It is only atomic as far as the OS is concerned. A partial write can render the system unbootable here, and all that is being done here seems to be adding another failure mode for the sake of more "randomization" without any real benefit.
          >
          > > Before this change, all kernels would have precisely the same memory layout. If you know a single symbol, you can calculate everything else.
          > >
          > > The purpose of this, is to defend against attacks that use that information to attack. If every machine has a unique layout per boot, then those attacks cannot succeed.
          > >
          > > It is basically the equivalent of randomizing the objects in libraries.
          >
          > Correct me if I'm wrong, but wouldn't anyone who has access to the symbol table be able to work out where things are regardless of the randomization? Again, another exercise in which a serious failure mode is added for apparently little benefit.
          >
          > It is nice to have extra security features, but not if the benefit is small compared to the severity of an incident resulting from added failure modes.

          you really dont get it do you?

        2. By phessler (phessler) on http://www.openbsdfoundation.org/donations.html

          > > 2) power loss during the critical install step. this tool uses the same install mechanism as kernel builds do, and depends on a "mv" to move the kernel into /bsd. That's an atomic operation and is very fast.
          >
          > It is only atomic as far as the OS is concerned. A partial write can render the system unbootable here, and all that is being done here seems to be adding another failure mode for the sake of more "randomization" without any real benefit.

          The new kernel is written to a temp location in that directory, then is moved to /bsd. Moves are atomic and are a single write to the disk. It can only point to the old kernel, or the new kernel. A partial write isn't possible, unless the underlying disk is lying to us.

          This part is as safe as possible.

      2. By Anonymous Coward (24.113.18.65) on

        > > There really needs to be a better way to do this, rather than using GCC to relink the files every time the OS boots up. There is a huge potential for failure here if it goes wrong, all for little benefit (especially with the kernel, since userland applications cannot access kernel memory anyway, and if it can, they can do a colossal amount of damage).
        >
        > There are two potential failures that I can see.
        >
        > 1) re-ordering the objects breaks things. this was already seen in the development of this feature, and all of those were bugs that have been fixed.
        >
        > 2) power loss during the critical install step. this tool uses the same install mechanism as kernel builds do, and depends on a "mv" to move the kernel into /bsd. That's an atomic operation and is very fast.
        >
        > >
        > > Being security-minded is great, but not if it leads to a false sense of security. If there is any attacks which can be prevented by this kind of tweakery (particularly when applied to the kernel) please let me know.
        > >
        >
        > Before this change, all kernels would have precisely the same memory layout. If you know a single symbol, you can calculate everything else.
        >
        > The purpose of this, is to defend against attacks that use that information to attack. If every machine has a unique layout per boot, then those attacks cannot succeed.
        >
        > It is basically the equivalent of randomizing the objects in libraries.

        If re-ordering breaks things, that is a bug that hasn't been fixed.

        rename is suppose to be atomic, so there should be no problem with a "mv". If rename is not atomic, then the kernel doesn't conform to standards (assuming it isn't NFS).

    4. By Marc Espie (espie) on

      > There really needs to be a better way to do this, rather than using GCC to relink the files every time the OS boots up. There is a huge potential for failure here if it goes wrong, all for little benefit (especially with the kernel, since userland applications cannot access kernel memory anyway, and if it can, they can do a colossal amount of damage).

      Your logic is slightly flawed, because the kernel is built with a compiler anyway. Yes, it can go wrong. It does so regularly when tinkering with the kernel as a developer. I don't really see a greater risk when doing that automatically as a user. You're already relying on millions of compiles (literally) going right when you're using OpenBSD.

      If anything, having a few links happen on a user machine is a great way to exercise the system MORE. Maybe find a few more bugs, which is always a good thing.

      But, hey, you're already relying A LOT on that magical gcc doing its work correctly, even if you don't know it. The build system of OpenBSD is very much reproducible. We don't believe in stuff that builds half the time.

      If you've been around for long enough, you might remember OpenBSD insists on building things natively and not do cross-compiles, because rebuilding the system is the most interesting test you can have. Other system (cuff cuff netbsd vax) have been burnt by cross-compiles in the past.

      > Being security-minded is great, but not if it leads to a false sense of security. If there is any attacks which can be prevented by this kind of tweakery (particularly when applied to the kernel) please let me know.

      OpenBSD has a great record with respect of security because we often start worrying about attacks a few months before they become practical. There are quite a few poc that have not led to practical attacks yet, but that KARL will make very much more difficult.

      We've always been of the very strong opinion that we should NOT wait for the attack to become practical. When the pieces fall into place, it's often too late. Fix things before they become an actual issue is MUCH better than reacting to actual attacks.


      > Before I get ragey fanboys saying how "oh openbsd is for the DEVELOPERS not the USERS" and "How dare you defer from OpenBSD developer opinion you HERETIC!", let me make it clear that this just seems like a waste of energy to me.

      Anything but that answer. Nope. Just wait for a few months/years, and I'm fairly sure KARL is going to save OpenBSD from quite a few embarrassments.

      Comments
      1. By Anonymous Coward (2a02:59e0:0:7::12) on

        > Your logic is slightly flawed, because the kernel is built with a compiler anyway. Yes, it can go wrong. It does so regularly when tinkering with the kernel as a developer. I don't really see a greater risk when doing that automatically as a user. You're already relying on millions of compiles (literally) going right when you're using OpenBSD.

        I am not referring to the fact that a compiler is used to build the kernel. I am referring to the fact that it is built and written to disk every single time the system starts up. If the object layout was randomly arranged while loading, it may not be an issue. Just reboot the system again and it should work this time round.

        The random linking of kernel isn't the only issue here though. This failure mode is present even with the random link ordering of libc as currently implemented.

        > If anything, having a few links happen on a user machine is a great way to exercise the system MORE. Maybe find a few more bugs, which is always a good thing.
        >
        > But, hey, you're already relying A LOT on that magical gcc doing its work correctly, even if you don't know it. The build system of OpenBSD is very much reproducible. We don't believe in stuff that builds half the time.
        >
        > If you've been around for long enough, you might remember OpenBSD insists on building things natively and not do cross-compiles, because rebuilding the system is the most interesting test you can have. Other system (cuff cuff netbsd vax) have been burnt by cross-compiles in the past.

        True, but these compiles have always been performed under strictly controlled conditions, such as a known build environment, developers who understand and can fix issues as they arise, known software and hardware configurations. The linking is only done once, not every time the system is booted.

        > OpenBSD has a great record with respect of security because we often start worrying about attacks a few months before they become practical. There are quite a few poc that have not led to practical attacks yet, but that KARL will make very much more difficult.
        >
        > We've always been of the very strong opinion that we should NOT wait for the attack to become practical. When the pieces fall into place, it's often too late. Fix things before they become an actual issue is MUCH better than reacting to actual attacks.

        I agree, but not with so much haste that the security feature is half-implemented. I am willing to redact this statement if the link-and-write-to-disk model is due to be replaced with a link-randomly-upon-load-without-writing-to-disk model.

        > Anything but that answer. Nope. Just wait for a few months/years, and I'm fairly sure KARL is going to save OpenBSD from quite a few embarrassments.

        I for one am certainly looking forward to that day.

        Comments
        1. By Theo (199.185.136.55) deraadt@openbsd.org on de Raadt

          > > Your logic is slightly flawed, because the kernel is built with a compiler anyway. Yes, it can go wrong. It does so regularly when tinkering with the kernel as a developer. I don't really see a greater risk when doing that automatically as a user. You're already relying on millions of compiles (literally) going right when you're using OpenBSD.
          >
          > I am not referring to the fact that a compiler is used to build the kernel. I am referring to the fact that it is built and written to disk every single time the system starts up. If the object layout was randomly arranged while loading, it may not be an issue. Just reboot the system again and it should work this time round.
          >
          > The random linking of kernel isn't the only issue here though. This failure mode is present even with the random link ordering of libc as currently implemented.
          >
          > > If anything, having a few links happen on a user machine is a great way to exercise the system MORE. Maybe find a few more bugs, which is always a good thing.
          > >
          > > But, hey, you're already relying A LOT on that magical gcc doing its work correctly, even if you don't know it. The build system of OpenBSD is very much reproducible. We don't believe in stuff that builds half the time.
          > >
          > > If you've been around for long enough, you might remember OpenBSD insists on building things natively and not do cross-compiles, because rebuilding the system is the most interesting test you can have. Other system (cuff cuff netbsd vax) have been burnt by cross-compiles in the past.
          >
          > True, but these compiles have always been performed under strictly controlled conditions, such as a known build environment, developers who understand and can fix issues as they arise, known software and hardware configurations. The linking is only done once, not every time the system is booted.
          >
          > > OpenBSD has a great record with respect of security because we often start worrying about attacks a few months before they become practical. There are quite a few poc that have not led to practical attacks yet, but that KARL will make very much more difficult.
          > >
          > > We've always been of the very strong opinion that we should NOT wait for the attack to become practical. When the pieces fall into place, it's often too late. Fix things before they become an actual issue is MUCH better than reacting to actual attacks.
          >
          > I agree, but not with so much haste that the security feature is half-implemented. I am willing to redact this statement if the link-and-write-to-disk model is due to be replaced with a link-randomly-upon-load-without-writing-to-disk model.
          >
          > > Anything but that answer. Nope. Just wait for a few months/years, and I'm fairly sure KARL is going to save OpenBSD from quite a few embarrassments.
          >
          > I for one am certainly looking forward to that day.


          I don't care what you think, you can run something else if you are so concerned.

          OpenBSD is a research operating system. Research entails risk.

          I've rebooted kernels probably 50,000 times in the last 20 years, and I've NEVER encountered the
          fictional scenario you lay out.

          "Don't change anything" conservatives like you a dime a dozen, just as a city is 90% populated by them, here you are, Mr. Anon Whiner.

          You are probably anon because you've never changed the world in a meaningful way. You find meaning in
          rejecting experimentation towards a better world.

          So sad.

          Anyways, back to my work. I'm working on something else which is just as dangerous.

          Comments
          1. By Anonymous Coward (79.247.143.240) on

            > > > Your logic is slightly flawed, because the kernel is built with a compiler anyway. Yes, it can go wrong. It does so regularly when tinkering with the kernel as a developer. I don't really see a greater risk when doing that automatically as a user. You're already relying on millions of compiles (literally) going right when you're using OpenBSD.
            > >
            > > I am not referring to the fact that a compiler is used to build the kernel. I am referring to the fact that it is built and written to disk every single time the system starts up. If the object layout was randomly arranged while loading, it may not be an issue. Just reboot the system again and it should work this time round.
            > >
            > > The random linking of kernel isn't the only issue here though. This failure mode is present even with the random link ordering of libc as currently implemented.
            > >
            > > > If anything, having a few links happen on a user machine is a great way to exercise the system MORE. Maybe find a few more bugs, which is always a good thing.
            > > >
            > > > But, hey, you're already relying A LOT on that magical gcc doing its work correctly, even if you don't know it. The build system of OpenBSD is very much reproducible. We don't believe in stuff that builds half the time.
            > > >
            > > > If you've been around for long enough, you might remember OpenBSD insists on building things natively and not do cross-compiles, because rebuilding the system is the most interesting test you can have. Other system (cuff cuff netbsd vax) have been burnt by cross-compiles in the past.
            > >
            > > True, but these compiles have always been performed under strictly controlled conditions, such as a known build environment, developers who understand and can fix issues as they arise, known software and hardware configurations. The linking is only done once, not every time the system is booted.
            > >
            > > > OpenBSD has a great record with respect of security because we often start worrying about attacks a few months before they become practical. There are quite a few poc that have not led to practical attacks yet, but that KARL will make very much more difficult.
            > > >
            > > > We've always been of the very strong opinion that we should NOT wait for the attack to become practical. When the pieces fall into place, it's often too late. Fix things before they become an actual issue is MUCH better than reacting to actual attacks.
            > >
            > > I agree, but not with so much haste that the security feature is half-implemented. I am willing to redact this statement if the link-and-write-to-disk model is due to be replaced with a link-randomly-upon-load-without-writing-to-disk model.
            > >
            > > > Anything but that answer. Nope. Just wait for a few months/years, and I'm fairly sure KARL is going to save OpenBSD from quite a few embarrassments.
            > >
            > > I for one am certainly looking forward to that day.
            >
            >
            > I don't care what you think, you can run something else if you are so concerned.
            >
            > OpenBSD is a research operating system. Research entails risk.
            >
            > I've rebooted kernels probably 50,000 times in the last 20 years, and I've NEVER encountered the
            > fictional scenario you lay out.
            >
            > "Don't change anything" conservatives like you a dime a dozen, just as a city is 90% populated by them, here you are, Mr. Anon Whiner.
            >
            > You are probably anon because you've never changed the world in a meaningful way. You find meaning in
            > rejecting experimentation towards a better world.
            >
            > So sad.
            >
            > Anyways, back to my work. I'm working on something else which is just as dangerous.
            >
            >

            Dear Theo;

            Read about Polymorphic Engines (Malware).

            If every Kernel is differently.. how will a OpenBSD-Dev support in a bug analyse? Now if you compile "own Kernels" you got told "run Generic"....

            With your model even self compiled Kernels get accapted.. right? Because each kernel is unique anyway.

            A Source of Informations about Polymorphic/Mutation stuff is http://vxheaven.org/

            http://vxheaven.org/lib/?index=PO&lang=en

            Comments
            1. By Marc Espie (espie) on


              > Read about Polymorphic Engines (Malware).
              >
              > If every Kernel is differently.. how will a OpenBSD-Dev support in a bug analyse? Now if you compile "own Kernels" you got told "run Generic"....
              >
              > With your model even self compiled Kernels get accapted.. right? Because each kernel is unique anyway.
              >
              > A Source of Informations about Polymorphic/Mutation stuff is http://vxheaven.org/
              >
              > http://vxheaven.org/lib/?index=PO&lang=en

              Heaven preserve us of lit majors who think that because they throw names at a problem they understand anything.

              we don't want NON GENERIC kernels in the sense we don't want clueless users tinkering with shit they don't understand. Randomized relink is seen as an acceptable solution. It's nowhere *NEAR* the magnitude of trouble that non generic kernels cause where debugging is concerned.

  2. By Anonymous Coward (109.163.234.4) on

    I would like to point out that maybe there should be some modification to this patch to support read-only /usr partition, like it was done for the reordening of the libraries, before some user start reporting errors at the boot sequence. Or is has already be taken care?

  3. By ED Fochler (131.92.14.154) undead@liquidbinary.com on

    This implementation seems mutually exclusive with signed executables like iPhone and Win8 and the TPM are employing. The concept of a trusted / signed boot chain seems useful, even if its current use case is to lock down hardware by companies to prevent users from installing legitimate operating systems.

    Can this implementation occur in memory only? This would afford a signed kernel on disk to be loaded after checking legitimacy, and then morph to protect itself at runtime so that threats would not have a homogenous target base to attack.

    I don't want to protect against a real-time attack only to be left vulnerable to an evil-maid on-disk kernel-swap attack.

    Comments
    1. By Theo (199.185.136.55) deraadt@openbsd.org on

      > Can this implementation occur in memory only? This would afford a signed kernel on disk to be loaded after checking legitimacy, and then morph to protect itself at runtime so that threats would not have a homogenous target base to attack.

      I spoke about that before. In essence - put a linker into the bootloader, and load+link from a /bsd.ar file instead. That linker would also need to include MD layout rules currently encoded in ld.script.

      Such a development would be a really big job. As a shortcut, we are
      building the future kernel using userland tooling which can already replace the /bsd file, since it is root.

      > I don't want to protect against a real-time attack only to be left vulnerable to an evil-maid on-disk kernel-swap attack.

      You cannot have both of these, because the proposal is far too simple.

      You want assurances that the pieces (such as /bsd) haven't been tampered with. /bsd is being built by system components such as the rc script and the linker. Surely you've verified rc and ld haven't been tampered with. Surely you've also verified the .o files in the link kit haven't been tampered with. If all components are untampered, then the new /bsd is product of untampered components. No problem, right? The tamper checks should be against *all* input material, not the products.

      If you lean towards checking the product, you'll end up in a very rough place.

      That pushes an ecosystem towards having the same kernel, every day for 6-12 months. It ensures running of the same binary in the same address space as last time, day in day out. That's really great for the attacker as that is required for success of a many attack techniques.

      Frankly your last sentence doesn't make sense. You haven't lost anything because we don't have the thing you think you're losing.

      Comments
      1. By Anonymous Coward (94.227.16.168) on

        > > I don't want to protect against a real-time attack only to be left vulnerable to an evil-maid on-disk kernel-swap attack.
        > You cannot have both of these, because the proposal is far too simple.

        the new kernel is created on a booted system, and set aside for next boot. are there any sane mechanisms possible for verifying the newly built kernel that would run after next boot? by sane, i mean outside the system that created that kernel. is this even useful? or, tying this into uefi/mok authentication and the whole trustedpath/etcetera components that are available on much hardware?

        my apologies for wasting your time if i didn't think this through.

  4. By Anonymous Coward (112.215.172.239) on

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]