Date: Wed, 1 Jun 2016 00:22:10 -0400 From: Eric McCorkle <eric@metricspace.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, Allan Jude <allanjude@freebsd.org> Subject: Re: EFI GELI support ready for testers Message-ID: <B494915E-FAF8-44E9-82CC-465E939E1509@metricspace.net> In-Reply-To: <20160531120418.GF38613@kib.kiev.ua> References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <d6b96a6c-4e92-35a5-e78b-cc674b6d2f25@freebsd.org> <20160528172618.GB38613@kib.kiev.ua> <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> <20160529091827.GD38613@kib.kiev.ua> <46B3F9E2-A25B-4F9D-B35F-11AC782495B1@metricspace.net> <20160531120418.GF38613@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> On May 31, 2016, at 08:04, Konstantin Belousov <kostikbel@gmail.com> wrote= : >=20 >> On Sun, May 29, 2016 at 10:10:16AM -0400, Eric McCorkle wrote: >>=20 >> 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 boo= t environment can play that affect the OS as well. It's simply impossible f= or an OS to provide reliable security when the hardware or firmware is compr= omised, and this isn't limited to the boot loader. >>=20 > 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 /alrea= dy exist/, have been demoed in multiple forums, and have been discovered in t= he 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 a= n option rom or something similar 4) insert a trap similar to what debuggers do at the start point of any elf f= ile 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 G= ELI keys, I'd say drop another debugging-style trap in geli_taste, but the p= ossibilities 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 r= eferenced in leaked documents, or just go to DefCon or some other venue). S= omeone would have to actively sit down and write malware to sniff GELI keys i= n the boot loader, where they can just use what already exists if they want t= o back-door the kernel. >> What you completely ignore in all this is the capability for an attacker t= o tamper with the unencrypted kernel, loader, and drivers. >=20 > 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 s= cenarios here, because you don't seem to get what I'm talking about. 1) Attacker has physical access, tampers with machine while offline, possess= es ability to tamper with all hardware. This is mentioned only for complete= ness. You're helpless with or without full disk encryption, as they just pu= t a hardware keylogger in place (or anything else, really). A variation on t= his is the malevolent bios/EFI code scenario, in which they just deploy an a= lready existing rootkit on you. 2) Attacker has physical access, tampers with machine while offline, only po= ssesses ability to tamper with disk. Without full-disk encryption, they ins= ert 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 e= ncryption, there is no way to obtain most of the data. There is an informat= ion leak from examining unencrypted drivers, configs, and the kernel. This d= oesn't compromise this specific machine, as we assume we will never regain t= he machine. However, the attacker can potentially learn something about how= we configure machines. In the worst case, they discover something that cou= ld be used to attack other machines (unpatched CVE, etc). Some organization= s and people *do* consider this worth protecting against. 4) Attacker seizes/steals machine while online. Again, this is for complete= ness sake. They get all the data in either case. 5) Attacker accesses machine remotely while online, gains sufficient privile= ges to tamper with filesystems and disks. Total disclosure in either case. = They just steal the data directly, or tamper with loader/kernel if they *re= ally* want the keys. 6) Same as #5, but they are also able to flash firmware. No difference. Th= ey may actually mess with the firmware if they're mean or if they're doing s= ome kind of persistent penetration, but in all likelihood they just steal th= e data or backdoor loader and kernel again. Takeaway: there's no scenario where an attacker would be able to sniff GELI k= eys in the boot loader that they can't already get the keys today (or do wor= se), therefore, they gain no significant advantage from GELI keys being pres= ent 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 y= ou have not yet acknowledged that case yourself. Aside from denying attackers the ability to read *and tamper with* the kerne= l, loader, modules, possible configurations, and other data given offline ac= cess 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 aim= ed at protecting systems from attackers that have some level of physical acc= ess 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) al= l have their own full-disk encryption solutions. >>=20 >> Moreover, my work is aimed at tamper-resilience at the OS level. Yes, I k= now OS tamper-resistance can be undermined without trusted firmware, but we a= re seeing projects like coreboot and others working toward that end. Moreov= er, these kinds of efforts are themselves pointless when the OS does things l= ike leaving the most sensitive part of the system wide open to tampering. >>=20 >> Speaking personally, I would like to see a system where I have full disk e= ncryption combined with EFI secure boot with a unique platform key stored on= my encrypted disk. Having an unencrypted boot partition in such a system ju= st opens up more attacks, plain an simple. (I would also like to see an ope= n source firmware and no ME, but that's out of scope here) >=20 > 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 har= dware supporting secure boot. >=20 >>=20 >> Finally, it's not like Alan's and my work *forces* anyone to use GELI. I= f you are really worried about some scenario where an attacker doesn't have p= hysical access and needs to backdoor the firmware to sniff keys so they can a= ccess 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 fro= m boot1 and loader completely. But if you want full disk encryption, you ha= ve the option of having it. >=20 > 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 G= ELI code in the boot loader is simply not that complicated, nor is it that l= arge. It's mostly calling some crypto functions and reading some metadata. = As for my changeset, the majority of it is just EFI boilerplate to implemen= t various protocol interfaces (EFI is a rather tedious framework in some way= s). A more constructive direction for this, I think, would be to figure out how t= o reduce duplication and improve testability. The GELI functionality used i= n Alan's and my work ought to be pretty easily testable; all you need for a t= est suite is to make a few GELI volumes and turn their metadata blocks into a= constant array. Additionally, things could probably be refactored such tha= t 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 d= one for the crypto code itself). The userland EFI test framework I put forw= ard is another way to deal with the difficulties of maintaining boot loader c= ode...=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B494915E-FAF8-44E9-82CC-465E939E1509>