|
|
Subscribe / Log in / New account

LSS: Secure Boot

LSS: Secure Boot

Posted Sep 21, 2012 4:11 UTC (Fri) by cyanit (guest, #86671)
Parent article: LSS: Secure Boot

Again, WHAT THE FUCK is the threat model?!?

As far as I can tell, you can just run Windows in a fullscreen qemu instance with full access to the hard disk, and the user will think it's the legitimate version of Windows...

Is access to Windows partitions on disk somehow blocked by the kernel?

If so, why not just have the BIOS and SATA controller cooperate to do that (i.e. irrevocably disable access to a disk range until reboot), thus allowing arbitrary software to run without issues?

Then, what's the point of having all this for Linux, when root can just add something in /etc/init.d that takes over the system silently, and any user can do the same using autostart?

Also, do you REALLY expect all Linux code (esp. in drivers) to not contain a ton of security holes exploitable by a root user, considering this was never thought to be a problem?!?

Have you spent the millions (or billions) of man hours needed to do a thorough review of the Linux code and mathematically prove that there are no holes?

Is this all just for show because otherwise Microsoft wouldn't sign the bootloader?

Because the way it is described, it provides no real security whatsoever, at all.


to post comments

LSS: Secure Boot

Posted Sep 21, 2012 4:49 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (4 responses)

So you run all your code as root?

LSS: Secure Boot

Posted Sep 21, 2012 5:18 UTC (Fri) by raven667 (subscriber, #5198) [Link] (3 responses)

Do you know of any thing that would prevent the scenario where a compromised system modifies the boot such that you boot into a trusted boot loader and trusted kernel which then runs the original OS image as a VM and has its way with it. AFAIK Secure Boot doesn't protect a VM from its hypervisor.

LSS: Secure Boot

Posted Sep 21, 2012 5:24 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (2 responses)

No, if you can launch a sufficiently convincing hypervisor from within Linux then you can win. As yet I haven't seen any examples of a sufficiently convincing hypervisor, but I look forward to seeing what people come up with.

LSS: Secure Boot

Posted Sep 21, 2012 13:18 UTC (Fri) by raven667 (subscriber, #5198) [Link]

I suppose one could make it deliberately difficult to make such subterfuge difficult to be convincing by including splash screens or other visual indicators of what is going on. There is also the fact that such an attack will have to carry around a lot of code, tens of megabytes or more, making it unwieldy in many environments.

LSS: Secure Boot

Posted Sep 21, 2012 23:08 UTC (Fri) by nix (subscriber, #2304) [Link]

I doubt it needs to be very convincing to convince enough people to be useful to attackers. Heck, the less convincing it is the better it may be for them -- as with Nigerian scams, it helps their marks self-select for stupidity.

LSS: Secure Boot

Posted Sep 21, 2012 5:13 UTC (Fri) by raven667 (subscriber, #5198) [Link] (22 responses)

> What is the threat model?

The threat model that Secure Boot is intended to help thwart is fairly simple, it makes no claims about OS security or vulnerabilities in the kernel or rootkits in the running system, it's only claim is that you can boot into the kernel without the possibility of a rootkit already having been planted in the firmware or bootloader. The rest is whatever scheme you dream up for the OS.

What people are using this tool for is to implement integrity checking in the kenrel that can't be easily and persistently subverted. It didn't make a lot of sense to invest heavily in integrity checking before when the underlying layers were so easy to subvert. Since you can't subvert any of the persistant storage without breaking the signatures then your malware has to be started using normal OS means and you can use standard OS tools and anti-malware to detect and clean it out before it runs. The anti-malware can have its own integrity checking on updates so that a compromised system can be cleaned just by rebooting it. The malware can't subvert the anti-malware but it can potentially block updates although this can be easily detected.

The concern with the security of the boot loader is that there are going to be a number of signed boot loaders from various vendors out in the wild that will all be trusted by every machine by default. If those boot loaders can be configured to run arbitrary code then any one of them could be used as a shim to load malware before the kernel and anti-malware has a chance of loading which drives a particular design where the boot loader does some sort of authorization checking as to what kernel image it is booting.

None of this protects an OS which is running in a VM from the hypervisor although it still has the same protections from malware inside the OS. As far as I know the threat model of Secure Boot can't handle the case where you Secure Boot into a legitimate bootloader and legitimate kernel which then boots the OS as a guest in a VM. It'd be an interesting proof of concept to see how one would modify a compromised running system to include booting a hypervisor without breaking the system in some way. Maybe someone who knows more than me can help answer this question, mjg59?

LSS: Secure Boot

Posted Sep 21, 2012 14:56 UTC (Fri) by ballombe (subscriber, #9523) [Link] (21 responses)

It is easily predictable that the day Windows 8 is released, the windows boot loader will be compromised to boot arbitrary code. So one get 24h of protection, then what ?

LSS: Secure Boot

Posted Sep 21, 2012 15:14 UTC (Fri) by raven667 (subscriber, #5198) [Link]

I'm sorry but that is pure BS. By what mechanism do you think this is likely? Win8 has been out for free for anyone to test for months now and I haven't seen anything even hinting at a compromise published. The boot loader is a small piece of code and auditing it is a completely tractable problem. Maybe you haven't noticed but MS has gotten religion about security in the last decade and has some of the most thorough auditing of any software project.

This is just a fancier way to make the statement "Linux rulez and MS droolz" which isn't a useful statement.

LSS: Secure Boot

Posted Sep 21, 2012 18:33 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (19 responses)

Then the signature is revoked, blacklist updates are pushed out through Windows Update and Microsoft have to press a lot of new media.

LSS: Secure Boot

Posted Sep 21, 2012 23:12 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

Well, that's OK for Microsoft because it'll presumably push out an update to its bootloader to no longer be a blacklisted one at the same time.

Shame if it decides to blacklist the Fedora key. All of a sudden every single secure-booted instance of one of its competitors that is dual-booted with Windows has stopped working! And there is, as far as I can see, no easy way to recover. (Maybe Fedora could make a boot CD image available that would update the bootloader, splash it in big letters all over fedoraproject.org, and hope that everyone affected thinks to look there. *shiver*.)

(I have 'secure boot' on this new system of mine. I have, of course, turned it off. The last thing I need is a way of rendering my system magically unbootable. I have enough of those as it is!)

LSS: Secure Boot

Posted Sep 22, 2012 22:14 UTC (Sat) by raven667 (subscriber, #5198) [Link] (1 responses)

Personally I think that this risk is a reason that the major Linux vendors such as RedHat, Ubuntu, Debian and SuSE should work together and with OEMs to make sure they have their own keys in the root of the firmware. This will cost millions of dollars and be an ongoing cost to keep the secure signing infrastructure but it provides a measure of independence. A related solution is to work with Linux-friendly VARs to make branded devices and try to get similar market share and margins as Apple does with their Mac hardware. This might be harder than Apple though because Linux will never be restricted to run on only branded boutique hardware so its revenue stream is not protected.

LSS: Secure Boot

Posted Sep 23, 2012 14:22 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

That doesn't help a great deal - if Microsoft have an entry in KEK then they're in a position to blacklist Linux binaries even if there's a more generic Linux key present as well.

LSS: Secure Boot

Posted Sep 22, 2012 15:55 UTC (Sat) by ballombe (subscriber, #9523) [Link] (15 responses)

So a bug to windows update could be used to upgrade the boot loader to a vulnerable one ? This increases the attack surface somewhat.

LSS: Secure Boot

Posted Sep 22, 2012 16:05 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (14 responses)

> So a bug to windows update could be used to upgrade the boot loader to a vulnerable one ?

No.

LSS: Secure Boot

Posted Sep 23, 2012 21:21 UTC (Sun) by nix (subscriber, #2304) [Link] (13 responses)

But if Microsoft were penetrated and their key stolen... correction, not if: *when*.

LSS: Secure Boot

Posted Sep 23, 2012 21:37 UTC (Sun) by raven667 (subscriber, #5198) [Link] (4 responses)

I think you underestimate how easy defense is compared to offense when protecting keys. Any individual subroot can be revoked and replaced via a secure update, the root key hardly ever needs to be used and can be kept offline and safe against anything short of a Mission Impossible type attack.

LSS: Secure Boot

Posted Sep 23, 2012 22:32 UTC (Sun) by nix (subscriber, #2304) [Link] (3 responses)

Yeah. Because they'll never make any key management mistakes, there'll be no social engineering, no industrial espionage, no simple burglary -- after all, nobody at all has any reason to want to get hold of a bit of data which could kill huge numbers of Windows boxes at a stroke, no sir.

(Remember, the attackers only have to be lucky once.)

LSS: Secure Boot

Posted Sep 23, 2012 22:46 UTC (Sun) by hummassa (subscriber, #307) [Link] (2 responses)

YES, Please.

People imagining these schemes forget that crypto keys are leaked and recovered all the time IRL. And that if you are not a government, you can always use the wrench method. https://xkcd.com/538/

LSS: Secure Boot

Posted Sep 24, 2012 3:50 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

I'm sorry, are you asserting that Verisign and other major entities are leaking their root keys all the time? We're not talking about passwords for your disk encryption, we're talking about real professionally managed CAs. If some vendors signing infrastructure were compromised to sign arbitrary binaries, like the DigiNotar incident, then that subroot can be blacklisted without affecting other vendors. The root has to sign so very few things that it has very little attack surface area.

LSS: Secure Boot

Posted Sep 24, 2012 8:41 UTC (Mon) by nix (subscriber, #2304) [Link]

Several major keys from various CAs have been compromised already: more will come. If this scheme really gets going, these keys will be a *major* target -- do you really imagine that nobody with sufficient resources to get a copy won't try? (Perhaps, if they are sufficiently clever and lucky, they might even arrange to get the *only* copy: that'd be amazingly useful to extort money from MS with, though very hard since I'm sure MS have lots of backups).

LSS: Secure Boot

Posted Sep 24, 2012 0:36 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (2 responses)

If you wanted to attack Windows in the current non-Secure Boot world, the single most valuable thing would be the ability to sign arbitrary code as a valid Windows driver. But, somehow, nobody's managed to get hold of Microsoft's key. Now, to be fair, part of that's because vendor keys have been easier to get hold of (see Stuxnet), but even so having the Microsoft key would be an advantage - if you've got the root then there's no process for revoking existing installations. And yet it hasn't been leaked.

LSS: Secure Boot

Posted Sep 24, 2012 8:41 UTC (Mon) by nix (subscriber, #2304) [Link]

True enough. Still, the paranoid in me sees a billion or so eggs landing in one basket, and thinks 'this is *wrong*, this is *stupid*'.

LSS: Secure Boot

Posted Sep 24, 2012 9:07 UTC (Mon) by hummassa (subscriber, #307) [Link]

> Now, to be fair, part of that's because vendor keys have been easier to get hold of

No, that's not "part of that". s/part of //. The security process stops at the easier way to the threat to get what he wants. Threats can and will leak keys from Microsoft (remember NT4/XP source code?) if that's the easier way of signing device drivers. As vendor keys are currently easier to get hold of, and they do the job just fine (because there are a lot of vendors and IIRC once the keys were revoked another version of Stuxnet signed with another key popped up) the threats don't need to go after MS.

Security = you don't have to outrun the beast, you have to outrun the friend beside you.

LSS: Secure Boot

Posted Sep 24, 2012 1:04 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

All large companies use HSMs (Hardware Security Modules) to sign keys. They are guaranteed to be unhackable in _practice_, and that guarantee is backed by a very large sum that manufacturer would pay you in case of a breach.

LSS: Secure Boot

Posted Sep 24, 2012 8:42 UTC (Mon) by nix (subscriber, #2304) [Link] (3 responses)

So... if MS's key gets compromised and a huge proportion of the world's machines are rendered unbootable... MS gets compensation? That's reassuring.

LSS: Secure Boot

Posted Sep 24, 2012 18:24 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Well, the world's root DNS zone is also signed by a key in a HSM.

LSS: Secure Boot

Posted Sep 25, 2012 8:20 UTC (Tue) by alonz (subscriber, #815) [Link] (1 responses)

Yeah, that sure is reassuring. </sarcasm>

Have you, perhaps, seen this? Or this (as applied to HSM's, considering the incompetence apparent from the first link)? I don't think HSM's are as magic as people expect them to be…

LSS: Secure Boot

Posted Sep 25, 2012 8:29 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Naw, HSMs are protected against trivial attacks like this. I know for a fact that a certain large HSM from a company which names begins with "T" has an intermediary buffer that holds data after the encryption for a random (and quite significant) amount of time before transmitting it to client.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds