Practical security for 2014 [LWN.net]

Practical security for 2014

Posted Jan 16, 2014 15:32 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: Practical security for 2014 by paulj
Parent article: Practical security for 2014

No, it has a flash write protect jumper. It has nothing to protect the CMOS. How would you write-protect the CMOS? The clock needs access to it.

to post comments

Practical security for 2014

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

No, I didn't mean the flash write protect jumper. It also has:

Setup Enable--J9E2

This jumper controls whether the CMOS Setup program can be run.

Pins 1-2 covered: users can run Setup. Access to CMOS is allowed
Pins 2-3 covered: Setup is disabled. Access to CMOS is provided

Whether that actually did electrically write-protect CMOS setup variables, I don't know. However, I don't think it's completely impossible to do so, while leaving the CMOS clock NVRAM writeable.

Practical security for 2014

Posted Jan 16, 2014 16:56 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (33 responses)

No, it simply disabled the hotkey→BIOS setup tool functionality. You'd still be able to modify CMOS contents through software.

"However, I don't think it's completely impossible to do so, while leaving the CMOS clock NVRAM writeable."

It's amazingly tedious having a conversation with someone who would prefer to discuss how they imagine the world works instead of spending some time figuring out how the world actually works. The datasheets for the RTC CMOS in Intel chipsets are publicly available. There's no write-protect bit or line.

Practical security for 2014

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

Well, given there's a long line of answers from you in this thread that assume the existence of a non-existent bootloader, I'm entitled to the same feeling of tedium I guess.

Practical security for 2014

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

Also, the board is an old 486 one. Boards then, as with my Abit, literally did have separate NVRAM on the board. Sheets for today's Intels chipsets with integrated NVRAM would not be relevant.

Practical security for 2014

Posted Jan 16, 2014 17:32 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (2 responses)

So look at the data sheet for a Dallas DS1387 and tell me how you'd implement a jumper that lets you write to the clock registers but not the rest of the CMOS registers.

Practical security for 2014

Posted Jan 16, 2014 18:00 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

At a glance, it seems to be trivial: have the jumper pull up ~WER. Shouldn't affect the RTC portion afaict.

Practical security for 2014

Posted Jan 16, 2014 18:03 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

WER is for the SRAM, not the CMOS. Boot order is stored in the CMOS. You could tie off WE instead, but now you can't update the clock registers either.

Practical security for 2014

Posted Jan 16, 2014 17:22 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (27 responses)

"Secure Boot is snakeoil" "Here's an example of how it can be used to provide a real improvement in security" "That can't possibly work because (spurious reasons based on an incomplete understanding of the problems, technology and incorrect beliefs about hardware)" look seriously what do you want? This functionality permits the creation of a secure mechanism for the validation and upgrading of user systems in the face of hostile code. The only alternative you've come up with involves read-only media and a CMOS-protection jumper that doesn't exist, which is clearly not practical for most home users.

Practical security for 2014

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

I had never read before, until the comments in this thread, that SecureBoot requires a network stage "phone home" bootloader, which has yet to be implemented, to reliably achieve a SecureBoot. I'm not sure that's general knowledge either, but perhaps I havn't been paying attention. If it wasn't, this thread has been useful in drawing that out of you, and expanding on the implications.

Thanks for the ad-homimen. However, you've no idea whether or not those old boards CMOS WP jumper did or did not protect the NVRAM. I don't have a map of NVRAM handy to tell for sure, but if there's a sufficient gap between the BIOS setup variables and the area the OS still must write to, then it would be electrically quite feasible to pull up or down relevant address lines according to a jumper to prevent that BIOS config data being written to. Your assertion that CMOS jumpers weren't practical for home users runs contrary to the reality that home computers for a long time *did* often require fiddling with jumpers - even if they're not desirable today.

Given you're allowed to rely on non-existent technology in your arguments, I don't see why I should be denied the same opportunity in mine. I personally would have much preferred a solution based on write-once or write-protectable media, with a physical write-protect switch somewhere (this is technologically trivial), to a solution that literally gives the keys to booting Linux to parties that are potentially hostile to the use of Linux.

You may assume that MS will never require SecureBoot in PCs (as is the case for UEFI ARM) in future, however I (and perhaps others) are not comfortable with that assumption. I'm allowed that.

Practical security for 2014

Posted Jan 16, 2014 18:01 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (25 responses)

"I don't have a map of NVRAM handy to tell for sure"

You could perform some minimal quantity of research and then you would be able to tell for sure?

"but if there's a sufficient gap between the BIOS setup variables and the area the OS still must write to, then it would be electrically quite feasible to pull up or down relevant address lines according to a jumper to prevent that BIOS config data being written to"

No, because the address and data lines are multiplexed and so you're (a) preventing *reading* from the protected addresses as well, and (b) you're corrupting data in the registers that you can access. Really. Please look at the data sheet, and then remember that you're still talking about hardware that hasn't shipped within the past 15 years because now it's all in the chipset and it's really awkward to try to tie jumpers to internal address lines on chips fabbed at 45nm.

You're right that the software I'm describing does not currently exist, but nor does the hardware you're describing. I can implement my solution and deploy it to millions of existing machines, thereby improving security over the status quo. You can't. And yes, you're right that it's possible that Secure Boot could be used to remove user freedom. But saying "The security benefits provided by Secure Boot do not outweigh the threat to user freedom" is an entirely different argument to "Secure Boot provides no security benefits". One is a matter of opinion based on your weighting of various threats. The other is simply wrong.

Practical security for 2014

Posted Jan 16, 2014 18:18 UTC (Thu) by paulj (subscriber, #341) [Link] (24 responses)

That isn't what I said.

I said SecureBoot provides no security benefits above boot from RO media, or boot from known-"good" media.

Where SecureBoot differs from that is in providing /selective/-write media, which has some practical benefits when it comes to distributing and installing without user-intervention, I'll agree (if indeed you make that network "phone home" stage work without fuss).

I don't think I'm wrong in that characterisation.

As for removing user freedom, SecureBoot *actively* does so by default. It does not trust the end-user by default, but only a select few entities. That's what the *selective* part inherently is all about. Most PCs have a way for now to allow a user to enroll their keys, but not all do - as nix commented. Whether this ability to enroll end-user keys and/or bypass SecureBoot will remain, we will see. However, undoubtedly, MS now have much greater control over what PCs will boot, and this wouldn't have been the case with a local-only, user-controlled solution.

We clearly disagree on assumptions about how the future will pan out, but I don't think the above is wrong.

Practical security for 2014

Posted Jan 16, 2014 18:25 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (23 responses)

"I said SecureBoot provides no security benefits above boot from RO media"

True, in the universe where you can ensure that you only boot from RO media. Which isn't this one. As a result, Secure Boot provides security benefits.

"Most PCs have a way for now to allow a user to enroll their keys, but not all do - as nix commented."

I have never seen a system that provides no mechanism for this[1] and I've seen no credible reports of them existing. If anyone believes otherwise, I'm happy to buy myself any hardware they claim lacks this functionality as long as they're willing to pay for it if it turns out they're wrong.

[1] The exception is some desktop boards produced between Secure Boot being specified and Microsoft's requirements for key management being published, but none of those boards enable Secure Boot by default so it's not an interesting case - you can just pretend that they don't implement it at all.

Practical security for 2014

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

Sorry, no. If we're restricted to the here and now, where RO-only media is subject to a boot-order attack, then SecureBoot as deployed today is also subject to re-subversion. That's precisely why you introduced that network boot-loader verify stage.

If the SecureBoot scenario can rely on not-implemented technology, then the RO-only media case also may do so¹.

Can you, using current technology, implement and roll out your network boot solution one day, I agree, probably yes. Will it provide the claimed security (assuming a reliable network)? Perhaps, that depends on the details, which remain to be seen. Have you fleshed them out in further detail anywhere, outside of this LWN comment thread?

As for the system that doesn't allow enrollment of user-keys, sorry, I misrepresented nix's problem. He just couldn't get SecureBoot to work with a distro, but it's not actually clear if he could have enrolled his own keys or not. It seems he chose not to bother with that because of the complexity of SecureBooting self-signed materials. However, I thought some vendor had a problem at some stage with their UEFI missing end-user enrollment functionality (was it Asus?). The exact size of the set of UEFI implementations with that problem is far from the main point though.

1. Or, old technology, with a little bit of active logic in front of the RTC chip to hold the write RTC lines down if the previous address cycle tried to access the upper-half of the RTC. Arguing about the exact minutiae of that isn't hugely helpful, except as some kind of cock-on-desk-slapping exercise. The point is, if a vendor of that logic wanted to provide a hardware switch WP functionality today, e.g. cause industry wanted it for security, it'd be trivial to add.

Practical security for 2014

Posted Jan 16, 2014 18:55 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (14 responses)

Again, Existing hardware Secure Boot provides all the infrastructure required to implement this functionality. Existing hardware does not provide the infrastructure required to implement secure boot from read-only media. If you can't see the difference between these two situations then there's really no point discussing it.

Practical security for 2014

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

I don't disagree with you on that.

However, the full security implications of your proposal will not be clear until it is actually implemented and used. Will it achieve the security goals you set for it? Possibly, but it's far from clear until fully realised and tested. I don't think any reasonable person could disagree with that.

Practical security for 2014

Posted Jan 17, 2014 16:48 UTC (Fri) by nix (subscriber, #2304) [Link] (12 responses)

Existing hardware does not provide the infrastructure required to implement secure boot from read-only media.

Thus neatly explaining why the livecd of the distro I tried to install in the post above UEFI-booted without a secure boot error, unlike everything UEFI-booted off the hard drive. Another irregularity exposed to end users but not documented anywhere they can see (not until this post of Matthew's, anyway).

Practical security for 2014

Posted Jan 17, 2014 17:01 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (11 responses)

Er. I think you've misunderstood what I said there. Secure Boot works fine from read-only media, but existing hardware provides no way for you to implement equivalent security using read-only media and no UEFI Secure Boot.

Practical security for 2014

Posted Jan 18, 2014 20:43 UTC (Sat) by nix (subscriber, #2304) [Link] (10 responses)

Ah. I did misunderstand. You're right that you can't ensure that your BIOS hasn't been reflashed by hostile parties without something like secure boot, but I'm somewhat unclear how secure boot can fix that, given that it's the BIOS that *implements* secure boot in the first place... surely a hostile BIOS can claim to be doing signature verification, and then, well, just not do it?

Practical security for 2014

Posted Jan 18, 2014 21:24 UTC (Sat) by paulj (subscriber, #341) [Link] (2 responses)

Many PC boards had electrically secure write-protect jumpers in EEPROM days. That's pretty damn secure. Indeed, I might have more faith in that than software signature schemes, depending on the scenario.

Practical security for 2014

Posted Jan 18, 2014 21:48 UTC (Sat) by paulj (subscriber, #341) [Link] (1 responses)

Oh, and how is UEFI firmware in flash is protected for updates? The trust anchor in SecureBoot is established by the firmware, right (not in the CPU)?

Practical security for 2014

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

The firmware verifies the update before flashing it. The SPI controller prevents the OS from writing to the flash.

Practical security for 2014

Posted Jan 18, 2014 21:39 UTC (Sat) by raven667 (subscriber, #5198) [Link] (1 responses)

Yes, absolutely, if someone intercepts your hardware and flashes a bogus UEFI that pretends, they could even add keys to SecureBoot to trust their bogus bootloader but that requires physical access and can't be done remotely by malware because the UEFI firmware will check the signature of any updates before applying them, a core feature of SecureBoot.

Practical security for 2014

Posted Jan 18, 2014 21:50 UTC (Sat) by paulj (subscriber, #341) [Link]

You're assuming the UEFI firmware, the reference implementation for which contains a fair amount of non-trivial C code, is free of exploitable defects.

Practical security for 2014

Posted Jan 18, 2014 22:02 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (4 responses)

It has nothing to do with modifying the BIOS. You can install a known good kernel on piece of read-only media and use that to boot the OS installed on your hard drive. I, as an attacker, can install an evil kernel and bootloader on your hard drive and then rewrite the CMOS settings to instruct your system to boot from the hard drive instead of the read-only media. The BIOS is entirely intact, it's just doing what it was told to do.

Practical security for 2014

Posted Jan 18, 2014 22:06 UTC (Sat) by paulj (subscriber, #341) [Link] (3 responses)

BTW, I've been trying to find which PC BIOS standard/convention required the BIOS boot-order config be in a known location in the NVRAM. Do you know where I can find that?

Practical security for 2014

Posted Jan 18, 2014 23:01 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (2 responses)

It's not in a fixed location, but there's a small number of firmware vendors and they tend to leave things in the same place over product releases. You can pull the firmware vendor out of DMI so it's trivial to automate it.

Practical security for 2014

Posted Jan 18, 2014 23:18 UTC (Sat) by paulj (subscriber, #341) [Link] (1 responses)

Yeah. Digging more, it seems the RTC and some of the slots immediately after it are "well-known", and the rest vary with BIOS vendor (and even the revision of BIOS). This seems one of the more comprehensive summaries:

http://oopweb.com/Assembly/Documents/InterList/Volume/CMO...

I've been trying to work out what the other half was for, the SRAM, and as far as I can work it seems that was used for ESCD and ISA PNPBIOS stuff.

Practical security for 2014

Posted Jan 18, 2014 23:19 UTC (Sat) by paulj (subscriber, #341) [Link]

err, s/ISA//.

Practical security for 2014

Posted Jan 17, 2014 16:46 UTC (Fri) by nix (subscriber, #2304) [Link]

FWIW, the year-and-a-half-old asus motherboard on the Ivy Bridge desktop I'm using right now has secure boot and no end-user key enrollment. However, it does have secure boot off by default (as Matthew said would be true for a desktop made in that time period), and it's easy to turn UEFI off too. So I have no real complaints on that score.

Practical security for 2014

Posted Jan 17, 2014 16:44 UTC (Fri) by nix (subscriber, #2304) [Link] (5 responses)

I have never seen a system that provides no mechanism for this[1] and I've seen no credible reports of them existing. If anyone believes otherwise, I'm happy to buy myself any hardware they claim lacks this functionality as long as they're willing to pay for it if it turns out they're wrong.
[1] The exception is some desktop boards produced between Secure Boot being specified and Microsoft's requirements for key management being published, but none of those boards enable Secure Boot by default so it's not an interesting case - you can just pretend that they don't implement it at all.

Well, yes. Every PC I have set up in the last two years (all three of them, I don't do this unless I must!) has had no way to enroll new keys that I could find, but has allowed you to boot in non-UEFI mode, if you could figure out how to do it past the appalling mistranslated English of the BIOS interface.

It is quite possible that the most recent one, probably made in the last six months (I set it up in November) did have a way to enroll keys, but I just couldn't find it because the BIOS setup translations were so bad. It had an option labelled "UEFI uefi enable" with the extra help description "enabling to enabling UEFI". It was off by default: to switch to BIOS booting, I had to turn it on. There was a secure boot option, which was on by default and was greyed-out so I couldn't turn it off, and what may have been a key enrollment facility which I couldn't figure out how to use because they hadn't bothered to translate it at all and it hit me with what I guess was Taiwanese! Unfortunately I didn't think to note down the vendor of this glorious piece of misdesign, I was too busy cursing it and trying to get my friend's brand new machine to boot at all.

Even once I'd taught the BIOS to boot without using the secure-boot-apparently-mandatory UEFI, I had to separately convince the Linux distro's setup program to write a BIOS bootloader rather than the UEFI bootloader it was insisting on writing out, which the BIOS then silently didn't use because it wasn't booting in UEFI mode except when booting off the distro's live CD: I note that when UEFI-booting off the CD it was apparently not using Secure Boot, but it didn't want to do that while UEFI-booting off the hard drive! (Of course, nothing anywhere in the Mint installer tells you which mode you've booted in or what sort of bootloader has just been written out, so it took me literally hours to figure out why my attempts to boot were still failing despite the distro having been allegedly installed. Maybe something in /sys tells you, I dunno. It is hardly made obvious anywhere. I suppose in the final-state world in which everyone uses UEFI and it works properly and doesn't get in your way, such an option would be pure noise. It very much isn't right now.)

This brave new world is not better than the old, unless you think this sort of downright stupid palaver is pleasant and expected when setting up new systems. Setting them up was very much easier three years ago than it is now. It's not secure boot itself getting in the way so much as really badly written and translated, pathologically unhelpful UEFI BIOSes, but would you trust the people who wrote that stuff to do anything security-related right? I wouldn't trust them to write 'hello world'.

Practical security for 2014

Posted Jan 17, 2014 16:58 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (2 responses)

Boards made more than a year ago are unlikely to implement Secure Boot at all, and certainly won't enable it by default - you wouldn't be able to install Windows 7 otherwise.

"I had to separately convince the Linux distro's setup program to write a BIOS bootloader rather than the UEFI bootloader"

Which distribution? The kernel won't provide UEFI functionality unless it's passed a pointer to the UEFI tables by the bootloader, and the only way that can happen is if you booted via UEFI. If there's a distribution that installs a UEFI bootloader even though it can't write to the UEFI boot variables, that's a criminally incompetent implementation and certainly a distribution bug. Or, alternatively, you're wrong when you claim that you booted via BIOS compatibility.

"It's not secure boot itself getting in the way so much as really badly written and translated, pathologically unhelpful UEFI BIOSes"

…and so entirely irrelevant to the discussion that we're actually having here?

Practical security for 2014

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

It sounded like the sequence of events was that he successfully installed a GPT partition and UEFI boot loader but then was unable to boot into it due to some UEFI problem, he then tried to re-install after reconfiguring the UEFI to boot in BIOS mode but the installer detected that he had a GPT partition and failed to install a BIOS compatible boot loader without some convincing and probably wiping the install and partition table.

Practical security for 2014

Posted Jan 18, 2014 20:38 UTC (Sat) by nix (subscriber, #2304) [Link]

Yes. (Actually the GPT partition was already there: the machine had a UEFI-booting Windows on it.)

Practical security for 2014

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

That sounds truly awful and that is not what I expect to be the norm. I figure the best effort is spent on making the reference design really work well and licensing it liberally, these small vendors aren't going to invest in writing their own if they can easily pick up one cheaply or for free. They differentiate in their awful UIs and not in the underlying components which actually do the work.

Practical security for 2014

Posted Jan 18, 2014 20:41 UTC (Sat) by nix (subscriber, #2304) [Link]

Agreed. However, if the UI is so bad that nobody can figure out how to use it unless they read zh_TW, I'm not sure it matters how good the underlying code is (except that it might be less likely to fail completely).