Practical security for 2014 [LWN.net]

Practical security for 2014

Posted Jan 14, 2014 17:30 UTC (Tue) by PaXTeam (guest, #24616)
In reply to: Practical security for 2014 by mjg59
Parent article: Practical security for 2014

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?

to post comments

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