Announcement

Collapse
No announcement yet.

Defeating Secure Boot With Linux Kexec

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Keys and bootloaders can be changed on MOST machines

    Originally posted by smitty3268 View Post
    No, you can't. That's the whole point.

    You're basically saying you could break Secure Boot by launching a kernel that isn't approved that includes kexec - which implies you've already bypassed Secure Boot.

    You either turned it off, or managed to key sign that kernel yourself to work, in which case there is no reason to use kexec to bypass anything, since you already have.
    I suspect there are distros out there that permit the combination of a signed kernel and kexec, first of all. As the original poster obseved, if kexec is supported by a signed kernel, that kernel can be replaced with an unsigned kernel, and no doubt some OS versions support this be default. I assume this has been tested somewhere. Use case: a locked down Linux distro sold by an OEM vendor on locked hardware (a new Tivo,perhaps?) , using Secure Boot to lock you in-but forgetting to disable kexec, or for which a kernel exploit allows inserting unsigned modules. Maybe someone does this on purpose to satisfy simultanous demands from Hollywood for DRM and from users for a deniable way to unlock the hardware.

    Of course, in any machine supporting "custom mode," keys can be changed, allowing you to sign any kernel you want to run and make sure is being used. Just because Fedora is by default configured to use Secure boot with its kernels and its keys (don't know if that is an MS key) does not mean a user can't modify it to use their keys and their kernel, so long as they install their own keys in the TPM. Bootloaders can be changed to ones that are themselves signed, call ExitBootServices themselves, then run unsigned kernels. In this scenario, you would be using kexec for some other purpose than cracking secure boot, such as a gamer wanting to boot into Windows directly from Linux. You could boot Windows 8 with a custom kernel and unsigned drivers, as though it were running under Stoned Bootkit, then crack DRM'ed Hollywood content, while Windoze Media Center still thinks it has a "protected audio path," etc. You might have this whole mess running in a VM but thinking it is on bare hardware while the hyperviser harvests the content for your backup files. In the latter case you are cracking Windows, not Secure Boot.

    Now I will point out an example of where you do NOT want kexec to be available: an encrypted machine such as a server that has to run unattended. Not a good idea, but suppose you are relying on DDR3 RAM epoxied into the slots, plus a hard-to-enter locked case to kill the "freeze the RAM" cold boot attack, thinking that means DM-crypt gives protection Bitlocker with its forensic tools given to the FBI does not.

    If the running kernel supports kexec, an attacker, (maybe even a remote attacker with a root shell from an exploit) could kexec to a new kernel and a special forensic OS, taking care not to overwrite RAM locations where the encryption key is likely to be stored, then extract the key without ever shutting down and risking RAM decay killing it. For this attack, a kernel not supporting kexec could be "updated" during a physical access visit to one that does, waiting for the next reboot. The reboot could be forced by an arranged power outage, etc. Secure boot and a system like Fedora could make that MUCH harder, but only if you are using your own keys and only if the TPM does not contain extra NSA/FBI keys hidden from you (as I assume it does).

    Personally, I would rely instead on a room boobytrapped to shut off the power if entered to attack that server. Step on the pressure plate, short out both the AC mains and the UPS, trip both breakers. Remote attacks remain an issue, but no physical access attacker could recover in time, especially worrying about securing the room before even attemping any further hacking. By the time they are back at the machine, that RAM has been powered down probably half an hour.

    Comment


    • #17
      Originally posted by MWisBest View Post
      That's why Android is disabling kernel modules by default now, hehe.
      People smarter than me have said "disabling modules is snake oil, and does not prevent one from loading code to the kernel.".

      Comment


      • #18
        could defeat any security benefits provided by Secure Boot
        And what "security benefits" would those be???

        Oh right... secure is from the perspective of system builders, not the actual people who own the hardware.

        In other words... HURRAH FOR KEXEC!!!

        Comment


        • #19
          Originally posted by droidhacker View Post
          And what "security benefits" would those be???

          Oh right... secure is from the perspective of system builders, not the actual people who own the hardware.

          In other words... HURRAH FOR KEXEC!!!
          Protection from rootkits and malware control at the hardware interface layer?

          Secure boot has never been necessary for implementing a locked boot-loader, (Tivoization?) so I don't really get why you would come to this conclusion.

          Comment


          • #20
            Originally posted by curaga View Post
            People smarter than me have said "disabling modules is snake oil, and does not prevent one from loading code to the kernel.".
            Can you by chance provide some references for this? I'd be very interested in it!

            If this sounds like sarcasm or trolling, it isn't, I'm geniunely interested in reading about this... I just know it can be hard to tell on the internet about things like this sometimes, especially in places where trolling can be common like here.

            Comment


            • #21
              Well, AFAIK, kernel modules are equally "dangerous", to put it in some way. Anyway, it is probably fixable. If you can make a software that only loads signed kernels, you probably can modify kexec and the module loading functions to work the same way.

              Also, I have news for the ones celebrating this: if you get to run a Linux kernel, either you are running Android (AFAIK, they don't use UEFI, so SecureBoot is already out of the picture and the vendor lock-in has been achieved in some other way), or you already bypassed SecureBoot if that's what you wanted. So, this news is at best "meh" if you dislike SecureBoot, and it is bad (but fixable) if you consider it a feature. So there is no reason to party here.

              Comment


              • #22
                Originally posted by mrugiero View Post
                Well, AFAIK, kernel modules are equally "dangerous", to put it in some way. Anyway, it is probably fixable. If you can make a software that only loads signed kernels, you probably can modify kexec and the module loading functions to work the same way.

                Also, I have news for the ones celebrating this: if you get to run a Linux kernel, either you are running Android (AFAIK, they don't use UEFI, so SecureBoot is already out of the picture and the vendor lock-in has been achieved in some other way), or you already bypassed SecureBoot if that's what you wanted. So, this news is at best "meh" if you dislike SecureBoot, and it is bad (but fixable) if you consider it a feature. So there is no reason to party here.
                Android can run on some x86 devices with SecureBoot last I heard, but the market for x86 devices is small, let alone ones with SecureBoot...

                With ARM platforms, it uses the ARM TrustZone, which can basically serve the same purpose and more that SecureBoot does.

                Comment


                • #23
                  Originally posted by MWisBest View Post
                  Can you by chance provide some references for this? I'd be very interested in it!

                  If this sounds like sarcasm or trolling, it isn't, I'm geniunely interested in reading about this... I just know it can be hard to tell on the internet about things like this sometimes, especially in places where trolling can be common like here.
                  Read up on grsecurity and Brad Spender; that quote was from Spender. I don't have an exact link, but it's not exactly secret info.

                  Comment


                  • #24
                    Originally posted by curaga View Post
                    Read up on grsecurity and Brad Spender; that quote was from Spender. I don't have an exact link, but it's not exactly secret info.
                    Thank you very much, I'll have a look at it!

                    Comment


                    • #25
                      I do not fully understand what he means that the windows kernel can be started with kexec. Usally EFI/Microsoft/Boot/bootmgfw.efi is started, thats nothing special but a standard efi binary. I want a sample implementiation to see how it should work. I don't consider the ReatOS loader as valid windows loader example.

                      Comment


                      • #26
                        Originally posted by erendorn View Post
                        Protection from rootkits and malware control at the hardware interface layer?
                        Which I couldn't care about in the slightest, compared to the risk of hardware manufacturers locking me out of running the software I want to run on the hardware I've paid for.

                        Comment


                        • #27
                          Originally posted by Kano View Post
                          I do not fully understand what he means that the windows kernel can be started with kexec. Usally EFI/Microsoft/Boot/bootmgfw.efi is started, thats nothing special but a standard efi binary. I want a sample implementiation to see how it should work
                          You start the Windows kernel with kexec in exactly the same way that you start the Linux kernel with kexec - load it, generate the appropriate handoff data and jump to the entry point. kexec-tools has implementations for the kernel and multiboot files already, it wouldn't be that much work to implement Windows support.

                          I don't consider the ReatOS loader as valid windows loader example.
                          You don't consider something that can load and execute the Windows kernel as a valid example of something that can load and execute the Windows kernel? Interesting position.

                          Comment


                          • #28
                            Originally posted by movieman View Post
                            Which I couldn't care about in the slightest, compared to the risk of hardware manufacturers locking me out of running the software I want to run on the hardware I've paid for.
                            but then, locking you out doesn't require secureboot on ARM, and it's specifically non compliant for secureboot on x86. So you couldn't care less compared to "nothing", leaving you in an odd position to complain either way.

                            Comment


                            • #29
                              Originally posted by Pajn View Post
                              No that is totally against the GPL license.
                              You can't mix GPL and proprietary code.
                              But they already do this. The firmware folder in the Linux code base is plagued with binary blobs, and some of them explicitly include license information that forbids modification, etc.

                              https://git.kernel.org/cgit/linux/ke...s/tags/v3.12.3

                              Comment


                              • #30
                                Originally posted by IsacDaavid View Post
                                But they already do this. The firmware folder in the Linux code base is plagued with binary blobs, and some of them explicitly include license information that forbids modification, etc.
                                I think that's why the firmware files don't actually get built into the Linux kernel, but instead are treated as data files.

                                Comment

                                Working...
                                X