Do We Need Secure Boot?
There are ongoing debates on how one needs to protect his/her computer from malicious code which modifies pre-boot process(es). There are also articles and blogs talking about what we (alternative OS users) can do to tackle the troubles secure boot will bring us. However, as long as I understand it, the whole mess is forced down our throat only to cover a single company's a**, who is not doing a good job protecting its crappy flagship product. We don't really have that kind of malware in the *nix land so far which is feasible in a technical perspective, do we?
Also, I'm thinking of replacing my old machine (desktop) and I'm going to build from parts. Are there any new motherboards available out there without the mentioned trouble (i.e. secure boot)? |
"Secure Boot" prevents the boot loader on a motherboard from loading non-signed boot code. No more, no less. If the only malicious software in existence were programs modifying the boot loader then yes, that would protect users from malware.
However, if malicious software can exploit security flaws in the OS or device drivers, then "Secure Boot" offers absolutely no protection. And of course, that's exactly how most malware works. The idea behind "Secure Boot" is to establish a trust chain from pre-boot to a user session. Users can be prevented from loading software and drivers by OS enforced signing mechanisms, and the OS itself cannot be modified without compromising the boot signature. Result: The user has very little control over the environment in which his/her software runs, and that is the entire point. No way to circumvent DRM. |
Quote:
|
Quote:
A user who intentionally tries to circumvent corporate policy will probably be able to do so, Secure Boot nonwithstanding, provided he/she has access to the right tools or the knowledge to create them. After all, if malware can exploit security vulnerabilities in the OS (or in drivers or applications) so can a user, especially one with physical access to the hardware. |
Quote:
That only justification for that is to conclude that the forces behind Secure Boot are attempting to implement their own walled orchard, a la Apple. Whatever the theoretical dangers of root kits may be, the impulse behind requiring Secure Boot as a condition of sale ("Windows Certified") is clearly anticompetitive. |
Quote:
Quote:
|
Quote:
The "must" is a marketing requirement of a software company whose marketing practices have long been less than sterling, not the recommendations of a neutral security taskforce or certification organization. Keywords: marketing requirement. Whatever the pros of Secure Boot may be, the motives for it are--er--unlikely to result from the disinterested concern of Microsoft in the sterling computer habits of its users. |
There are two simple reasons why there must be an option to disable Secure Boot that have nothing to do with marketing:
1. Many of their customers will do the same as always, they will buy Windows 8 licenses with options to downgrade to Windows 7 or Vista (whichever they deploy in their corporate environment). This will not be possible if Secure Boot can't be disabled. 2. The EU would sue the hell out of them for abusing their monopoly, may be even with a prohibition to sell boards that don't have the option. But they have made the option to disable Secure Boot mandatory for their certification program to prevent that. There are also simple reasons why they have made it mandatory to provide options to implement custom keys: So that larger customers can use their own keys if wanted, may be deploying a Linux or BSD system, may be ordering Windows versions with a different key than the standard key, so that the users aren't able to boot a standard Windows install DVD. |
Quote:
The rule "physical access equals full access" is still valid, and the best solution is still terminal (or possibly web-based) environments and/or physically locked-down clients. Quote:
|
Quote:
Quote:
|
Quote:
However, if ones primary concern is not to improve system security or stability, but rather to create a walled garden, restricting users ability to install non-signed low-level drivers (including DRM circumvention tools), Secure Boot may be the answer. (If one chooses to ignore empirical evidence regarding the effectiveness of such measures, that is; the jailbreak community has been quite successful in circumventing similar mechanisms on various smartphones.) |
And the jailbreak community are home-users, not corporate users. As I said, at corporate level Secure Boot makes sense. If you want to use it at home is a different thing, but thanks to the Linux Foundation (if you want dual boot with Windows 8) and thanks to Microsoft (if you want to run Linux only or dual boot using your own keys) it shouldn't be such a problem as most people cry it out.
|
Quote:
My comment about jailbreaking was just meant to illustrate that signed binaries are only as effective as the OS they load, and history teaches us that security vulnerabilities are quite common. One of the first (if not THE first) driver signing circumventions on the Vista x64 platform was related to a buggy (and signed) video driver from AMD. Quote:
|
How do you jailbreak a machine without leaving traces? And if there are traces it will be very likely that you will get fired and maybe sued.
|
I'm sorry people, but I think my questions still remain:
1) Is there any exploit code that works on Linux which can modify the boot sector without acknowledge of the end user? And how feasible is it? 2) Are there any newly manufactured motherboards without Secure Boot (not being able to disable the feature) available on the market today? |
Quote:
With Secure Boot disabled there is nothing to prevent a hacked system from booting. Quote:
|
Quote:
|
Quote:
The boot sector does not enjoy any special protection under Linux (or Windows, for that matter). If you can write to the boot device, you can modify the boot sector. Assuming the user lacks the necessary privileges to write directly to the device, there are two common attack vectors: 1. Application vulnerability > OS privilege escalation vulnerability > boot sector modification 2. Network-exploitable OS vulnerability [ > OS privilege escalation vulnerability ] > boot sector modification In the first scenario, the user is tricked into opening a specially-crafted file or visiting a compromised website. An application vulnerability causes code in the file/content to be executed. The code exploits an OS vulnerability to gain root privileges and alters the boot sector. In the second scenario the user isn't really involved at all, but this will only work if the attacker can access a service on the computer remotely. A vulnerability in the OS or a remotely accessible service is exploited to inject malicious code, which then proceeds to obtain root privileges (if necessary). It then modifies the boot sector. Quote:
|
Do you need it?
No Is it useful? Yes |
Frankly a motherboard manufacturer would be foolish to NOT have SecureBoot available in their UEFI products. Without it Windows 8 will not run and they will loose out on what is unarguably their largest market segment.
As I understand it SecureBoot is only enabled by default in systems sold with Windows 8 preinstalled, and even then there is a BIOS option to disable it (though Win 8 will refuse to boot if you do). The biggest problem is for those who wish to dual boot Win 8 and Linux. |
Quote:
In order to get the Windows 8 Logo certification, so that you can put a sticker on the box, the mainboard must use UEFI, support Secure Boot (with an option to disable it on non-ARM systems) and has to be shipped with enabled by default Secure Boot (not true for servers, Secure Boot may be disabled). That means that a machine that ships with Windows 8 pre-installed can be shipped without having UEFI or Secure Boot, but can also be shipped with Secure Boot enabled without an option to disable it, as long as it does not have the Windows 8 Logo certification. Sounds counter-intuitive and a little bit ironic, but having a Windows logo is the best way to make sure that you can install Linux. |
You are of course correct regarding older systems, and self-built. I had based it on what seemed to be a discussion of commercially purchased systems with Windows pre-installed. I daresay with the possible exception of smaller makers such as local shops and such, all the major players are going to be certified/logo bearing products.
|
I don't get the impression that Secure Boot / UEFI was designed by seasoned cryptologists. I'm not persuaded that it will prove to be as technically successful as hoped, and I will hereby wager a beer that it will be gone from Windows-8 as a requirement by, say, June of 2013.
|
Quote:
It's not just the bootloader but the entire boot chain that needs to work with it. Handling UEFI Secure Boot in smaller distributions: http://mjg59.dreamwidth.org/17542.html https://www.suse.com/blogs/uefi-secure-boot-details/ https://github.com/mjg59/shim/tree/mok |
Really - depending on Microsoft for the ability to use Linux is, at least for me, NOT an option.
|
Quote:
|
All times are GMT -5. The time now is 10:23 AM. |