New vicious UEFI bootkit vuln found for Windows 8 Security researchers have discovered security shortcomings in Windows 8 that create a means to infect the upcoming operating system with rootkit-style malware. Italian security consultants ITSEC discovered the security hole following an analysis of the Unified Extensible Firmware Interface (UEFI), a successor to the legacy …
"I think he needs a hug! Come here, you scamp!"
There's a poster that doesn't know me, and my impressively low personal hygiene standards.
But evidently "we're bored" was incorrect on my part. I'm f***ing bored of the "a'ha, me hearties" s****. Is everybody happy now?
If you can't manage to go into your BIOS and change the secure boot to 'custom' or 'off', it really is best that you don't attempt to install Linux anyway.
There are around 2 billion computer users in the world. Around 1.8 billion Windows users would benefit from secure boot by eliminating traditional rootkits. It will slightly inconvenience 40 million, for the sake of 1.8 billion. Stop being so selfish.
(I'm having a competition for downvotes with this message so don't feel shy if you want to knee jerk)
If you can't manage to go into your BIOS and change the secure boot to 'custom' or 'off', it really is best that you don't attempt to install Linux anyway.
On the face of it you're correct, except that the BIOS doesn't have to have an off switch. Bit of a bugger then if you get a machine and find you can't turn it off.
I'd be happy with them mandating an off-switch (whether hardware or software) personally, but others obviously differ on this one!
"On the face of it you're correct, except that the BIOS doesn't have to have an off switch. Bit of a bugger then if you get a machine and find you can't turn it off."
You're in luck. Microsoft have required manufacturers to allow a physically present user to turn off Secure Boot on any x86 system. It's part of the specification that has to be met in order to receive a Windows 8 sticker.
This post has been deleted by its author
Yes! I've! Just! Been Caught! OUT! by This! F%^cking! Madness!
Sorry about that - just couldn't resist annoying all those posters that are "F^&cking pissed off with every headline concerning Yahoo!"
Erhum.... Getting back on subject...
I've just been caught out by this unawares on my new Asus laptop (to replace my HP laptop that "fried" due to the well known design flaw. Upon trying to boo from the USB universal recovery stick (Yum, Ubuntu Live, etc.) only to discover that it no longer worked. I discovered that the laptop had all thie Uefi/MS lock (sorry, Secure Boot) crap on it - AFTER I had already added all my applications to the installation! I am now in the midst of the long drawn-out process of imaging the partitions to convert the primary drive to MBR so I can get back to normal and finish my multi-boot setup!
F^&^cking Microsoft! Grrrrr.......
It is Microsoft's way of "enhancing its partners offerings"; by making sure that competing O/Ses are locked out, and that it will be difficult to install alternatives, or to upgrade the installed O/S.
It all boils down to this:
do we trust the OEMs to make it convenient for end users to
a) install their own keys for either alternative O/S installs (assuming the end user wants a "Secure Boot" experience), or
b) to allow to the end user to install keys for upgrades to the existing O/S
The reason why I mentioned "b)" is that without that capability, your desktop becomes essentially a "brick", and in order to upgrade the O/S, you may have to buy new hardware, and we all know that makes M$' hardware partners very happy. They must look at the cell phone market with envy - just look at all of those ilemmings who go out and splurge hard earned cash on the newest Jesus phone. Those greedy bastards (OEMs) want their share too!!
I think that was just because he was starting service, for which you need to be an administrator (usually.)
However I'm not sure where the problem is, is it a UEFI (ie: non-MS) or a Windows (ie: MS) problem? The whole point of UEFI is that if the OS has been compromised, it shouldn't allow it to load, so even if Windows allows its system files to be replaced, UEFI secureboot shouldn't let it boot.
While it may stop that particular nasty, if you think that Microsoft, with all the money they have and time they've had, were really concerned about stopping those nastys I'd have to say your wrong. Microsoft is far more concerned about stopping the usage of Linux on work and home computers. I use Linux Mint (Maya) and I can tell you that it works great, including with online (web delivered) games that my children, ages 5 and 7, enjoy. To recap - Linux works great, the OS doesn't get in your way and it's NOT Microsoft, hhhmmm, Microsoft must kill it. I wouldn't be surprised to learn that Microsoft and the UEFI knew about this long ago or even designed it into the software to shut out all other OSs.
"I wouldn't be surprised to learn that Microsoft and the UEFI knew about this long ago or even designed it into the software to shut out all other OSs."
You have a demonstrated attack that threatens any installed OS (Ubuntu, Windows, BeOS, anything), a countermeasure released by a specifications foundation made up overwhelmingly by hardware manufacturers which protects against it and which can be (and is) used by multiple OS producers (MS, Red Hat, Ubuntu) and somehow this becomes an attempt by MS and "the UEFI" (what the BIOS replacement running on my motherboard?) to shut out all other OS's?
Yep, it's a blatant attempt to shut out any unauthorized (by MS) OS. You want the proof ? All those hardware manufacturers under the visionary lead of Microsoft "wink wink" forgot to allow more than one encryption key so Microsoft is the only one who can decide what OS will run on a secure booted hardware.
Oh, and please stop mentioning RedHat and Ubuntu, their OS will run only if their boot loader is signed by Microsoft. As for computer OEMs neutrality, don't bother explaining it.
Which is exactly what Microsoft require for certification and exactly what the Linux fanboys have been complaining about, saying it has no value.
No, what the Linux ... er ... supporters have been saying (more or less) is that a system that can only boot Windows has no value (to them).
The Secure Boot feature of UEFI has the potential to make a PC much more secure (if it is turned on) but it also has the potential to be used to lock the hardware to boot only an OS signed by a particular vendor/distributor. Used sensibly it can provide security without lock-in, used as Microsoft want it provides security only for Microsoft OSes, and for other OSes whose binaries have been signed by Microsoft.
Secure Boot relies on cryptographic keys stored on the motherboard. When Secure Boot is enabled the UEFI firmware will only allow the system to boot from an image that has been signed using one of those keys. It's perfectly possible to design UEFI firmware that allows the user to install new sets of keys with which to verify signatures on different systems -- so if I wanted to run Ubuntu I'd install a key certificate published by Canonical, and so on. No such facility is mandated by the UEFI spec, but at least some UEFI implementations do support it.
There is a concern that malware might be able to add fraudulent certificates to the onboard store, but it would be possible to prevent this by fitting a physical switch that would have to be activated to enable certificate installation.
What some Linux vendors are actually doing is to provide their own bootloader which will be signed using Microsoft's keys (for which Microsoft will doubtless make a charge) and making that bootloader responsible for checking the signatures on the OS kernel that it subsequently loads. That's a bit simpler for the end user to deal with, but does mean that MS get paid a fee for the ability to run a non-MS OS.
"and for other OSes whose binaries have been signed by Microsoft."
This part is wrong and the rest of your post follows from it. Red Hat asked MS to provide them a key because MS offered it cheaper than Red Hat could do it themselves. There's no requirement that a key be provided by Microsoft.
Now it's your turn to be wrong. Microsoft does not provide a key, Red Hat asked Microsoft to sign its boot loader with MS key. Reason is simple, you can not have multiple keys in UEFI. You will have either Microsoft key or your key (in case hardware manufacturer allows you to change it)
And while they are at it, turn on DEP/ASLR/SEHOP for everything too as default.
Oh and mandatory password for Admin accounts as default too.
Then that's most of it.
It's all there just MS always wimps out from turning all the security on.
"I can install a penguin based OS on a "Built for Windos" machine?"
Your question shows a misunderstanding. UEFI is not Secure Boot. Secure Boot is a feature of UEFI. And Secure Boot actually prevents this attack so this is not an exploit that would allow you to bypass it and install a Linux bootloader. But your question is also a red herring as you already could if it's an x86 machine. Microsoft certification requires that the user be able to turn off Secure Boot which is all you need. On RT platforms you cannot turn off Secure Boot, but this isn't a work around for Secure Boot anyway, so it wont let you install an ARM Linux on a WinRT device.
I'm interested - not exactly sure how UEFI works yet, but does this mean:-
a. An UEFI enabled Windows PC could be "rooted" legitimately to enable a dual-boot?
b. A MS tablet with enforced UEFI could be legitimately rooted to enable an Android or Ubuntu install?
Also, is this exploit open source?
And before I forget, "Yaarr!"
From reading the different specs, for the vast majority of Win 8 PCs, it will be possible to enable a dual-boot. As someone else already said, SUSE, RedHat, and Ubuntu all showed a working implementation of booting a PC with Secure Boot fully enabled.
As for turning off Secure Boot, the average Linux user can easily do that on just about any Win 8 Certified system. It was pretty clear from the early Win 8 development flame wars that Microsoft has no interest in using THIS to kill Linux.
It appears the WinRT ARM Tablets (and notebooks) will be extremely difficult to create a dual-boot version in the field, but then their hardware is are pretty different from the current Android tablets. I guess if you spent the time on creating a working Android, you might be able to figure out how to get it installed on a system.
He's simply said Microsoft isn't interested in using Secure Boot to kill Linux. It would tick off too many people and be crossing a legal line in Microsoft's case since they don't own the UEFI code. That's why the PC versions require an ON/OFF switch, to show that Microsoft isn't coercing the OEMs. The tablets are another story because that is supposed to be a total-package solution that requires end-to-end protection. Different rules.
So when Microsoft after a decade of trial and error finally gets it right about security, they hand it over to a bunch of people who have no clue about security and best coding practice in general, the BIOS and firmware makers. I'm having a bit of hard time figuring out who are the real Muppets here.
Hmm, so if I'm reading this correctly... it actually seems to me that using the UEFI kit means that you can easily bypass all the much touted security in a linux install, as most won't run with SecureBoot (?). So what will the FOSS crowd do now?
Oddly, blaming MS for this feels a bit off. Given that it's designed to make a system more secure, why would anyone want to disable it? I'm not sure why the linux crews can't actually bite the bullet on this one and use the functionality present, as surely that would make everything even more secure.
My guess is that as it's a Microsoft requested feature, it MUST be evil. Right?
Unfortunately I'm not exactly the best qualified to answer this, but here goes.
As I understand it the problem is basically MS hijacking the territory re secure boot, and demanding that OEMs implement UEFI by default, without any obligation to give other OS providers an automatic right to be able to have their own keys for authentication by the UEFI system, i.e. everybody has to go cap in hand to MS.
Ubuntu and Redhat have already sorted a deal with MS, but everyone else will have to have UEFI disabled.
Anyone else is welcome to correct the above.
"Unfortunately I'm not exactly the best qualified to answer this, but here goes."
Just thinking that puts you ahead of a lot of posters here. ;)
"As I understand it the problem is basically MS hijacking the territory re secure boot, and demanding that OEMs implement UEFI by default, without any obligation to give other OS providers an automatic right to be able to have their own keys for authentication by the UEFI system, i.e. everybody has to go cap in hand to MS.
This is incorrect. You don't have to get a certificate from MS to have a signed boot loader. Indeed, you don't actually need a signed boot loader just because a device is UEFI, only if it's using Secure Boot which is a feature of UEFI that can be turned on or off by the device manufacturer and usually by the user also. (And note, UEFI is not the property of Microsoft. It's the new BIOS). You can get a signature from a number of places or even do it all yourself if you want to. Red Hat bought a certificate for their boot loader from Microsoft because MS had the infrastructure in place and were cheapest. They could have done it themselves but this would have cost them a lot more. They're actually saving themselves money by buying what they need from Microsoft.
"Ubuntu and Redhat have already sorted a deal with MS, but everyone else will have to have UEFI disabled."
Point of clarification: not UEFI disabled, but Secure Boot disabled. Think of it like turning off AHCI in the BIOS, with UEFI being the BIOS. Note, MS require any x86 devices to allow disabling of Secure Boot as part of their certification process, so signatures wont be needed except for ARM devices which makes them similar to things like the iPad.
"Anyone else is welcome to correct the above."
Likewise, if I've got anything wrong in *my* explanation, someone do my post the same courtesy.
There are things that need some correction here.
Red hat did not buy a certificate, they paid Microsoft to sign the RH boot loader with MS key. Don't you find it weird that you can provide your own keys without any problem but Red Hat couldn't ? As for the infrastructure, the same way got their key certified, Red Hat could do it too but it wouldn't help Linux users. The real problem is that hardware manufacturers can load only one key by default which so far happens to be Microsoft key (surprised ?). Besides that, due to the "special" bond between computer OEMs and Microsoft, all computer manufacturers will camp outside Microsoft's door waiting in line to get the keys to Windows garden, Red Hat will have to beg each manufacturer individually to load their key on their systems. Now knowing how Microsoft is pricing Windows licenses according to the volume of computers sold with non-Windows OS (remember, only one key allowed), I doubt hardware manufacturers will be very cooperative. See it's not that difficult when you know the history of Microsoft!
Buy this man a case of beer!!!!
Why, you may ask?
He understands the problem, and the nefarious schemes M$ has "up its sleeve"
Allow me to highlight the relevant portions of his comment:
As I understand it the problem is basically MS hijacking the territory re secure boot, and demanding that OEMs implement UEFI by default, without any obligation to give other OS providers an automatic right to be able to have their own keys for authentication by the UEFI system, i.e. everybody has to go cap in hand to MS.
I see all the MS fans have come out on this one. Expressing their support for their favourite software company holding the entire PC manufacturing industry to ransom with the "if your UEFI systems don't do secure boot, you can't have a 'Certified for Windows' badge for them" and therefore will have difficulty selling your systems in competition with all those who comply with our blackmail.
You are seemingly unaware that both Red Hat and Ubuntu also use Secure Boot. It's a security feature that is not limited to MS and there's no "holding the entire PC manufacturing industry to ransom". They have mandated that Secure Boot can be disabled on any x86 device thus enabling any OS manufacturer to take advantage of this security feature. Is that what you're angry about?
"And what have they (MS) mandated for any non-x86 device (Windows RT or whatever the name is today)? Why the difference?"
Why are you asking questions that have already been answered several times? As you perfectly well know, WinRT devices come with Secure Boot turned on and not configurable by the user (as far as I'm aware). Presumably the difference is because MS want to sell these things as a complete hardware+software solution, like the iPad. It's a shame. Hopefully they will be forced to change this and allow keys from other OS's to be installed.
So switched off mechanisms don't work? this isn't a windows 8 problem beyond people turning off secure boot against all the warnings, why would someone running a Win8 box do this, only folks running other OSes would do this and then how exactly is it microsoft's fault if you get stung? Distros that don't get a way of preventing the bootloader being changed are surely opening their users to unacceptable risk., if the hardware supports it it's almost criminal not to do so too, even if MS proposed parts of it.
Normally, an OS can not allow and at the same time prevent modifying the boot-loader. This is possible only if OS is not under your control a.k.a. DRM. Why would you pay for an OS that does not trust you ?
Folks running other OS do not want to disable secure boot but in detailing the specs, Microsoft had no objection to UEFI storing and using one single encryption key (Microsoft's one, of course) so those folks have to disable secure boot if they want to run other OS than the one Microsoft dictates (f.y.i. including older or not authorized versions of Windows).
"Why would you pay for an OS that does not trust you ?"
Because malware operates on the principle that the OS cannot tell the difference between "you" telling it something and the malware telling it something. You don't complain about the OS not trusting you if the hash of a downloaded program doesn't match what it's supposed to be, so why are you complaining about the fingerprint of the boot loader not matching what it's supposed to be? Its not any more the OS not trusting you than your virus scanner checking a program you are installing.
"Folks running other OS do not want to disable secure boot but in detailing the specs, Microsoft had no objection to UEFI storing and using one single encryption key (Microsoft's one, of course) so those folks have to disable secure boot if they want to run other OS than the one Microsoft dictates (f.y.i. including older or not authorized versions of Windows)."
Microsoft also had no objection to people storing more than one single encryption key (they are already selling keys to Red Hat for a small fee and Red Hat could do it themselves if they wanted). Besides, what is wrong with turning off the security feature if you don't want it? It's no more difficult than turning off your virus scanner if you don't want it.
"You're being largely misinformed here. Microsoft is not selling keys, they are signing boot loaders with their own key so there is still one single key being used, Microsoft key. Please stop spreading incorrect information."
There was no intent to cause any confusion. The signature used to verify a boot loader or OS by UEFI is called a "platform key". The service Microsoft are providing is to sign and include Red Hat's platform keys. So the statement is correct. Red Hat's VP Tim Burke uses the same terminology I do in their press release: Microsoft will provide keys for Windows and Red Hat will provide keys for Red Hat Enterprise Linux and Fedora".
There are multiple keys. I wasn't clear in what I wrote, though. Sorry about that - unintentional.
I've gone back and read my original post. I did write "selling keys to Red Hat". Badly put - I should have written signing the keys Red Hat provides for a fee. But it's a bit like when you buy a certificate from Verisign for your website. Technically you're actually creating your own key and you're paying them to acknowledge it. Same thing. Anyway, apologies for any confusion. My point and logic is the same, but please substitute in the above terminology.
What "security hole"? This quote says it all: “Our research attempts to show the industry that the new UEFI platform is still as insecure as the old BIOS technology, it's still vulnerable to the old attacks IF the SecureBoot technology is not turned on by default,”
UEFI 2.3.1 requires a mechanism like Secure Boot to be truly useful. So if you enable the security features as designed, then it prevents the malware threats the authors claim to have "discovered".
This is a junk article, for sure, and those “researchers” should be embarrassed.
The attacker had to have physical access (or root access) to that machine to install it.
Now if he had root access, he could do anything in user-space, regardless of the boot process, so that's not the interesting case.
If he had physical access he could do one of the following:
Install a hardware keylogger/replace the keyboard with a bugged one of the same model
re-flash the service MPU (if it's a good laptop) to log keystrokes.
change the service-mode firmware (x86 code running along with your OS, but with higher privileges)
change the firmware of your north- and south bridge (yes, there are processors in there with full RAM access)
There are many ways to manipulate a system once you have physical access. Secure Boot only pretends to close one of them.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
