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.
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.