Defeating Secure Boot With Linux Kexec

[Luke]

Surely a machine owner can patch Fedora to permit Kexec w/ Secure Boot

I'm not sure why. It just means that any kernel booting into Secure Mode has to have kexec disabled.

Just like DVD's css and Blu-Ray DRM, once again a corporate attempt to control what people do with what they have already bought and paid for has been defeated!

Should be easy enough to reconfigure Fedora (or anything else) to permit kexec with secure boot, say for a machine with a locked/buggy UEFI that does not permit turning Secure Boot off. For this a signed kernel NOT booting into any kind of Secure Mode would be booted with secure boot still activated. I think this is Ubuntu's default approach, as it makes the use of proprietary or other third party drivers much easier, as they do not have to be signed. Ubuntu Server should probably offer an option to change that, however. After all, blocking unsigned modules (or ALL modules) is an established technique to harden any system that will be run only with known hardware, such as a server, and is ineffective if a reboot to an arbitrary kernel is possible. Ideal approach would be a boot-time only option for secure mode or not, on the same signed kernel bootable from UEFI with Secure Boot enabled.

I could see cases, such as UEFI only accessable from inside Windows, where a kexec-style exploit is needed to essentially root your laptop. Still chicken-and-egg if starting from Linux on machines that offer no option to stop Windows 8 from booting and have a soldered-down disk, however. The other problem is machines like the MS Surface, with no option to run anything but Windoze. For these, a port of kexec to the Windows kernel would allow rebooting to Linux, either for a session or to load code to root the firmware to install other keys and/or disable Secure Boot. That will be the final crack of Secure Boot as a form of DRM. It took 6 months for someone to jailbreak the first iPhone, and they got a blizzard of bluffing threats from Crapple as I remember. Now rooted phones are everywhere, and Hollywood is crying.

I can really only see one reason to keep Secure Boot, given than kexec can reboot into Windows 8 or later. This would be for an attempt to obstruct the insertion of software keyloggers into /boot on encrypted machines. In the wild, the MSS(China secret police) is known to prefer hardware keyloggers, even on laptops. Suspect the same of the FBI, so this would be no guarantee even if it was perfect. The "evil maid" software keylogger is simple in theory but in practice in the field easy to run into surprises while trying to implement against unknown machines where you don't even know in advance what OS you will be facing, this the popularity or hardware keyloggers.

Just don't count on that TPM not to have additional, hidden keys for the NSA and maybe the FBI the way MS Windows itself and ATA security set password commands do. If it does, they
could sign their "evil maid" initramfs with that key instead of yours. Thus, we need an open-hardware TPM next, the kind you can drop into the motherboard socket and epoxy down. Only then will there be any "secure" in Secure Boot when the NSA (or possibly the MSS) is the adversary.

Until then, we gain much and lose almost nothing from exploits against Secure Boot. Its not secure, as the hardware itself cannot be trusted.

[Ericg]

No that is totally against the GPL license.
You can't mix GPL and proprietary code.

Isn't it also against to ship them by default included? There was multiple distros, for a long time, that shipped the Nvidia and AMD drivers on the liveCD's of their drivers and used them by default. Isnt that just as much against the license?

[MWisBest]

Yes and no.

You can disable kexec when you build the kernel. However you can then
build kexec in a kernel module (this is hacky but works, it's used on
Android phones to boot a custom kernel even with locked bootloader).

Of course you can disable kernel modules altogether but that would
be very limiting for the system.

That's why Android is disabling kernel modules by default now, hehe.


But yeah, as for kexec being able to do this, I'm surprised this hasn't been talked about before. I don't think it's any kind of "secret" really.

[Delgarde]

No way to compile the kernel portion of Nvidia and AMD drivers in? It'd be up to the individual distros then but still

No, because they're proprietary drivers distributed only in module form... no source, no object files... there simply isn't anything to compile in.

[smitty3268]

Should be easy enough to reconfigure Fedora (or anything else) to permit kexec with secure boot.

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.

[Luke]

Keys and bootloaders can be changed on MOST machines

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.

[curaga]

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

[droidhacker]

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!!!

[erendorn]

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.

[MWisBest]

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.