EFI GELI support ready for testers

[Eric McCorkle]

> On May 31, 2016, at 08:04, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
>> On Sun, May 29, 2016 at 10:10:16AM -0400, Eric McCorkle wrote:
>> 
>> Ok fine.  But this is a risk anyone using EFI has to assume, and it doesn't end at the boot environment.  There are plenty of nasty tricks an EFI boot environment can play that affect the OS as well.  It's simply impossible for an OS to provide reliable security when the hardware or firmware is compromised, and this isn't limited to the boot loader.
>> 
> This statement, althought looking true, does not account for difference
> in the level of efforts required to target the corresponding environment.

It is not any more difficult; BIOS/EFI based exploits against kernels /already exist/, have been demoed in multiple forums, and have been discovered in the wild.  As a PoC, a simple kernel exploit might like this:

1) replace bios disk read/EFI block read with malware that tracks contiguous sections of memory written by disk reads.
2) look for ELF headers in any such sections
3) store runtime malware in a memory section disguised in the memory map as an option rom or something similar
4) insert a trap similar to what debuggers do at the start point of any elf file you detect, have the traps jump into the runtime malware
5) once you trap into the runtime malware, you have them.  If you just want GELI keys, I'd say drop another debugging-style trap in geli_taste, but the possibilities are really endless (just deploy your favorite rootkit)

But the fact is, you can find this kind of thing on the dark web today (or referenced in leaked documents, or just go to DefCon or some other venue).  Someone would have to actively sit down and write malware to sniff GELI keys in the boot loader, where they can just use what already exists if they want to back-door the kernel.


>> What you completely ignore in all this is the capability for an attacker to tamper with the unencrypted kernel, loader, and drivers.
> 
> At which point would the attacker tamper ?  Immediately after your
> GELI UEFI code provides him with the keys to do so ?

No this attack is *offline*.  I'm going to break down all the major attack scenarios here, because you don't seem to get what I'm talking about.

1) Attacker has physical access, tampers with machine while offline, possesses ability to tamper with all hardware.  This is mentioned only for completeness.  You're helpless with or without full disk encryption, as they just put a hardware keylogger in place (or anything else, really).  A variation on this is the malevolent bios/EFI code scenario, in which they just deploy an already existing rootkit on you.

2) Attacker has physical access, tampers with machine while offline, only possesses ability to tamper with disk.  Without full-disk encryption, they insert malware into the unprotected kernel, loader, or modules.  They cannot do this with full-disk encryption, as they can't read the contents of /boot at all.

3) Attacker seizes/steals machine while offline.  With or without full-disk encryption, there is no way to obtain most of the data.  There is an information leak from examining unencrypted drivers, configs, and the kernel.  This doesn't compromise this specific machine, as we assume we will never regain the machine.  However, the attacker can potentially learn something about how we configure machines.  In the worst case, they discover something that could be used to attack other machines (unpatched CVE, etc).  Some organizations and people *do* consider this worth protecting against.

4) Attacker seizes/steals machine while online.  Again, this is for completeness sake.  They get all the data in either case.

5) Attacker accesses machine remotely while online, gains sufficient privileges to tamper with filesystems and disks.  Total disclosure in either case.  They just steal the data directly, or tamper with loader/kernel if they *really* want the keys.

6) Same as #5, but they are also able to flash firmware.  No difference.  They may  actually mess with the firmware if they're mean or if they're doing some kind of persistent penetration, but in all likelihood they just steal the data or backdoor loader and kernel again.

Takeaway: there's no scenario where an attacker would be able to sniff GELI keys in the boot loader that they can't already get the keys today (or do worse), therefore, they gain no significant advantage from GELI keys being present at boot time.  By contrast, a backdoor is defeated in scenario #2 and an information leak is defeated in scenario #3, meaning full disk encryption *does* provide an advantage.

> Let me restate the question I aked in my first mail, but now after
> having the discussion rolled forward. Is there any other 'security'
> benefit from having /boot encrypted, other than obscuring the kernel
> binary ?

I will say that it denies them the ability to tamper with it offline, since you have not yet acknowledged that case yourself.

Aside from denying attackers the ability to read *and tamper with* the kernel, loader, modules, possible configurations, and other data given offline access to the machine, no there isn't any other advantage I can think of.

>> You are only considering one kind of scenario.  Alan's and my work is aimed at protecting systems from attackers that have some level of physical access to the machines.  There are people in the world who have to contend with this sort of thing, and the major competing OSes (Apple, Linux, MS, etc) all have their own full-disk encryption solutions.
>> 
>> Moreover, my work is aimed at tamper-resilience at the OS level.  Yes, I know OS tamper-resistance can be undermined without trusted firmware, but we are seeing projects like coreboot and others working toward that end.  Moreover, these kinds of efforts are themselves pointless when the OS does things like leaving the most sensitive part of the system wide open to tampering.
>> 
>> Speaking personally, I would like to see a system where I have full disk encryption combined with EFI secure boot with a unique platform key stored on my encrypted disk. Having an unencrypted boot partition in such a system just opens up more attacks, plain an simple.  (I would also like to see an open source firmware and no ME, but that's out of scope here)
> 
> What you describe makes even less sense.  If secure boot is in action,
> then kernel binary should be measured and its fingerprints compared with
> the protected records in TPM.  Then all the layers that you add are
> useless.

There is still the information disclosure.  Also, some people don't have hardware supporting secure boot.

> 
>> 
>> Finally, it's not like Alan's and my work *forces* anyone to use GELI.  If you are really worried about some scenario where an attacker doesn't have physical access and needs to backdoor the firmware to sniff keys so they can access data they can't see despite being able to write to firmware, then fine, don't use GELI at boot.  Better yet, use the compile flag to remove it from boot1 and loader completely.  But if you want full disk encryption, you have the option of having it.
> 
> It forces us to maintain that code. It pulls large amount of code into
> environment that is hard to debug in the comfortable local setup, and is
> absolutely impossible to inspect and diagnose in the wild, where the
> problems occur on the user machine.

That is a legitimate concern, though I think it's way overblown here.  The GELI code in the boot loader is simply not that complicated, nor is it that large.  It's mostly calling some crypto functions and reading some metadata.  As for my changeset, the majority of it is just EFI boilerplate to implement various protocol interfaces (EFI is a rather tedious framework in some ways).

A more constructive direction for this, I think, would be to figure out how to reduce duplication and improve testability.  The GELI functionality used in Alan's and my work ought to be pretty easily testable; all you need for a test suite is to make a few GELI volumes and turn their metadata blocks into a constant array.  Additionally, things could probably be refactored such that there could be a single implementation of the metadata and crypto handling bits.  (I was also asking in another branch if a similar thing couldn't be done for the crypto code itself).  The userland EFI test framework I put forward is another way to deal with the difficulties of maintaining boot loader code...