![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59PC World wrote an article on how the use of Intel Boot Guard by PC manufacturers is making it impossible for end-users to install replacement firmware such as Coreboot on their hardware. It's easy to interpret this as Intel acting to restrict competition in the firmware market, but the reality is actually a little more subtle than that.
UEFI Secure Boot as a specification is still unbroken, which makes attacking the underlying firmware much more attractive. We've seen several presentations at security conferences lately that have demonstrated vulnerabilities that permit modification of the firmware itself. Once you can insert arbitrary code in the firmware, Secure Boot doesn't do a great deal to protect you - the firmware could be modified to boot unsigned code, or even to modify your signed bootloader such that it backdoors the kernel on the fly.
But that's not all. Someone with physical access to your system could reflash your system. Even if you're paranoid enough that you X-ray your machine after every border crossing and verify that no additional components have been inserted, modified firmware could still be grabbing your disk encryption passphrase and stashing it somewhere for later examination.
Intel Boot Guard is intended to protect against this scenario. When your CPU starts up, it reads some code out of flash and executes it. With Intel Boot Guard, the CPU verifies a signature on that code before executing it[1]. The hash of the public half of the signing key is flashed into fuses on the CPU. It is the system vendor that owns this key and chooses to flash it into the CPU, not Intel.
This has genuine security benefits. It's no longer possible for an attacker to simply modify or replace the firmware - they have to find some other way to trick it into executing arbitrary code, and over time these will be closed off. But in the process, the system vendor has prevented the user from being able to make an informed choice to replace their system firmware.
The usual argument here is that in an increasingly hostile environment, opt-in security isn't sufficient - it's the role of the vendor to ensure that users are as protected as possible by default, and in this case all that's sacrificed is the ability for a few hobbyists to replace their system firmware. But this is a false dichotomy - UEFI Secure Boot demonstrated that it was entirely possible to produce a security solution that provided security benefits and still gave the user ultimate control over the code that their machine would execute.
To an extent the market will provide solutions to this. Vendors such as Purism will sell modern hardware without enabling Boot Guard. However, many people will buy hardware without consideration of this feature and only later become aware of what they've given up. It should never be necessary for someone to spend more money to purchase new hardware in order to obtain the freedom to run their choice of software. A future where users are obliged to run proprietary code because they can't afford another laptop is a dystopian one.
Intel should be congratulated for taking steps to make it more difficult for attackers to compromise system firmware, but criticised for doing so in such a way that vendors are forced to choose between security and freedom. The ability to control the software that your system runs is fundamental to Free Software, and we must reject solutions that provide security at the expense of that ability. As an industry we should endeavour to identify solutions that provide both freedom and security and work with vendors to make those solutions available, and as a movement we should be doing a better job of articulating why this freedom is a fundamental part of users being able to place trust in their property.
[1] It's slightly more complicated than that in reality, but the specifics really aren't that interesting.
UEFI Secure Boot as a specification is still unbroken, which makes attacking the underlying firmware much more attractive. We've seen several presentations at security conferences lately that have demonstrated vulnerabilities that permit modification of the firmware itself. Once you can insert arbitrary code in the firmware, Secure Boot doesn't do a great deal to protect you - the firmware could be modified to boot unsigned code, or even to modify your signed bootloader such that it backdoors the kernel on the fly.
But that's not all. Someone with physical access to your system could reflash your system. Even if you're paranoid enough that you X-ray your machine after every border crossing and verify that no additional components have been inserted, modified firmware could still be grabbing your disk encryption passphrase and stashing it somewhere for later examination.
Intel Boot Guard is intended to protect against this scenario. When your CPU starts up, it reads some code out of flash and executes it. With Intel Boot Guard, the CPU verifies a signature on that code before executing it[1]. The hash of the public half of the signing key is flashed into fuses on the CPU. It is the system vendor that owns this key and chooses to flash it into the CPU, not Intel.
This has genuine security benefits. It's no longer possible for an attacker to simply modify or replace the firmware - they have to find some other way to trick it into executing arbitrary code, and over time these will be closed off. But in the process, the system vendor has prevented the user from being able to make an informed choice to replace their system firmware.
The usual argument here is that in an increasingly hostile environment, opt-in security isn't sufficient - it's the role of the vendor to ensure that users are as protected as possible by default, and in this case all that's sacrificed is the ability for a few hobbyists to replace their system firmware. But this is a false dichotomy - UEFI Secure Boot demonstrated that it was entirely possible to produce a security solution that provided security benefits and still gave the user ultimate control over the code that their machine would execute.
To an extent the market will provide solutions to this. Vendors such as Purism will sell modern hardware without enabling Boot Guard. However, many people will buy hardware without consideration of this feature and only later become aware of what they've given up. It should never be necessary for someone to spend more money to purchase new hardware in order to obtain the freedom to run their choice of software. A future where users are obliged to run proprietary code because they can't afford another laptop is a dystopian one.
Intel should be congratulated for taking steps to make it more difficult for attackers to compromise system firmware, but criticised for doing so in such a way that vendors are forced to choose between security and freedom. The ability to control the software that your system runs is fundamental to Free Software, and we must reject solutions that provide security at the expense of that ability. As an industry we should endeavour to identify solutions that provide both freedom and security and work with vendors to make those solutions available, and as a movement we should be doing a better job of articulating why this freedom is a fundamental part of users being able to place trust in their property.
[1] It's slightly more complicated than that in reality, but the specifics really aren't that interesting.
Who cares?
Date: 2015-08-04 07:29 am (UTC)Re: Who cares?
Date: 2015-09-03 11:33 pm (UTC)Who cares? Only those who see the benefit in open source operating systems, utilities and support FSF/OSF. Forgetting cost, they want the freedom to be able to study how and what a program/operating system is actually doing - with their personal information and data. And those who aren't in love with the Microsoft/NSA relationship - closed operating source so no audit on what Microsoft could/does plant in the code.
Being able to have an open source BIOS, while important, is only the side issue here. The issue is closed hardware that contains a significant amount of, for lack of a better term, execution time code - code different to that implementing basic hardware instruction set and function. The issue is the Intel ME. Both the dedicated hardware and the encrypted blob (code) that it runs. Perhaps in its early incarnations were acceptable but in later Intel chipsets the ME hardware and software cannot be disabled. From Igor Skochinsky's paper:
. Management Engine (or Manageability Engine) is a dedicated microcontroller on all recent Intel platforms
. Shares flash with the BIOS but is completely independent from the main CPU
. Can be active even when the system is hibernating or turned off (but connected to mains)
. Has a dedicated connection to the network interface; can intercept or send any data without the main CPU's knowledge
So in short if you are happy with a separate "watch dog" processor running alongside your PC's main processor, with nearly unlimited ability to snoop on what the main processor is doing/has access to AND is capable of out-of-band network access,, well then I guess you are right - there's no reason to want something like Coreboot, no big deal.
Re: Who cares?
Date: 2016-02-29 11:48 pm (UTC)If you want a system without the ME firmware or any other binary blobs, I think you can get systems with Libreboot pre-installed from https://minifree.org/ or the Gluglug website (if it still exists).
More information:
http://me.bios.io/Main_Page
https://www.coreboot.org/Intel_Management_Engine
https://www.coreboot.org/Binary_situation
https://libreboot.org/docs/hcl/gm45_remove_me.html
https://libreboot.org/faq/#intelme
https://libreboot.org/docs/hcl/index.html#supported_list
Re: Who cares? I do!
Date: 2015-12-13 05:39 pm (UTC)First, those who would give up their essental liberty to obtain little temporary safety, deserve neither liberty, nor safety. That's how B. Franklin told it, and it seems to be very true.
Second, UEFI shit is not customizable and proprietary, and could expose really nasty bugs. Say, my system firmware would lock up if I hit shift key a moment before GRUB has been started. This makes entering GRUB menu really challenging and annoying and I have to reboot like 3-5 times to just be able to boot with desired version. Because if I hit key half second earlier before GRUB, system locks up. And no, this awful bug is not going to be fixed. Ever. So you can be sure I would seriously consider using some less fucked hardware next time.