What if I prefer Debian over Ubuntu? Can I be upset then? I'm sure this will be possible to hack around, but we shouldn't have to hack our own computers to use them. A simple option to disable secure boot would solve all the problems. The vendors know this, so I'm curious why they would chose to not provide the option. Is there some belief that by even having the option, the system would be inherently more insecure?
I'm sure that some vendors will provide an option, so this will just likely be an extra thing to research before buying a new system.
Doug, if you use a Linux distro that is not signed, then yes, it is an issue because you will have to track down laptops that allow allow disabling secure boot. BTW, I didn't intend to sound flippant in my original comment, it is just that as I get older (I turn 2^8 next month, yeah :-) I am more concerned with convenience, fun and productive development environments, etc.
I would be more worried about other OS projects that are either too disorganized to meet whatever the signing qualifications are, or have ideological issues which prevent them from participating.
Canonical doesn't enforce signature checks for module loading (which is useful for DKMS based kernel modules, and is also a "freedom to tinker" matter). That may well lead to a revoked Secure Boot key at some point...
I don't use Ubuntu and Redhat. Once they decided to follow a windows model with systemd and the "break everything on purpose" style of writing software, they were no longer useful. So what about the massive variety of other distributions that didn't - or cannot in the case of Free Software - sign up for the restrictions inherent in being "compatible with secure boot"?
More importantly, why limit this to linux? It would be a lot harder to develop a new OS - just like Linus did - when you have to deal with secure boot.
Serious question: how does Secure Boot make you more secure?
How many times has a virus latched onto your computer by executing before your system booted up? I've never heard of this happening to anyone I've ever known.
The only scenario I can imagine is having a PC set to auto-boot from peripherals, and a USB key having something bad execute before invoking your hard disk's boot loader. And that is obviously possible, but terrifying more complex to pull off. But that seems a lot more like a local, physical attack that's much less useful and more targeted than your ordinary viruses that install after executing inside your OS, where viruses seem to have no problems pulling off privilege escalation exploits to gain kernel access then. Plus you can easily block this and then lock down your BIOS already.
It really seems like Secure Boot is solving a problem almost no one ever had. I may well be misunderstanding the point, so please elaborate on how this is useful and absolutely prevents a class of attack that could not be done otherwise.
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
So the concern is that the virus is installed like any others on Windows; but then it keeps itself installed through the boot process reloading it. Thus it must intentionally damage any internal Windows protections that would try and check for it during its own startup. Which of course would be a cat and mouse game.
Okay then, what stops a theoretical TDL5 from using a Linux distro's signed kernel/bootloader to boot a little mini OS that then does the same thing TDL4 does now? (even if the Secure Boot Linux kernel locks out kernel driver access; maybe it uses a privilege escalation exploit to regain that access)
It would seem like the only way Windows could be absolutely certain that only its own code executed up to the completion of boot would be if Microsoft were the only company that could sign working boot code for a hardware device. The gains in security wouldn't be worth the loss of freedom.
I read an article a couple of months back (like October-Novemberish 2014) about the NSA putting a virus into the firmware of a RAID controller on some Dell servers that would patch Windows Server 2003 (R2?) during startup.
So it is not entirely without precedent.
Then again, this did not touch the OS bootloader itself, strictly speaking and might not have been prevented by "Secure Boot". Also, once you're diddling with a devices firmware, you might as well tamper with "Secure Boot" as well and defang the checking of the bootloader or even make the firmware live-patch the bootloader...
So, while I am by no means a security expert, I have been wondering the same thing. The entire "Secure Boot" stuff just seems like a lame excuse to allow vendors control over what operating systems you can boot on their devices.
>So, while I am by no means a security expert, I have been wondering the same thing. The entire "Secure Boot" stuff just seems like a lame excuse to allow vendors control over what operating systems you can boot on their devices
>Malware developers have increased their attempts to attack the pre-boot environment because operating system and antivirus software vendors have hardened their code. Malware hidden in the firmware is virtually untraceable by the operating system, unless a search specifically targets malware within the firmware. UEFI Secure Boot assists with system firmware, driver and software validation
>Without UEFI Secure Boot, malware developers can more easily take advantage of several pre-boot attack points, including the system-embedded firmware itself, as well as the interval between the firmware initiation and the loading of the operating system
>Nevertheless, in a variety of implementations that have already reached the market, UEFI Secure Boot has proven to be a practical and useful tool for improving platform integrity and successfully defending the point of attack for a dangerous class of pre-operating system malware.
>I read an article a couple of months back (like October-Novemberish 2014) about the NSA putting a virus into the firmware of a RAID controller on some Dell servers that would patch Windows Server 2003 (R2?) during startup.
I'd say that there's a better than even chance that the NSA already has Microsoft's secure boot private key.
> I read an article a couple of months back (like October-Novemberish 2014) about the NSA putting a virus into the firmware of a RAID controller on some Dell servers that would patch Windows Server 2003 (R2?) during startup.
The NSA and the PRC will get their payloads signed with the appropriate keys. Everyone else will do something cheaper and simpler, like reading their target's gmail accounts.
> So, while I am by no means a security expert, I have been wondering the same thing. The entire "Secure Boot" stuff just seems like a lame excuse to allow vendors control over what operating systems you can boot on their devices.
This is true today, but it ignores the realities of many secure boot implementations. Specifically, many UEFI firmware vendors don't include the ability for the hardware owner to update the public key used to verify a bootloader signature. This means that someone wanting to use a new bootloader on one of these platforms has to beg for permission from whoever owns the existing keys (Microsoft seems to be popular right now...) to get their software to boot. Right now, MS is willing to sign bootloaders for OSS, but this could change at any time. Do you really want MS to control the ability to boot your operating system of choice?
Jeff, you mention valid concerns but there are two things that make me feel reasonably comfortable with this: there will be laptop manufacturers who will provide selective disabling because of market pressures, and, I think the 'new Microsoft' sees its future as providing productivity tools cross platform. I find the web based versions of Office 365 to be handy to have on my Linux laptops and I would be a little surprised if Microsoft does not eventually offer native apps for Linux.
Although I am a fan, for my own projects, of GPL and AGPL licenses, I do like the availability of commercial apps on Linux. I like Linux because it is a great development platform but I am less of a purist than I used to be concerning an occasional commercial app.
It's less about Linux for me than about the other things I want to boot (MS is unlikely to disable Linux bootloaders on certified Windows PCs for lots of reasons).
By way of example, the company where I work today produces a hypervisor for x86. We're nowhere near big enough to exert market pressure on someone the size of MS or the hardware manufacturers. When we recently added UEFI support to our product, we looked at support for UEFI secure boot as well. Some systems made key management easy (obvious bios options, etc.), but others made it impossible. Upon investigation, this mostly appears to be more due to apathy on the hardware vendors part than any conspiracy theory, but for an end user the distinction is unimportant. Today we can work-around this by using an MS-signed bootloader shim, but this reduces the security of the end solution (any ms-signed shim will boot, a third party owns the root keys). And, as I mentioned in my comment above, MS can change their policies at any time.
I haven't run into an x86 system yet that doesn't at least allow you to disable secure boot, but the trend towards more locked-down hardware in general (esp. in mobile) worries me due to the potential for anti-competitive behavior towards both commercial and open-source software from third parties.
Remember that `SecureBoot`ed Kernels only load signed kernel modules, because otherwise you could still run arbitrary kernel code. Thus with locked secured boot you cannot ever use self-compiled kernel modules, e.g. Nvidia driver and ZFS.
I don't really understand the concern here. Microsoft is simply saying it's optional for its hardware partners to display the option to toggle it. I could see plenty of enterprise systems wanting to not allow users to change this setting. Microsoft isn't trying to block anything here.
If you want to use linux simply vote with your dollar and go to the vendors that will let you install it (I imagine most will). That or use a linux distro that is actually compatible with secure boot.
The problem was IIRC that you need something signed with MS key to be able to boot whatever. If you are able to set your own keys - then there is almost no problem (still usb flashes and so on will be harder to boot)
> If you are able to set your own keys - then there is almost no problem
Doesn't this make the feature useless from a security standpoint? If you're able to create your own keys then malware could create its own keys. Maybe if manufacturers could do it that would be handy.
I would assume that these UEFI machines have a built-in settings screen the same as BIOS-based machines do (and that screen would be where the setting we're discussing is found). If the only way to add keys is thru that screen, then you'd need physical access and malware adding keys wouldn't be an issue.
The keys are stored in a separate hardware module with a defined interface (which I'm sure is standardized somewhere). From what I understand, part of that interface would be a flag you can set to say "do not accept new keys until next reboot" (I assume there's also one for "do not accept new keys, ever again"). If the firmware sets that not-until-reboot flag before booting the OS, then going thru the firmware really would be the only way.
Secure Boot can (and typically does) operate without a TPM, so no separate hardware module.
However, flash writing can be limited in hardware, so it would be possible to store Secure Boot keys in a special region of the flash that's locked down right after the opportunity to get to that setup screen passed.
But that's not how UEFI works. Unlike your traditional BIOS, the settings can be edited from a normal OS by command-line utilities and such, too. In fact, often the only way to do anything useful, given how broken many UEFI setup pages are, is to edit the settings directly.
You're not meant to be able to edit those settings from anywhere other than the setup page. In practice, that's as broken as everything else in modern UEFI implementations, and some allow userland processes within Windows to add signing keys.
Currently ability to set your own keys is mandated for Windows 8/8.1 devices. Leaked slides don't describe how it will be for Windows 10. We can guess only on the base of possible Microsoft's intentions.
My main concern is it will be a pain to actually find out whether or not a machine supports this option. Nobody will actually actively advertise its absence.
It costs $99 to sign the software. I'm sure most of the distros can afford that (unless they take a die-hard stand, in which case, just don't buy a Windows pre-loaded PC from the OEM that disables the option to run Linux with).
If you buy from an OEM that pre-installs Windows then you are already paying a fee for the Windows license. If you don't want to pay a fee for software then just buy a from a company that pre-installs Linux.
My organization provides the disk images to the manufacturer for the computers we buy. This isn't about "paying a fee for software." It's about the fact that Microsoft has used its industry influence (and cozy relationship with Intel) to attach itself like a parasite to the process of bootloading in UEFI.
We currently pay our manufacturers to install our signing keys into UEFI; this is fantastically expensive. It's a damn shame that it is literally impossible to buy a consumer UEFI device without Microsoft's keys in the image unless you pay to have yours put in.
In short: it sucks that they are the default, and it sucks that Red Hat and Ubuntu rolled over on the issue and pay the (latest) Microsoft tax. I would have preferred a more flexible solution.
$99 (not sure for which time period) and the risk of losing your cert whenever Microsoft thinks you compromised their platform.
Canonical uses kernels without signature checking, where you can just load new kernel modules.
In principle this allows to hack into a "Secure Boot" Windows in a day or so (rough draft: have a kernel module, eg. kexec, that runs Tianocore, which can load and run Windows, and pretend the system is "secure" while there's random crap running in the background).
I think Microsoft is silent about Canonical's use of Secure Boot for now, but they might change their tune (and once there's a PoC, they certainly will).
Doesn't it also have requirements (which may or may not be strongly enforced) that users are not allowed to run their own kernel code? (because you could then undermine most of the point of this whole system.) With possible key revocation (blacklisting) being the enforcement?
The cost alone is one thing, that'd only ruin the ability of hobbyists to create new OSes. Something exceedingly rare anymore, sadly.
But the restrictions stating what your kernel is allowed to let you do is quite another. I want the ability to write my own kernel space drivers on my own hardware, if I so choose (and I have done so in the past.)
If Microsoft’s stance on this issue is not reversed it’s possible we will see a spike in sales by manufacturers such as System76 and ZaReason who ship computers running Linux out of the box without any signs of Secure Boot at all.
So... not a problem. If there is a market for non-Secure Boot machines, they will be produced.
I think the post pretty speculative, given the past and current efforts of Microsoft to get together with OSS and Linux community; using a single slide to come to a conclusion of "Microsoft stopped doing that or has been lying about it" is very speculative.
I think we should give credit where it is due, MS is really trying to work with OSS community.
Also, a lot of enterprise customer would want always on secure boot, and it is up to OEM to decide whatever they want. How is this MS's fault?
Is there any evidence that MS's recent OSS efforts are a reflection of anything other than the fact that Ballmer, who was ideologically against OSS, has left and so now MS can act rationally and use the OSS community the same way many other large companies do?
If working with the OSS community is in their own immediate self interest -- and I'm curious whether someone can point out something they've done that isn't -- I don't know how much light it sheds on an area such as OEMs where their self interest is best served by locking linux out.
One possible direction the industry could go in (suggested by Win 8) is that the "laptop" as we know it could be replaced by tablets, and potentially these could be very low cost devices.
The fly in that ointment is that vendors are not that excited about selling inexpensive machines. For instance, going with the "only a USB 3.1 port" approach would make a lot of sense for a cheap tablet but Apple did it first on a premium laptop because the PC industry had a "who moved my cheese" freakout over Win8 and at the moment the industry has abandoned the race to the bottom.
These super-cheap devices will have very different economics (they'll get a free or cheap Windows license) so a major change in the contract between manufacturers and users is possible.
The negative impact is not on the average Linux user who just runs a distro, but it will be bad for anyone who wants to compile and run their own kernels.
The negative impact is not on the average Linux user who just runs a distro, but it will be bad for anyone who wants to compile and run their own kernels.
It will be bad for the average Linux user, because whoever has the signing keys can decide what Linux distributions a user can run and what versions not.
Let's not forget that e.g. Mint also started out as a distribution with a tiny user base. They are now big, because users could install and try Mint. In a UEFI world without unlockable boot loaders it's game over for OS competition, because parties can be excluded because they are too small, too competitive, or just because.
While some are saying it's only optional and up to the hardware vendors, isn't Microsoft giving Windows7 users a free upgrade? Is this the reason? A potential lock in?
I have no idea why people are downvoting you.This is about requirements for new PCs, not upgrades - nobody is going to get their ROM updated by upgrading to Windows 10.
While there is no real reason given why Microsoft decided to change their policy on Windows 8 / x86 (originally they requested Secure Boot enabled and enforced), I suspect it was due to their large corporate customers. They feared that after the Win8 release they couldn't buy machines without Win8 Logo (probably right) and thus can't image the Windows 7 (or even older) they still used internally onto new machines.
So Microsoft gave them some more time to make the switch, and with pushing Windows 10 like this, they want to purge old Windows versions from the market, and quickly.
In terms of Secure Boot this means that there's no business case (for Microsoft) anymore to keep non-Secure Boot around.
Motherboards bought in stores might omit the option as well. Not hugely likely, but certainly possible. It would probably be more of an oversight though, since it'd kill ~5-10% of their customer base over a menu option.
They're simply easing restrictions on their hardware partners especially since many enterprise customers only want signed software running on their machines.
Yeah I've been reading some more of the informed comments here. The uefi thing turned out to not be that big of a deal. I certainly dont know much about how the hardware sector works. I am just a consumer.
I guess I will not panic until I hear more about this. Though I will now been checking any laptops or mobos I buy for this.
The headline is sensationalist to the point of being false. Microsoft is doing nothing to block Linux on Windows machines. Microsoft is allowing OEMs to ship devices that no longer have an option to disable SecureBoot. Given how they're positioning Windows 10 as a Run All The Things operating system, that's probably just catering to people making low-end IoT devices and tablets and whatever else. Dell and Lenovo have not been chomping at the bit to ban Linux from their laptops, and I doubt they will change anything they're doing now.
> If Microsoft’s stance on this issue is not reversed it’s possible we will see a spike in sales by manufacturers such as System76 and ZaReason who ship computers running Linux out of the box without any signs of Secure Boot at all.
Come on. I prefer BSD based OSX and Linux myself, but to think that a large enough number of buyers care about Linux support to "spike" sellers is just silly. It's done well on servers, but it's a very small market for consumers. Not to mention Ubuntu and RedHat are compatible, so it isn't even an issue for some of the biggest distributions.
> I prefer BSD based OSX and Linux myself, but to think that a large enough number of buyers care about Linux support to "spike" sellers is just silly.
Hopeful rather than silly, I'd say.
Many people like you (who prefer BSD and Linux over MS) are still voting for MS with their wallets (dealing with majority MS manufacturers/sellers) and their discourse (the variations of how it all is "silly").
Right, and those sellers are selling to that market almost exclusively. If buyers from that market then are forced into a situation where it's harder to buy the product they want from other suppliers of course the suppliers supplying it will see a spike. They're capturing a larger portion of a small market.
the only reason my home does not have 4 ms surface pro is because Linux support will be poor.
if they already sold it with dual boot i mighty even be tempted to switch to use windows mostly with time, but on blind faith it ain't going to happen at all.
"All Certified For Windows 8 PCs allow you to trust a noncertified bootloader by adding a signature to the UEFI database, allowing you to run any operating system, including homemade operating systems."
That's listed separately from disabling secure boot, which is what this article (and the previous Ars Technica article) are about.
Is there any reason to think that this part has changed?
1. Without Secure Boot they're open to whatever you want to write.
2. With Secure Boot, they're open to whatever you want to write, as long as it's signed with a key that's trusted by the current database.
So if you can't disable Secure Boot, you need to ask Microsoft to sign your key data, before you can add it. Might as well request a directly signed key (within the MS trust chain) then - from there, you can also overwrite things to honor a new trust chain, and Microsoft is probably more used to requests of this kind than to the other.
Honest question: what's the defense that makes this not monopolistic behavior? This is MS going around trying to get all of the vendors for hardware to switch over to a system for which they are both the client AND the gatekeeper. The end goal is clearly to prevent anyone from entering the consumer operating system space without their express permission, giving them full monopoly over the consumer OS space. This would be like if in 98, they hadn't just been making it difficult to use other browsers, they had been asking all of the other OS vendors to add IE to their systems and disallow everything else that they don't like.
This whole discussion is misguided. It's not about Linux on 'windows machines', there are no such things as 'windows machines', there are only computers. Giving microsoft the ability to lock out their future competition (emphatically not linux) is where it goes wrong. Computers are universal machines, this idiocy makes all this hardware an extension of a single (software!) corporation that gets to decide after you buy the hardware what you can do with it. If I decide to roll my own operating system I'm chanceless to get the kind of support I need in order to get off the ground in the first place.
Imagine Microsoft had had this capability in the early 90's, it would have been a complete disaster. That server you're running linux/FreeBSD/OpenBSD on today would have been running Microsoft software instead.
Well it was apple that started it and now everybody is just following suit ...
If people demanded root on the original 2007 iPhone when realized what really were the capabilities of the device the walled garden model would have been DOA.
People are well trained by now with consoles, tablets, phones and thermostats that it is totally ok for someone else to tell you what to do with the hardware you own ... and only a couple of old (30+) farts like us that remember the wild west years of the internet and computing are kicking against the trend.
For some reason I thought it would be interesting to keep Windows 8 on my laptop to a dual boot with linux. Three hours of blank screen boots later I realized it was the microsoft boot-loader's fault (which absolutely refused to load Linux correctly or to link to a different bootloader, even with secure boot disabled) - and deleted it's entry in the EFI shell.
For the average user installing an OS is hard enough, without the gotchas of figuring out how to correctly adjust BIOS, UEFI and switch bootloaders.
I think the reason Microsoft are allowing OEMs to enforce Secure Boot is because Dell, HP et al are going to sell Windows 10 PCs that only run trusted code. [1]
> With Windows 10 Enterprise edition and specially configured OEM hardware, administrators will be able to completely lock down devices so that they're unable to run untrusted code.
> In this configuration, the only apps that will be allowed to run are those signed by a Microsoft-issued code-signing certificate. That includes any app from the Windows Store as well as desktop apps that have been submitted for approval through Microsoft. Enterprises with internal line of business apps can get their own key generator, which will allow those apps to run on their network but won't work outside the network.
79 comments
[ 339 ms ] story [ 3450 ms ] threadI understand the concern, but the flip side is that if secure boot makes my future Ubuntu laptops more secure that could be a good thing.
Linux is here to stay. Relax.
I'm sure that some vendors will provide an option, so this will just likely be an extra thing to research before buying a new system.
256‽
More importantly, why limit this to linux? It would be a lot harder to develop a new OS - just like Linus did - when you have to deal with secure boot.
How many times has a virus latched onto your computer by executing before your system booted up? I've never heard of this happening to anyone I've ever known.
The only scenario I can imagine is having a PC set to auto-boot from peripherals, and a USB key having something bad execute before invoking your hard disk's boot loader. And that is obviously possible, but terrifying more complex to pull off. But that seems a lot more like a local, physical attack that's much less useful and more targeted than your ordinary viruses that install after executing inside your OS, where viruses seem to have no problems pulling off privilege escalation exploits to gain kernel access then. Plus you can easily block this and then lock down your BIOS already.
It really seems like Secure Boot is solving a problem almost no one ever had. I may well be misunderstanding the point, so please elaborate on how this is useful and absolutely prevents a class of attack that could not be done otherwise.
http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_...
http://www.computerworld.com/s/article/9217953/Rootkit_infec...
A snippet:
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
So the concern is that the virus is installed like any others on Windows; but then it keeps itself installed through the boot process reloading it. Thus it must intentionally damage any internal Windows protections that would try and check for it during its own startup. Which of course would be a cat and mouse game.
Okay then, what stops a theoretical TDL5 from using a Linux distro's signed kernel/bootloader to boot a little mini OS that then does the same thing TDL4 does now? (even if the Secure Boot Linux kernel locks out kernel driver access; maybe it uses a privilege escalation exploit to regain that access)
It would seem like the only way Windows could be absolutely certain that only its own code executed up to the completion of boot would be if Microsoft were the only company that could sign working boot code for a hardware device. The gains in security wouldn't be worth the loss of freedom.
So it is not entirely without precedent.
Then again, this did not touch the OS bootloader itself, strictly speaking and might not have been prevented by "Secure Boot". Also, once you're diddling with a devices firmware, you might as well tamper with "Secure Boot" as well and defang the checking of the bootloader or even make the firmware live-patch the bootloader...
So, while I am by no means a security expert, I have been wondering the same thing. The entire "Secure Boot" stuff just seems like a lame excuse to allow vendors control over what operating systems you can boot on their devices.
From http://www.linuxjournal.com/content/growing-role-uefi-secure...
>Malware developers have increased their attempts to attack the pre-boot environment because operating system and antivirus software vendors have hardened their code. Malware hidden in the firmware is virtually untraceable by the operating system, unless a search specifically targets malware within the firmware. UEFI Secure Boot assists with system firmware, driver and software validation
>Without UEFI Secure Boot, malware developers can more easily take advantage of several pre-boot attack points, including the system-embedded firmware itself, as well as the interval between the firmware initiation and the loading of the operating system
>Nevertheless, in a variety of implementations that have already reached the market, UEFI Secure Boot has proven to be a practical and useful tool for improving platform integrity and successfully defending the point of attack for a dangerous class of pre-operating system malware.
I'd say that there's a better than even chance that the NSA already has Microsoft's secure boot private key.
The NSA and the PRC will get their payloads signed with the appropriate keys. Everyone else will do something cheaper and simpler, like reading their target's gmail accounts.
> So, while I am by no means a security expert, I have been wondering the same thing. The entire "Secure Boot" stuff just seems like a lame excuse to allow vendors control over what operating systems you can boot on their devices.
Yes: http://mjg59.dreamwidth.org/20187.html [1]
[1]: It's worth noting that mjg59 is a big secure boot fan, and did most/all of the Linux implementation.
Although I am a fan, for my own projects, of GPL and AGPL licenses, I do like the availability of commercial apps on Linux. I like Linux because it is a great development platform but I am less of a purist than I used to be concerning an occasional commercial app.
By way of example, the company where I work today produces a hypervisor for x86. We're nowhere near big enough to exert market pressure on someone the size of MS or the hardware manufacturers. When we recently added UEFI support to our product, we looked at support for UEFI secure boot as well. Some systems made key management easy (obvious bios options, etc.), but others made it impossible. Upon investigation, this mostly appears to be more due to apathy on the hardware vendors part than any conspiracy theory, but for an end user the distinction is unimportant. Today we can work-around this by using an MS-signed bootloader shim, but this reduces the security of the end solution (any ms-signed shim will boot, a third party owns the root keys). And, as I mentioned in my comment above, MS can change their policies at any time.
I haven't run into an x86 system yet that doesn't at least allow you to disable secure boot, but the trend towards more locked-down hardware in general (esp. in mobile) worries me due to the potential for anti-competitive behavior towards both commercial and open-source software from third parties.
If you want to use linux simply vote with your dollar and go to the vendors that will let you install it (I imagine most will). That or use a linux distro that is actually compatible with secure boot.
Doesn't this make the feature useless from a security standpoint? If you're able to create your own keys then malware could create its own keys. Maybe if manufacturers could do it that would be handy.
However, flash writing can be limited in hardware, so it would be possible to store Secure Boot keys in a special region of the flash that's locked down right after the opportunity to get to that setup screen passed.
The first time you log in to a server with ssh, it asks you if you should accept the particular fingerprint it just got. You either say yes or no.
Thereafter, if it changes, you get a big fat warning about potentially being hacked.
From a security standpoint, this is no different.
Some of us are not okay with one company charging a gatekeeper fee for access to hardware we already bought from a different company.
We currently pay our manufacturers to install our signing keys into UEFI; this is fantastically expensive. It's a damn shame that it is literally impossible to buy a consumer UEFI device without Microsoft's keys in the image unless you pay to have yours put in.
In short: it sucks that they are the default, and it sucks that Red Hat and Ubuntu rolled over on the issue and pay the (latest) Microsoft tax. I would have preferred a more flexible solution.
Canonical uses kernels without signature checking, where you can just load new kernel modules. In principle this allows to hack into a "Secure Boot" Windows in a day or so (rough draft: have a kernel module, eg. kexec, that runs Tianocore, which can load and run Windows, and pretend the system is "secure" while there's random crap running in the background).
I think Microsoft is silent about Canonical's use of Secure Boot for now, but they might change their tune (and once there's a PoC, they certainly will).
The reason this is absolutely outrageous is that Microsoft gets to say what OS's you're allowed to install, because they control what they sign.
It's whoever implements and controls the BIOS.
The cost alone is one thing, that'd only ruin the ability of hobbyists to create new OSes. Something exceedingly rare anymore, sadly.
But the restrictions stating what your kernel is allowed to let you do is quite another. I want the ability to write my own kernel space drivers on my own hardware, if I so choose (and I have done so in the past.)
So... not a problem. If there is a market for non-Secure Boot machines, they will be produced.
I think we should give credit where it is due, MS is really trying to work with OSS community.
Also, a lot of enterprise customer would want always on secure boot, and it is up to OEM to decide whatever they want. How is this MS's fault?
If working with the OSS community is in their own immediate self interest -- and I'm curious whether someone can point out something they've done that isn't -- I don't know how much light it sheds on an area such as OEMs where their self interest is best served by locking linux out.
One possible direction the industry could go in (suggested by Win 8) is that the "laptop" as we know it could be replaced by tablets, and potentially these could be very low cost devices.
The fly in that ointment is that vendors are not that excited about selling inexpensive machines. For instance, going with the "only a USB 3.1 port" approach would make a lot of sense for a cheap tablet but Apple did it first on a premium laptop because the PC industry had a "who moved my cheese" freakout over Win8 and at the moment the industry has abandoned the race to the bottom.
These super-cheap devices will have very different economics (they'll get a free or cheap Windows license) so a major change in the contract between manufacturers and users is possible.
The negative impact is not on the average Linux user who just runs a distro, but it will be bad for anyone who wants to compile and run their own kernels.
It will be bad for the average Linux user, because whoever has the signing keys can decide what Linux distributions a user can run and what versions not.
Let's not forget that e.g. Mint also started out as a distribution with a tiny user base. They are now big, because users could install and try Mint. In a UEFI world without unlockable boot loaders it's game over for OS competition, because parties can be excluded because they are too small, too competitive, or just because.
Secure boot is part of the BIOS so nope.
While there is no real reason given why Microsoft decided to change their policy on Windows 8 / x86 (originally they requested Secure Boot enabled and enforced), I suspect it was due to their large corporate customers. They feared that after the Win8 release they couldn't buy machines without Win8 Logo (probably right) and thus can't image the Windows 7 (or even older) they still used internally onto new machines.
So Microsoft gave them some more time to make the switch, and with pushing Windows 10 like this, they want to purge old Windows versions from the market, and quickly. In terms of Secure Boot this means that there's no business case (for Microsoft) anymore to keep non-Secure Boot around.
They're simply easing restrictions on their hardware partners especially since many enterprise customers only want signed software running on their machines.
This is really not a big deal.
Come on. I prefer BSD based OSX and Linux myself, but to think that a large enough number of buyers care about Linux support to "spike" sellers is just silly. It's done well on servers, but it's a very small market for consumers. Not to mention Ubuntu and RedHat are compatible, so it isn't even an issue for some of the biggest distributions.
Hopeful rather than silly, I'd say.
Many people like you (who prefer BSD and Linux over MS) are still voting for MS with their wallets (dealing with majority MS manufacturers/sellers) and their discourse (the variations of how it all is "silly").
if they already sold it with dual boot i mighty even be tempted to switch to use windows mostly with time, but on blind faith it ain't going to happen at all.
"All Certified For Windows 8 PCs allow you to trust a noncertified bootloader by adding a signature to the UEFI database, allowing you to run any operating system, including homemade operating systems."
That's listed separately from disabling secure boot, which is what this article (and the previous Ars Technica article) are about.
Is there any reason to think that this part has changed?
1. Without Secure Boot they're open to whatever you want to write.
2. With Secure Boot, they're open to whatever you want to write, as long as it's signed with a key that's trusted by the current database.
So if you can't disable Secure Boot, you need to ask Microsoft to sign your key data, before you can add it. Might as well request a directly signed key (within the MS trust chain) then - from there, you can also overwrite things to honor a new trust chain, and Microsoft is probably more used to requests of this kind than to the other.
Redhat made Linux compliant to this scheme (through Shim), so there's an example for the concept, and "choice".
Imagine Microsoft had had this capability in the early 90's, it would have been a complete disaster. That server you're running linux/FreeBSD/OpenBSD on today would have been running Microsoft software instead.
If people demanded root on the original 2007 iPhone when realized what really were the capabilities of the device the walled garden model would have been DOA.
People are well trained by now with consoles, tablets, phones and thermostats that it is totally ok for someone else to tell you what to do with the hardware you own ... and only a couple of old (30+) farts like us that remember the wild west years of the internet and computing are kicking against the trend.
For the average user installing an OS is hard enough, without the gotchas of figuring out how to correctly adjust BIOS, UEFI and switch bootloaders.
> With Windows 10 Enterprise edition and specially configured OEM hardware, administrators will be able to completely lock down devices so that they're unable to run untrusted code.
> In this configuration, the only apps that will be allowed to run are those signed by a Microsoft-issued code-signing certificate. That includes any app from the Windows Store as well as desktop apps that have been submitted for approval through Microsoft. Enterprises with internal line of business apps can get their own key generator, which will allow those apps to run on their network but won't work outside the network.
[1] http://www.zdnet.com/article/microsoft-reveals-audacious-pla...