Practical security for 2014 [LWN.net]

Practical security for 2014

Posted Jan 14, 2014 15:47 UTC (Tue) by mjg59 (subscriber, #23239)
In reply to: Practical security for 2014 by paulj
Parent article: Practical security for 2014

No, but the set of actively exploited bugs tends to be bounded. The current state of affairs is that a single successful attack against your system can be turned into a persistent compromise - even if you fix the original bug, your system is still under the control of the attacker. Secure Boot provides mechanisms to ensure that that's not true. The attacker can no longer subvert the boot process itself, so has to compromise some other component. But once we know that that component has a vulnerability, we can fix it and upgrade it from within the trusted environment.

This can only be bypassed if there's an exploitable vulnerability in the code within the trusted environment. That's ok, though, because we can make the set of code we need to trust almost arbitrarily small. There's no need to trust the on-disk /sbin/init - just download a new one.

Is making it significantly more difficult for an attacker to engineer a persistent compromise of a system an improvement of security? Obviously. Does Secure Boot provide a mechanism for doing so? Yes.

to post comments

Practical security for 2014

Posted Jan 14, 2014 16:20 UTC (Tue) by paulj (subscriber, #341) [Link] (25 responses)

The current state of affairs is that a single successful attack against your system can be turned into a persistent compromise - even if you fix the original bug, your system is still under the control of the attacker. Secure Boot provides mechanisms to ensure that that's not true.

Just for the record, this claim for SecureBoot is patently incorrect. Any exploit of incorrectly handled persistent state (e.g. config or other policy files, hardware database files) will remain persistent, as discussed before.

The notion that these attacks can not affect early boot, and that we are capable of building a very small and near perfectly reliable "trusted" subset of the OS is highly, highly optimistic.

Practical security for 2014

Posted Jan 14, 2014 16:28 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (24 responses)

"Just for the record, this claim for SecureBoot is patently incorrect. Any exploit of incorrectly handled persistent state (e.g. config or other policy files, hardware database files) will remain persistent, as discussed before."

Nonsense, because Secure Boot ensures that we have a mechanism to perform updates of the affected components without having to parse that persistent data with vulnerable software.

Practical security for 2014

Posted Jan 14, 2014 16:42 UTC (Tue) by paulj (subscriber, #341) [Link] (23 responses)

Sure, if you know about the exploit. Are you claiming SecureBoot provides us with omniscience?

Even for known exploits, SecureBoot need not protect against it, because (for the umpteenth time), the binary that gets booted is but *part* of the input that determines the state of computation. The other parts are the non-code state, which is often modifiable, and is always key to any exploit.

E.g., it is quite plausible a kernel could have a bug that allows it to be subverted by reading a modified filesystem (to pick one kind of state kernels tend to have to parse), such as the one that the system resides on. Now riddle me this, where is your secure system to run your update code from?

Then there is the hypervisor attack, if your system was subverted before, how can code within it *ever again* reliably detect between running on metal and running in a hypervisor? I know you dismiss this as leading to user-detectable slowness but not everyone believes that (not all systems have local users, and someone here has already mentioned knowledge of in-the-wild hypervisor attacks).

Practical security for 2014

Posted Jan 14, 2014 16:44 UTC (Tue) by paulj (subscriber, #341) [Link] (11 responses)

(the answer to the riddle is, of course, that you have to boot from alternative, known good media with a fixed kernel - just like before, despite SecureBoot).

Practical security for 2014

Posted Jan 16, 2014 14:27 UTC (Thu) by pjones (subscriber, #31722) [Link] (10 responses)

The part you've missed is that it's possible to create a persistent exploit across *reinstalls* without Secure Boot. In that case, known good media will not help you. With Secure Boot it will.

Practical security for 2014

Posted Jan 16, 2014 14:34 UTC (Thu) by paulj (subscriber, #341) [Link] (9 responses)

What type of exploit would persist across a reinstall without SecureBoot, yet not with?

Practical security for 2014

Posted Jan 16, 2014 17:42 UTC (Thu) by pjones (subscriber, #31722) [Link] (8 responses)

So the basic principle is that a rootkit installs itself as the bootloader and replaces the firmware interfaces with its own copies. Those interfaces would appear to be the same as the original ones, except they'd hide the "bootkit" from you, and present what appears to be a pristine machine to do an installation on.

It really isn't /that/ much code on a UEFI machine. You have to replace GetVariable(), SetVariable(), and GetNextVariableName() with wrappers that hide your boot entries, and you have to wrap the BlockIo driver (i.e. the block device driver in UEFI) that the EFI System Partition is being read with, so as to hide the real boot device your exploit is booting off of. The harder part is hiding it from the OS, but that's still entirely possible, since you can intercept the OS as it is loaded.

This sort of thing isn't new any more; with relatively low levels of sophistication these kinds of "bootkits" already exist. Secure Boot stops this attack.

Practical security for 2014

Posted Jan 16, 2014 17:52 UTC (Thu) by paulj (subscriber, #341) [Link] (7 responses)

Why would a reinstall not reinstall the bootloader, or at least verify what it is? That's only a part-reinstall, and yes, of course, that would leave the system vulnerable - agreed.

Practical security for 2014

Posted Jan 16, 2014 18:06 UTC (Thu) by pjones (subscriber, #31722) [Link] (5 responses)

The whole point is that when it reinstalls the boot loader and sets a new boot order, it's telling the "bootkit" code the new boot order, rather than the real system firmware. The bootkit code is then able to persist in the boot path in front of the newly installed OS.

Practical security for 2014

Posted Jan 16, 2014 19:01 UTC (Thu) by paulj (subscriber, #341) [Link] (4 responses)

Ah, I see. That stems then from a choice made to have UEFI services remain resident and overrideable, it seems. SecureBoot could make that secure, or you could avoid relying on code in the system, mutable by prior boots (as was my point ;) ).

Practical security for 2014

Posted Jan 16, 2014 20:13 UTC (Thu) by raven667 (subscriber, #5198) [Link] (3 responses)

That particular method of causing a rootkit to persist is not unique to uEFI and is has been done with BIOS for some time now. The next version of that kind of exploit is probably going to be centered around device firmware (running on the device, not device driver uEFI modules running on the CPU) rather than modifying the uEFI firmware, if uEFI firmware becomes difficult to modify remotely.

Practical security for 2014

Posted Jan 16, 2014 22:35 UTC (Thu) by paulj (subscriber, #341) [Link] (2 responses)

If I understand pjones correctly, the persistent attack in the UEFI services override case is from a disk-loaded bootloader.

In the BIOS case, at least for a long time, the BIOS EPROM was hardware write-protectable (I suspect the motivation there was more for board makers to minimise returns due to kiddies needlessly updating it than security), and the BIOS could be set to run directly from the ROM. Not bad protection. Booting from alternative media couldn't be bypassed by a bootloader on disk with a write-protected BIOS EPROM.

Without write-protection of the firmware, you're hosed, I completely agree! :)

I agree SecureBoot can give you sufficient write-protection. However, I dislike that it won't necessarily be me who says what can be written. I prefer a write-protect system that can't possibly be under anything but my control.

(To make this easy, the BIOS blobs often had a well-defined structure, and it was possible to unpack them and add your own code in - the old Award BIOS certainly did. Then there was some kind of PC convention to allow option ROMs to be recognised via some magic number, and entry points automatically get called. I forget the details, but I did this once to stuff PXE-capable etherboot code for my for my option-ROM-less NIC into my BIOS as an option ROM, so I could still get a network boot ;). This kind of firmware hacking is now disallowed with SecureBoot, isn't it?).

Practical security for 2014

Posted Jan 17, 2014 16:30 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

> I agree SecureBoot can give you sufficient write-protection.

Then I'm not sure what we've been talking about because it seems like you agree.

> However, I dislike that it won't necessarily be me who says what can be written. I prefer a write-protect system that can't possibly be under anything but my control.

SecureBoot is under control of the person at the console, it can be disabled or have keys added or removed. I think for the purposes of our discussion the fact that some vendors produce boot locked hardware (Apple IOS devices, MS WinRT and WinPhone, many Android, Tivo, etc.) just doesn't exist in our universe because that's not a general purpose computer and isn't running Fedora or whatever. The fact that SecureBoot is more like the Chromebook model, where you can run a factory-signed image, or you can take control and run whatever you want, however you want, except in the SecureBoot model, we can continue to use the security infrastructure to provide integrity checks on boot.

Practical security for 2014

Posted Jan 17, 2014 16:47 UTC (Fri) by paulj (subscriber, #341) [Link]

Initially I did not agree SecureBoot provided the same security as booting from alternative, good media because I had never heard of this network-boot check thing which Matt described in the comments that it is still to be implemented. The article covering Matt's talk doesn't mention it, so I guess it wasn't a widely known issue (?). Once that's implemented I agree it potentially could provide the same guarantees. However, it's also possible there'll be practical issues that might affect that. We'll have to see.

As SecureBoot distro implementations stand today though, they're do not stop all persistent attacks.

Practical security for 2014

Posted Jan 16, 2014 20:09 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I think you have far more faith in a compromised machine than what the SecureBoot people do.

Practical security for 2014

Posted Jan 14, 2014 16:48 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (10 responses)

"Sure, if you know about the exploit. Are you claiming SecureBoot provides us with omniscience?"

No, but in general actively exploited vulnerabilities get noticed.

"Now riddle me this, where is your secure system to run your update code from?"

It boots a kernel that doesn't have that bug. Really, this isn't difficult.

"if your system was subverted before, how can code within it *ever again* reliably detect between running on metal and running in a hypervisor?"

How did you get the bootloader to launch an unsigned hypervisor?

Practical security for 2014

Posted Jan 14, 2014 16:56 UTC (Tue) by paulj (subscriber, #341) [Link] (9 responses)

And how do you reliably install that fixed kernel from code running within a subverted system?

Are you saying end-users will be banned from running their own hypervisors under SecureBoot? Are hyper-visors going to go the way of kexec?

Also, if a kernel has a boot-time subvertable bug, how do you stop an attacker loading a hypervisor with that subversion?

Practical security for 2014

Posted Jan 14, 2014 17:09 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (8 responses)

"And how do you reliably install that fixed kernel from code running within a subverted system?"

The bootloader downloads and boots a fixed kernel. The bootloader is signed, so subverting the bootloader is difficult.

"Are you saying end-users will be banned from running their own hypervisors under SecureBoot? Are hyper-visors going to go the way of kexec?"

No, I'm saying that trivial hypervisors such as Blue Pill won't run under Secure Boot. Migrating a running system to something like KVM or Hyper-V is impractical.

"Also, if a kernel has a boot-time subvertable bug, how do you stop an attacker loading a hypervisor with that subversion?"

You don't, which is why your security upgrade mechanism shouldn't use that kernel.

Practical security for 2014

Posted Jan 14, 2014 17:25 UTC (Tue) by paulj (subscriber, #341) [Link] (5 responses)

Aha, so the bootloader has to do the updating now? Is that possible today with any Linux distro?

So now we need bootloaders with support for at least HTTP. It'll also need to store state somewhere for at least some basic config for network and distro parameters. At least some of those parameters will need to be validated somehow.The bootloader has to have what will likely be the exact same filesystem code (the bootloader-system-update may well be a special Linux system).

This isn't really getting any simpler, is it? :)

(This reminds me of Suns' "WANBoot", which was a bit of a beast last time I tangled with it.).

Practical security for 2014

Posted Jan 14, 2014 17:38 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (4 responses)

"Is that possible today with any Linux distro?"

Currently? No. But it's possible, which it wouldn't be without Secure Boot.

"So now we need bootloaders with support for at least HTTP."

Which we already have.

"It'll also need to store state somewhere for at least some basic config for network and distro parameters."

In most cases that's going to just be built into the bootloader, but it could be overridden via EFI variables.

"The bootloader has to have what will likely be the exact same filesystem code"

The bootloader doesn't need to touch any filesystems for this.

"This isn't really getting any simpler, is it? :)"

Yes, it is.

Practical security for 2014

Posted Jan 14, 2014 17:51 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

You think network boot isn't possible without SecureBoot? (Fairly sure some systems have jumper write-protectable CMOS for boot order btw).

How are you going to protect the state in those EFI variables btw?

(I mentioned Solaris WANboot before, and securing it was a major PITA, AFAIR).

Practical security for 2014

Posted Jan 14, 2014 18:12 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

Network boot is possible without Secure Boot, but you'd need infrastructure to support that network boot (which most consumers won't have) and you'd need a mechanism to ensure that system configuration can't be modified (I've never seen a system that had hardware protection for CMOS - there's no trivial way to implement that in most cases).

Boot-services EFI variables can't be modified at runtime.

Practical security for 2014

Posted Jan 14, 2014 17:52 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

Why does the bootloader not need to touch the filesystem? I thought the point was to update the system on filesystem?

Practical security for 2014

Posted Jan 14, 2014 18:09 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

You wouldn't do the actual update from the bootloader, the bootloader would simply be the trusted mechanism for obtaining a known-good kernel and initramfs for performing the actual update.

Practical security for 2014

Posted Jan 17, 2014 23:52 UTC (Fri) by Jandar (subscriber, #85683) [Link] (1 responses)

> Migrating a running system to something like KVM or Hyper-V is impractical.

The hypervisor jailhouse does such a migration from a running system as described in LWN.

Practical security for 2014

Posted Jan 18, 2014 21:59 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

If you're migrating the running kernel as well as the running OS, it's not a problem.

Practical security for 2014

Posted Jan 14, 2014 16:26 UTC (Tue) by PaXTeam (guest, #24616) [Link] (25 responses)

> Does Secure Boot provide a mechanism for doing so? Yes.

for all the discussions that took place over the past year and more, you have yet to prove this. in fact many people showed you how false that claim is.

Practical security for 2014

Posted Jan 14, 2014 16:32 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (24 responses)

Add a boot-services variable that contains a date. On boot, if still in the secure environment, perform DHCP and call out to a remote server. If the returned value is a date more recent than the date in the variable, download a set of files, verify them and boot them rather than anything on disk. Permit them to install updates. That way you can run a set of upgrades without relying on anything on the local system other than the bootloader, which means you can fix any vulnerabilities that are being used to create a persistent exploit. Without Secure Boot the attacker simply replaces the bootloader in order to disable this functionality.

Practical security for 2014

Posted Jan 14, 2014 16:46 UTC (Tue) by paulj (subscriber, #341) [Link] (4 responses)

Wow, this SecureBooting gets more and more complicated! How do I SecureBoot the DHCP server btw?

Practical security for 2014

Posted Jan 14, 2014 16:49 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (3 responses)

Your counterargument now involves an attacker being able to compromise your DHCP server in addition to your system, and you *don't* think there's any additional security there?

Practical security for 2014

Posted Jan 14, 2014 17:04 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

There is additional security, if you assume the security of the DHCP server is independent of the security of the subverted DHCP client. This is not always the case, particularly when they're both the same OS - in that case, the subversion of the client may mean the DHCP server is prone to the exact same subversion!

The boot from known-good, known-fixed media has far less complexity and is far more reliable.

Practical security for 2014

Posted Jan 14, 2014 17:12 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (1 responses)

"if you assume the security of the DHCP server is independent of the security of the subverted DHCP client"

Which ought to be a pretty safe assumption - the only network-facing code they should have in common is the kernel, and if your DHCP server has remotely-exploitable kernel vulnerabilities then you're already having a bad time.

"The boot from known-good, known-fixed media has far less complexity and is far more reliable."

And involves physical intervention every time you want to perform a security update. Good luck selling that idea.

Practical security for 2014

Posted Jan 14, 2014 17:44 UTC (Tue) by paulj (subscriber, #341) [Link]

And involves physical intervention every time you want to perform a security update. Good luck selling that idea.

Not every time. Only for updates that are known to require it. And your answers on the benefits of SecureBoot all have assumed that the impact of the exploit is known. We're talking about a small subset of all updates.

I've worked in or with a number of different corporate setups over the years, from small, to medium, to global, with various mixes of proficiencies. Even with the one corporate that was extremely technically proficient and who defaulted to remote boot & management of computers, they still required on site tech for interventions, and they still couldn't always get remote boot & management to provide required flexibility or always work correctly. It turns out to require ongoing expertise - especially if you want Internet booting. This isn't cheap.

For quite a few small to medium corporates I've seen, having local hands to intervene is *cheaper* than hiring in people sufficiently expert to make remote boot work well. Those local hands will already be there! Indeed, in an era of cut-backs, it may be the lesser-skilled "hands on" IT people who are less likely to be chopped than the network/server experts. The former will *always* be required, while the functions of the latter can increasingly be outsourced (Google Apps, etc).

Setting up & maintaining complex remote boot and update systems that may require knowing how to generate & sign SSL certs, versus inserting a USB stick in each computer, on the rare occasion. The former is not automatically cheaper in terms of labour than the latter, from what I have observed in business. The opposite in fact, by far the opposite.

Practical security for 2014

Posted Jan 14, 2014 17:30 UTC (Tue) by PaXTeam (guest, #24616) [Link] (18 responses)

and how is this elaborate scheme, bleeding from so many wounds, "making it significantly more difficult for an attacker to engineer a persistent compromise of a system"? it seems to me that we have very different ideas about what 'significantly' and 'persistent compromise' mean. maybe elaborate on yours?

also downloading GBs worth of data of an entire OS on each boot will surely do wonders on the corporate or home LAN never mind the internet if you were so brave to trust that. and then there're those pesky users who don't always have the luxury of a network connection, i guess they just should not reboot, did i get that right? ;)

next, i don't need secureboot to boot off a trusted medium (smart users of whole disk encryption have always been doing just that in fact).

next, how do you download fixes for vulnerabilities that noone knows about?

Practical security for 2014

Posted Jan 14, 2014 18:08 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (17 responses)

Without Secure Boot, is it trivial to elevate myself from root to a configuration where the system is (a) still compromised after a reboot without any further action on behalf of the attacker, and (b) impossible to recover without booting from external media? Yes. If I control the MBR, I control the entire OS.

With Secure Boot, things are more complicated. An attacker can't just replace the underlying boot components. And I now have a trusted environment that I can use to verify the system or perform updates without relying on the underlying system being in a good state.

This doesn't require transferring gigabytes of data. In most cases it'd be a single callout followed by a normal boot. In the worst case it'll be on the order of 20-30MB, plus the updates that you'd need to download anyway.

But yes, obviously, this isn't perfect. More work needs to be done to continue to improve overall system security. However, unless you're willing to go to lengths that are impractical in most deployments, you just can't implement anything like this without Secure Boot.

Practical security for 2014

Posted Jan 14, 2014 18:20 UTC (Tue) by paulj (subscriber, #341) [Link] (8 responses)

If your system is compromised, you don't have a trusted environment. You have a compromised environment that can tell your software anything.

Your counter-point to that depends on setting up some remote boot thing, which doesn't exist today and the ease-of-setup of which is unknown. If there's any setup required that's anything on the level of PXE booting or (heaven help us) WANBoot, then it'll be beyond a lot of lesser-skilled IT departments. In which USB stick / CDROM will be much easier, and SecureBoot didn't help.

Practical security for 2014

Posted Jan 14, 2014 18:26 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (7 responses)

"If your system is compromised, you don't have a trusted environment."

Yes, you do. The pre-boot environment is signed, trusted code with a sufficiently small attack surface that it's practical to audit.

"If there's any setup required that's anything on the level of PXE booting or (heaven help us) WANBoot, then it'll be beyond a lot of lesser-skilled IT departments."

Right, so there should be zero setup required, modulo privacy concerns that might require this to be opt-in. And, really, let's not focus on scenarios where you even have an IT department. Providing improved security for users who *don't* have professional security support is a significant win.

Practical security for 2014

Posted Jan 14, 2014 19:42 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

This kind of thing has already been done on EFI firmware on Apple hardware which can download the whole installer image and re-image a machine over wired or wireless without touching the local disk and is sufficiently user-friendly to be deployed to users without local IT support.

So just do that then. uEFI is a whole level beyond what PXE offers.

Practical security for 2014

Posted Jan 14, 2014 20:50 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

The downside is that baking it into the firmware (as Apple have done) means it's not generalisable to other operating systems. Pushing it into the bootloader provides that extra flexibility, but then you need to trust your bootloader and hence Secure Boot.

Practical security for 2014

Posted Jan 14, 2014 22:32 UTC (Tue) by paulj (subscriber, #341) [Link] (4 responses)

The pre-boot environment is signed, trusted code with a sufficiently small attack surface that it's practical to audit.

So two things:

a) So SecureBoot of the main OS was irrelevant then, wasn't it? You've fallen back to booting some other system...

b) I'd be sceptical on that claim that this environment is small and auditable. Havn't looked at Intels' EFI sources - but how large are they, and have they actually been audited? GRUB and GRUB2 are also fairly hefty codebases and I doubt EFI would be any different, would it¹? If this network-update boot environment is written predominantly in C, and not written with validatable reliability as the first priority (rarely the case), I really wouldn't want to bet against someone with experience finding exploitable holes in O(days) of work².

I really do wonder if you're underestimating just how buggy system software is, even when written by *good* programmers and/or how easy it is for good security people to find ways to own code. You seem to have a *lot* more faith in the reliability of code than I have. But hey... ;)

1. Actually, let me dig up some numbers. For the Tianacore EDKII, generated using David A. Wheeler's sloccount tool:


$ sloccount *
SLOC    Directory       SLOC-by-Language (Sorted)
600279  AppPkg          python=307690,ansic=292182,sh=407
213296  MdeModulePkg    ansic=210473,asm=2823
168207  EdkCompatibilityPkg ansic=140935,asm=17304,cpp=9919,pascal=49
160968  BaseTools       python=76701,ansic=73142,cpp=11091,sh=34
92118   MdePkg          ansic=84247,asm=7871
65831   IntelFrameworkModulePkg ansic=65388,asm=443
63116   NetworkPkg      ansic=63116
61390   StdLib          ansic=61152,asm=140,pascal=98
57635   ShellPkg        ansic=57635
35800   SecurityPkg     ansic=35744,asm=56
33184   DuetPkg         ansic=19542,asm=13262,sh=380
22985   ArmPkg          ansic=16316,asm=6563,pascal=106
19393   OvmfPkg         ansic=18619,asm=379,python=206,sh=189
19157   EmulatorPkg     ansic=16516,asm=2445,sh=196
17699   EmbeddedPkg     ansic=17389,asm=310
17380   ArmPlatformPkg  ansic=13388,asm=2446,pascal=823,python=638,sh=85
15748   OptionRomPkg    ansic=15748
15014   Nt32Pkg         ansic=14929,asm=85
9418    IntelFrameworkPkg ansic=9418
8022    UefiCpuPkg      ansic=5996,asm=1863,python=117,pascal=46
7464    CryptoPkg       ansic=7300,asm=93,sh=71
6493    SourceLevelDebugPkg ansic=5153,asm=1340
6181    Omap35xxPkg     ansic=6181
5339    PcAtChipsetPkg  ansic=5117,asm=222
2311    BeagleBoardPkg  ansic=2031,asm=185,sh=95
1699    PerformancePkg  ansic=1699
1288    StdLibPrivateInternalFiles ansic=1288
18      top_dir         sh=18
0       Conf            (none)
0       EdkShellBinPkg  (none)
0       EdkShellPkg     (none)
0       FatBinPkg       (none)
0       ShellBinPkg     (none)
0       UnixPkg         (none)


Totals grouped by language (dominant language first):
ansic:      1260644 (72.98%)
python:      385352 (22.31%)
asm:          57830 (3.35%)
cpp:          21010 (1.22%)
sh:            1475 (0.09%)
pascal:        1122 (0.06%)

$ sloccount MdeModulePkg/Universal
SLOC    Directory       SLOC-by-Language (Sorted)
40874   Network         ansic=40874
10218   HiiDatabaseDxe  ansic=10218
9862    Console         ansic=9862
9061    SetupBrowserDxe ansic=9061
6258    Acpi            ansic=5978,asm=280
5035    Variable        ansic=5035
4555    EbcDxe          ansic=4141,asm=414
4402    DisplayEngineDxe ansic=4402
3607    Disk            ansic=3607
3564    PCD             ansic=3564
2866    DebugSupportDxe asm=2070,ansic=796
2619    FaultTolerantWriteDxe ansic=2619
2273    PlatformDriOverrideDxe ansic=2273
1514    DriverSampleDxe ansic=1514
1360    CapsulePei      ansic=1360
771     MemoryTest      ansic=771
750     StatusCodeHandler ansic=750
697     SmbiosDxe       ansic=697
650     DebugPortDxe    ansic=650
629     ReportStatusCodeRouter ansic=629
335     CapsuleRuntimeDxe ansic=335
289     LockBox         ansic=289
182     FaultTolerantWritePei ansic=182
169     PcatSingleSegmentPciCfg2Pei ansic=169
145     LegacyRegion2Dxe ansic=145
121     WatchdogTimerDxe ansic=121
114     MonotonicCounterRuntimeDxe ansic=114
98      ResetSystemRuntimeDxe ansic=98
97      HiiResourcesSampleDxe ansic=97
77      SecurityStubDxe ansic=77
72      DevicePathDxe   ansic=72
70      TimestampDxe    ansic=70
52      Metronome       ansic=52
35      PrintDxe        ansic=35


Totals grouped by language (dominant language first):
ansic:       110657 (97.56%)
asm:           2764 (2.44%)

The AppPkg directory probably can be ignored, some example apps and a python interpreter, from a glance. Still, it does look like there's a hefty amount of non-trivial code, including hand-crafted, raw pointer, network protocol and disk format parsers amongst other things. Only a quick look at a couple of files, but it looks like fairly traditional C, that is historically known to result in lots and lots of security bugs, even when from the hands of the best programmers.

2. And note that someone finding an exploitable bug does not imply that knowledge will get to someone interested in fixing it any time soon. Sometimes I suspect the number of capable people looking for security problems greatly outnumbers those fixing them!

Practical security for 2014

Posted Jan 14, 2014 22:54 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (3 responses)

There's certainly plenty of code in the UEFI codebase, and a lot of it's certainly going to contain bugs. But very little of it handles untrusted input, and those paths have been audited much more heavily than the rest of the codebase.

Practical security for 2014

Posted Jan 14, 2014 22:57 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

What do you define as trusted v untrusted input? Remember, we're talking about a system which, in the previous boot, was subverted. Any and all state which that system could have modified can not be trusted any more (files, file system meta-data, etc).

Practical security for 2014

Posted Jan 14, 2014 22:58 UTC (Tue) by paulj (subscriber, #341) [Link]

Oh, and also, you're proposing to use the Internet to download stuff. So the network protocols in your trusted environment also need to be reliably free of bugs (IP, perhaps some ICMP, UDP, DHCP, TCP and HTTP, maybe more).

Practical security for 2014

Posted Jan 14, 2014 23:00 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

Untrusted input is anything that cannot be proved to be trusted, so includes things like the PE/COFF binaries themselves (but not the executable code within), partition tables, the contents of the EFI system partition and so on.

Practical security for 2014

Posted Jan 14, 2014 22:00 UTC (Tue) by PaXTeam (guest, #24616) [Link] (7 responses)

> If I control the MBR, I control the entire OS.

not true at all. if this is the raison d'etre of this whole secureboot business then it failed right there.

> With Secure Boot, things are more complicated.

complicated - definitely. more secure - no proof for that.

> An attacker can't just replace the underlying boot components.

1. why would the attacker do that? (remember how i asked you for your understanding of 'persistent compromise'? there was a reason to that and you carefully avoided answering it.)

2. what 'boot components'? secureboot doesn't protect a plurality of them, it claims to provide 'something' (you called it 'significant' improvement in security) for one specific file *only*. *you* made claims that this was enough to ensure/derive this 'something' for further components (whatever they may be, we have yet to learn how much a 'persistent compromise' entails in your world ;).

> And I now have a trusted environment[...]

no you don't unless you want to redefine 'environment' as that one file that secureboot does 'something' for. in my world everything else is part of the environment and secureboot doesn't do 'something' for them.

> This doesn't require transferring gigabytes of data.

this comes down to that one question you so didn't want to answer so far. please, work that out first because everything seems to rest on it. what amount of data your scheme would require to be transferred depends specifically on how much data a 'persistent compromise' would potentially affect (and this is a trick question as the better persistent compromises in the real world don't even modify existing files so there would be nothing to restore, then what... ;). so far you seem to be going on an angle that this is something small whereas real life evidence and attacker creativity shows the exact opposite.

> However, unless you're willing to go to lengths that are impractical in most deployments,
> you just can't implement anything like this without Secure Boot.

what are all these impractical approaches 'in most deployments'? and what secureboot actually does is yet to be determined, so let's not use that as an argument for 'this is how security should be done' because so far all i saw was snakeoil and false sense of security.

Practical security for 2014

Posted Jan 14, 2014 22:46 UTC (Tue) by dlang (guest, #313) [Link]

Well, if you were to go all out on this the way Tivo does (queue hissing at evil company :-), you could be secure.

Tivo has the firmware check the signature of the kernel + initfs image, that filesystem then checks that the main OS hasn't been tampered with (nothing added, nothing removed, no changes)

But unless you are willing to lock a system down that far, which makes it unusable for anything other than an appliance, you aren't going to succeed

And even with a tivo-style lockdown, it only takes one flaw somewhere to let people in.

Practical security for 2014

Posted Jan 14, 2014 22:47 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (4 responses)

>> If I control the MBR, I control the entire OS.
>not true at all. if this is the raison d'etre of this whole secureboot business then it failed right there.

Wait. You're saying that if an attacker can install something into the MBR, they *don't* control the entire OS? That can't be what you mean.

I'm defining a persistent compromise as any attack that, without further action on the part of the attacker, will persist over system reboots and will not be removed by the standard security update mechanism (either because it's at a layer that security updates won't touch or because it's subverted or disabled the security update mechanism).

So let's assume that your system has been subject to an attack that has succeeded in installing such a persistent compromise. If it's sufficiently well written, the installed OS can no longer be trusted to give you reliable and accurate information regarding the contents of the drive or the running processes. You need to have some verified external environment to do this.

Booting from known-good media is one way to achieve this, but it requires physical presence and for you to have known-good media in the first place - most users are never going to go to the trouble. Worse, there's no easy way for the OS vendor to provide updates to said known-good media in order to automatically detect newly identified infections.

Secure Boot allows you to implement a mechanism in which you can define a policy to control whether or not the system downloads a small signed environment from your OS vendor and boots that rather than any OS on local storage. This is then able to perform updates (mitigating any persistent compromises that are implementing persistence by exploiting vulnerabilities in system components on each boot) and scan for fingerprints of other known compromises.

This obviously doesn't protect against unknown vulnerabilities or highly targeted attacks. That doesn't mean it's not an improvement. It would handle the majority of mass infections of home systems, which seems like something meaningful.

Practical security for 2014

Posted Jan 14, 2014 23:04 UTC (Tue) by paulj (subscriber, #341) [Link] (3 responses)

How often will you run this network-booted system checker? Every boot? Every week? Every month? Every year? It's going to be at least a few tens of MB in size amd take a noticeable amount of time to download over over-subscribed DSL links when they go to catch up on kitten pics in the evening when they've gotten home.

Home users are going to love this feature!

Practical security for 2014

Posted Jan 14, 2014 23:20 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (2 responses)

Whenever there's a vulnerability that's known to be actively exploited.

Practical security for 2014

Posted Jan 15, 2014 8:14 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Which you can only check from this "secure" bootloader. So this won't work reliably and automatically for systems rarely rebooted (the system may be subverted to ignore any software update instructions to reboot).

Let's check back in a year or three and see if any distros have actually implemented anything like what you've described, and see what the practicalities of it are.

Practical security for 2014

Posted Mar 22, 2023 10:39 UTC (Wed) by paulj (subscriber, #341) [Link]

Checking back. None of this is implemented.

Practical security for 2014

Posted Jan 15, 2014 21:02 UTC (Wed) by nix (subscriber, #2304) [Link]

False sense of security? SecureBoot doesn't even provide *that*. What it provides to me is a true sense of *dread*, dread in the sense of 'this machine will be hell to set up and if I can't get SecureBoot to go away forever will be hell to upgrade every time as well'.

Practical security for 2014

Posted Jan 14, 2014 19:10 UTC (Tue) by hummassa (guest, #307) [Link]

> the set of actively exploited bugs tends to be bounded

Garrett, I respect you immensely, but WRT secure boot, your whole argument seems to rest on this premise... which I deeply doubt is true. Anyway, as secure boot is something that did not exist before and as the rest of your argument is voided if in fact (as I suspect) the set of actively exploited bugs is unbounded (Snowden documents, anyone?), it seems to me that the burden of proving this premise should be yours.