Machines shipping with Windows 10 may see OEMs enforcing Secure Boot
linuxveda.com
linuxveda.com
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.
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").
I 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.
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.
Redhat made Linux compliant to this scheme (through Shim), so there's an example for the concept, and "choice".
> 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...
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.
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.
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.
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.)
"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.
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.
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.
So... not a problem. If there is a market for non-Secure Boot machines, they will be produced.