You're saying "Microsoft is at least trying to do this" about a company that continues to hold up fixes to known exploits (maybe not publicly known, but it takes only a single person...) until a convenient patch day, but manages to push own idea of security which breaks other peoples' systems onto the whole industry (strangely those other systems are not affected to the same degree). That's what I would call a very real concern.
From my experience with the "typical user", migrating my gf's laptop from Windows to Ubuntu did more for security than any bootloader hardening could do. And it required no hardware update either...
They need more privileges for hiding itself from antivirus software, SmartScreen and MMSRT.
Bootloader signing is going to do NOTHING against the current threat model, which is all in the much higher levels.
Yes, an ios-app-store for all apps model IS effective against the current threat model (but also harmful to the computing economy at large). Secure boot, at this point, does ESSENTIALLY NOTHING against any of the worms / trojans out there.
http://www.chmag.in/article/sep2011/rootkits-are-back-boot-i...
http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_...
http://www.computerworld.com/s/article/9217953/Rootkit_infec...
I recommend reading atleast the first link.
Here's one juicy bit:
TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.
When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.
The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.
The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.
The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.
TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.
All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.
Another bit:
The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products.
But I don't think UEFI is going to make much of a difference, even against the next version of TDL4; In order to get installed in a system in the first place, it had some administrator permissions. What's to stop it from getting those permissions on win8?
From this article, the boot sector lets it hide better and earlier in the process -- but it wouldn't have been less scary to ordinary people even if it couldn't infect the boot sector.
Don't get me wrong, we need bootloader protection like this. However the approach that is being taken is wrong. This is the UAC of boot loader protections.... A half-assed measure that if Microsoft actually looked at what everyone else was doing they would have supported something different.
Consider the following scenario:
Spear-phishing attach aimed at the right individual compromises their computer through an IE exploit (never happens, right?) and steals the bootloader private key.
What's the response? If the key cannot be changed then overnight this fancy new protection has been rendered no protection at all. The key can then be sold for top dollar to malware programmers. The solution for the user will be to wait a few months and then buy a new computer.....
So you are right that the sort of implementation we are talking about will not make much of a difference long-term, but for a different reason: it offers no long-term security if the key cannot be rotated.
I don't doubt that something could be designed right, but I do doubt that such a design in security-critical aspects of computing will arise with Microsoft's cooperation.
so you modify the boot loader, but now that is dead. so you modify ... what? now we're "done", there isn't any further down the stack to go, this is the "base" of the "trusted computing base". hooray!
While it's true that with a trusted computing base (and tower), you could turtle all the way down to the boot, but unless something is already wrong (which can and will go wrong the same way even if you have a trusted base), UEFI secure boot should ONLY ever save you from pre-boot INFECTIONS, which I suspect are non-existent.
The best it could do for you for higher level attacks is make it harder for the malware to hide.
the best you can hope for is locking out unsigned code. we have platforms that do that, like chrome OS and iOS. after many years, it seems they continue to work! but when we try and take this security technique that we know works and move it onto the computers that everyone uses, we are met with much wailing and gnashing of teeth.
Now, that's where the problem lies, not with the unsigned boot sector. On the existing win7 system, rewriting the boot sector and loading unsigned drivers are essentially equivalent permissions (elevating from the former to the latter requires one reboot).
> the best you can hope for is locking out unsigned code. we have platforms that do that, like chrome OS and iOS. after many years, it seems they continue to work!
At the expense of JITs on ios; and chrome OS doesn't yet have enough experience in the wild.
Also, locking out unsigned code doesn't stop stuff like "return oriented programming".
> when we try and take this security technique that we know works and move it onto the computers that everyone uses, we are met with much wailing and gnashing of teeth.
A chain of trust is known as a security technique that DOESN'T work, regardless of what it protects -- SSL forgeries are rampant, and the vulnerability is not in the algorithms.
The UEFI secure boot makes a small difference in real security. It will easily become as trustworthy as SSL certificates, meaning, not at all. And if the key ever leaks or is broken ... there is essentially no recourse other than buying a new computer.
There are ways to secure the boot in a way that's helpful for security without limiting choice. UEFI secure boot is not one of them.
Using Windows these days just seems like asking for trouble on the spyware/malware front. Some of it is your machine getting owned, other times its just missing a checkbox on a program install that installs a browser bar that does God knows what.
My Macbook Air is pretty much my computer of choice these days (with very little third party software). Soon Apple will require sandboxing on the Mac App Store too. Linux of course also being a much better choice than Windows from a security point of view.
On the browser front I can't see myself using anything other than Chrome. Part of this is feature-related and the whole one process per tab thing but it's also the most security-conscious browser IMHO (disclaimer: I work for Google but not on Chrome).
We haven't had any machines "owned" at all...
Sorry, but a basic principle of security is to assume that you are already 'owned'.
A better basic principle is guard all your doors, windows (excuse the pun) and cracks religiously (proactive).
Also: how does secure boot prevent your laptop from being "owned?". It doesn't. I will bet a significant fraction of that $300k that the exploit used against your friend was not pre-OS malware.
The basic problem is that the GPL cannot live up to it's goal in all cases unless it is backed by both a) software patents and b) a software patent license under the terms of the GPL. Absent that all you have is a license that allows you to do some things otherwise prohibited by copyright law. You have no restrictions beyond copyright law.
The problem here is that copyright law doesn't ban all copying and distribution. Notable cases in the US which allowed verbatim copying of part of source or object code in commercial products as fair use include Oracle v. Google and Lexmark v. SCC. In both cases the court basically said that 17 USC 102(b) precludes using copyrights to ban control secondary markets of practical tools.
So I read this as that in US law you do not need the copyright owner's permission to distribute software that links to a copyrighted library. If I want to link to GNU Readline with my proprietary app, 17 USC 102(b) protects me regarding US law, provided I dont distribute Readline myself. But hey, virtually every Linux distro ships with Readline so, what does it matter?
I don't know how fruits-of-labor jurisdictions address this issue but there is likely to be some line that prevents this as well. Otherwise Microsoft could say "Nobody can distribute MinGW for Windows 8 because no longer give permission to link against our system libraries for that version." No court in the world will give Microsoft that level of power, ergo I doubt the FSF has anything close to that either.
As for what Microsoft did, I think the key case would be Chamberlain v. Skylink. There is going to be no DMCA issue with breaking secure boot because you can't show that this is access control in the way the DMCA intends it. If you can jailbreak your ARM tablet that will be seen as fair use even if it involves literal copying (see the US Copyright Offices opinion on fair use regarding jailbreaking iPhones by copying/modifying iOS). If not, at least there has been enough press for you to consider yourself fairly warned in advance. IOW, it's a technical measure, not one backed by force of law.
I don't mind the GPL v2. It's a relatively simple license. There is some ambiguity (if I statically link your GPL v2 module in my program and provide the source just for your module is that allowed?) but for the most part that's pretty minor.
The GPL v3 is a nightmare and I try hard to avoid touching it. I don't care how many times I slowly read the license, it never makes sense to me.
For example..... Can you include a 2-clause BSD-licensed module in a GPLv3-licensed program? If the BSD license is interpreted not to allow sublicensing or passing on only a subset of rights to the code (this is the official view of the Software Freedom Law Center btw), does that render the licenses incompatible as per the additional terms (particularly the additional permissions) requirements in section 7 of the GPL v3?
With the GPL v2 everyone had a general idea of what it meant and lawyers only really argued around the edges. With the GPL v3, I don't think anyone understands it. And the driver of this problem is the FSF trying to push copyright enforcement where, quite frankly, it doesn't belong.
So what you saying is that just because you know some smart guy that owns a lot of money, UEFI is a good solution for fighting malware. I'm not so sure that UEFI is really gone help your friend to be more secure ... maby feel more secure though, which of course is a valid point but probably not because he will see thru it. Maby you friends laptop was due to a bootloader hack but there is easier ways to hack computer then that. I'm not saying that we shouldn't try to do anything about the risks but not this way, because this do only do it harder for everyone else.
What text are you drawing that conclusion from? It strikes me that they deliberately pass up the opportunity to disparage the security explanation for secure boot: "This claim ignores the fact that we need protection from them." Not "This claim is total BS."
The FSF statement acknowledges the security concern and brings up a competing concern. They ask that computer makers balance the two competing needs, and state that the plans for implementing secure boot on x86 will satisfy both needs. That's definitely not the blindly one-sided position you seem to think it is.
Was this unfortunate gentleman's laptop subject to unauthorised access by means of a compromised bootloader/bios? I have heard of very few exploits of that nature (but I'm not involved in supporting large numbers of machines).
Think of it like a VM loader, an OS running in a VM may not even be able to find out if it's running on Linux or Windows, but the host can transparently see everything going on in the guest OS.
Maybe because those who boot into environments endorsed by the FSF don't have a malware problem. I certainly don't.
That doesn't make me insensitive to other people's problems. But I have no sympathy for those who face such problems because they chose to.
I'll take it seriously when bootloader malware become the dominant model, because only difference is being harder to detect. Each and every malware I've seen is perfectly happy with user-level permissions and privilege escalation from within the OS and, once UEFI becomes the norm, I suspect signing keys will leak anyway.
Agreed.
> The alternate to secure boot is something like an ios app store for all apps.
That's not the only alternative, though. Having a way to simply notify users of a signing status change would be enough.
For the thousandth time: I know a computer user who almost had a $300k sum stolen because his laptop was owned. He has had to resort to having a second laptop used exclusively for accessing his business bank accounts in order to feel some security. He's not dumb: he makes more money than virtually anybody reading this and has an undergrad in math.
The computer security model for most users is incredibly broken. The alternate to secure boot is something like an ios app store for all apps. Users simply want to be able to run their computers without having to be constantly paranoid about spyware and malware. Microsoft is at least trying to do this, but the eff pretty much dismisses these very real concerns.
edit: for the record, I spelled fsf as eff before having my first cup of coffee.