It's amazing. I read the first 3 paragraphs and the eff can't even acknowledge how much of a problem malware is for many computer users.
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.
How much of that malware is actually working at the level that the bootloader is concerned with? And how many samples are just trivial keyloggers, screen grabbers, enablers for fishing attacks, etc. that don't even need anything more than user-level privileges? I'd happily run a system with no standard antivirus / malware protection / ... as long as it has a good separation of resources from kernel to user-space. I subscribe to ideas like http://qubes-os.org much more than trying to protect the bootloader. The typical user-space is exposed too much at the moment and the number of really sophisticated exploits isn't that big.
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...
>And how many samples are just trivial keyloggers, screen grabbers, enablers for fishing attacks, etc. that don't even need anything more than user-level privileges?
They need more privileges for hiding itself from antivirus software, SmartScreen and MMSRT.
That's true. Unfortunately that assumes the user 1. has an antivirus installed 2. his interaction with it isn't limited to closing the "license expired" window as quickly as possible at startup. That's still a very typical pattern.
Unless you can produce credible statistics showing bootloader malware, I'm going to call "strawman".
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.
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.
The big thing is it is a half-measure against an emerging threat model.
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.
it could get administrator permissions but, to run a device driver, the device driver needs to be signed. to patch a device driver on the system would invalidate its signature and that modified device driver would no longer load.
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!
On win7/64, you don't get permission to load unsigned drivers even with administrator (or at least, that's how it is supposed to be). So, once the system is up -- how did the worm modify the boot loader in the first place?
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.
you don't need to load unsigned drivers to modify the boot loader, you can do that with administrative permissions alone (as far as I know).
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.
> you don't need to load unsigned drivers to modify the boot loader, you can do that with administrative permissions alone (as far as I know).
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.
I've had similar thoughts. I can make a fairly strong case that the best platform for me to access sensitive information from is iOS (specifically my iPad). It's sandboxed and comparatively secure.
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).
Well managed and secured Windows 7 is actually probably more secure than any other major desktop OS right now (iOS blows it out of the water of course). OSX is more secure out of the box for a single user deployment perhaps (largely due to being less of a target), but in a corporate environment, it's harder to really lock down OSX than anything else. Sadly.
This is the Free Software Foundation's position, not the Electronic Frontier Foundation's. Those are very different organizations. The fact that you confuse their acronyms (and also that you apparently stopped reading after three paragraphs) makes me worried that you are conflating their positions.
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 FSF, not the EFF. The EFF is generally much more reasonable (moderate?) about things like this; the FSF is generally more in line with Stallman's views (radical or crazy, depending if you agree with him).
I still see the FSF as a bit... idk... zealous? delusional? deliberately blind?
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.
The GPL was designed to protect users, not developers. Under it, developers can't hide the source code from their users, can't prevent their users from modifying the programs they use and from helping other users with the code they have. If you statically link to a GPL'ed library, your code is GPL'ed, end of story. What Lexmark did was to use code as an excuse to prevent the formation of a free market. What Lexmark did is very close to what Microsoft is trying to do preventing the formation of a free market for operating systems for ARM devices.
you know, I use the GPL v2 for most of my code for reasons of history of projects, and the 2-clause BSD license where I can. I refuse to use the GPL v3.
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.
>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.
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.
Well maybe you should have read more of it? They explicitly acknowledge the benefits of secure boot - the concern they have is that it's possible for the current model to be used to prevent the owners of machines from being able to choose what their computer will run.
"can't even acknowledge how much of a problem malware is for many computer users"
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.
"I know a computer user who almost had a $300k sum stolen because his laptop was owned."
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).
I am no fan of what Microsoft is doing here, but it is an emerging threat profile and consequently some sort of boot loader signing makes sense. The exact design of course should be such that it is possible for users to update keys, however, because otherwise, once a key is compromised the whole system falls apart.
The concern is not that bootloaders/bios is compromised. It is that once the PC is compromised, the malware can load from the bootloader before the OS or antivirus can even load, and then hide itself from them completely, thus making it effectively invisible.
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.
> It's amazing. I read the first 3 paragraphs and the eff can't even acknowledge how much of a problem malware is for many computer users.
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.
Until we have 'personality' virtualization for os's, so you can have subaccounts, the model is shitty. Also, programs and users should be treated the same.
Not only that, but after calling secure boot basically useless for security, they turn around and want to secure their PCs against malware known as Windows using secure boot!
They didn't call it useless, they said it could be useful, if done correctly. From their point of view, if it were done correctly, the user ought to be able to block Windows. But since that will be difficult, it undermines the security advantages of Secure Boot. Their position is quite consistent.
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.