UEFI is perhaps the single most egregious pile of garbage ever concieved by humans. I don't think it's possible to overstate how awful it truly is.
Here's how BIOS works: basically, the computer loads the first 512 bytes of disk into memory and jumps to it. The OS takes over from there and does whatever it needs to, like bootstrapping stage 2 and loading the kernel from the filesystem. The spec[0] is 46 pages long and you are granted the rights to reproduce, distribute, and implement it free of charge.
Want to know how UEFI works? The spec[1] is a 2,899 page PDF which you have to pay to use in any way, including writing an implementation.
Every copy of this specification should be found and burned. The ashes should be buried deep in a dark place and the earth above salted. Anyone who thinks this is the first rootkit made for it is completely insane. This thing was probably explicitly designed with rootkits in mind.
which you have to pay to use in any way, including writing an implementation
You may be misleading here, AFAIK the spec is free to implement (which helped spread its adoption) or else things like this would not exist or be sued out of existence:
>By downloading any of the UEFI Specifications, you acknowledge that no license, express or implied, is granted to you to distribute, additionally reproduce, implement or otherwise use for any purpose (other than to read only) the UEFI Specifications, and that all rights, title and interest in and to the UEFI Specifications, including all intellectual property rights of any type whatsoever, are owned by the UEFI Forum, or subject to rights granted to the UEFI Forum.
That is really a worthless statement compared to threats of legal action against the various open-source implementation out there, which would definitely raise attention --- if they actually happened, that is; I haven't found anything to suggest so.
A search for "UEFI royalties" also does not yield anything.
We get it, you hate UEFI as much as anyone else, but this is not really a valid issue to complain about.
For the record, TianoCore is run by Intel. Intel was the author of the original EFI spec and afaik remains the driving force on the UEFI Forum. Wouldn't make much sense for them to sue themselves.
You're basically acknowledging that they can sue you for implementing it, but they won't do it because they don't feel like doing so, hence it doesn't matter that they can?
UEFI smells like it was designed by a committee, so the value it adds (if any) seems far outweighed by the added complexity (and corresponding security challenges) it creates... to paraphrase Douglas Adams: (and replacing the word "Universe" with "BIOS":)
“There is a theory which states that if ever anyone discovers exactly what the BIOS is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable... There is another theory which states that this has already happened...” <g>
Don't forget the corollary to Hanlon's razor, Grey's law which i think is far more applicable here:
'Any sufficiently advanced incompetence is indistinguishable from malice'.
I'm not sure why others who respond think if something is old it isn't applicable, I suppose I'm on the X/millennial border so I don't get it though.
People should stop quoting this "Never attribute to malice that which is adequately explained by stupidity". It's very outdated. Every malicious person is just playing dumb these days.
The exploit in particular is SPI write bypass. That's the critical part, which is independent of UEFI. That is a separate Intel SMM vulnerability. If you can compromise the bios region, you can do whatever you want with the boot process, UEFI or not.
>Each time the system restarts, the code executes on boot, before the OS loads and before the system’s antivirus software is launched. That means that even if the device’s hard drive is replaced, the LoJack software will still operate.
AFAIK on my systems the BIOS launches code in the EFI partition to boot the rest of the OS. an HDD/SSD wipe or replacement would defeat code installed in the EFI partition. Of course as you say, something added to the BIOS would run regardless.
Apparently LoJack installs itself in the BIOS as well.
The original URL (https://threatpost.com/uefi-rootkit-sednit/140420/) looks like a short writeup, but I'm not sure if it adds any new content. And given the tendency to link back directly to source, it's probably worth a change.
According to the video, the root kit discussed does not work on Linux, it involves a dropper that writes a Windows service .exe to the NTFS volume. They have not seen a version that runs on Linux Or MacOS.
"Secure Boot" mode also doesn't protect against the rootkit, because it considers the contents of the UEFI Bios in the SPI Flash the root of trust, and does not do any verification at that stage. It only verifies the bootloader, which loads the OS.
It abuses platforms that do not implement the BIOS Write Lock mechanism incorrectly. (the BIOS is supposed to be write protected after UEFI Boot services hands stuff over to the Operating system)
Incidentally, (according to the video) BitLocker disk encryption can defeat it, though the legitimate LoJack system has a way of working with BitLocker. I think the implication is that a more advanced version of the rootkit may, in the future, work with BitLocker.
This comment was flag killed but I've vouched for it because I think it is a legitimate question posed by someone without domain expertise.
To someone who perhaps does not fully understand the implications of a uefi rootkit, the article might seem to imply that it wouldn't work on anything but windows.
>> It abuses platforms that do not implement the BIOS Write Lock mechanism incorrectly
I agree that post-boot the BIOS should be read-only.
> The UEFI payload would work on Linux systems, yes. But the delivery system described would not.
There was a case of rm -rf / erasing UEFI variables on linux system, rendering the system unbootable. Mapping the BIOS into the file-system doesn't strike me as too clever, but then again what do I know.
> The purpose of the legitimate LoJack software is to help victims of a stolen laptop be able to access their PC without tipping off the bad guys who stole it.
But does it buy you any real security at that point ? If the private key is stored on the file system, a local root exploit can just as easily use the key to sign whatever it wants. I don't even see the benefit or the threat model of secureboot on regular linux disros.
Don’t store the private key on the local filesystem then. Use a USB stick or build and sign the modules on a separate machine. Depending on your threat model, a strong passphrase on the signing key might already go a long way.
I'm no so sure about that. Unless you are using an android/chromeos like system, secureboot alone itself is quite ineffective to begin with because your filesystem is writable. And keeping the private key elsewhere, while possible in theory, would just add too much friction. For instance, apt install nvidia-xxx won't work.
Sure, security adds friction. Whether the added friction is worth the added security in your case depends on the amount of friction and the amount of security it buys you. The trade off is likely different for you than it is for a larger org. For example, you (or the admins responsible for your org) could maintain an apt repo with signed nvidia drivers for your org. This would reduce the friction by centralizing the signing process.
I keep my signing key on my machine, but gpg-encrypted bound to a yubikey. Is that frictionless? No, certainly not. Does it provide perfect security? No, certainly not. A dedicated attacker can root my box and wait until I need to sign a module. Does it protect me from loading random kernel modules if I get hit by an automated attack? Most likely. Good enough for what I currently expect as threats.
The Nvidia drivers are binary-only kernel modules that involve re-signing when installed.
> Some kernels may require that kernel modules be cryptographically signed by a key trusted by the kernel in order to be loaded. In particular, many distributions require modules to be signed when loaded into kernels running on UEFI systems with Secure Boot enabled.[0]
Jargon File entries are not really high quality definitions and some of them are simply wrong or deprecated since at least 20 years.
I.e. 'cracker' is used for people that 'crack' software protections (games or applications). I've never heard about "warez d00dz", and none of my friends from the "warez scene" did. Also the Jargon files describe crackers in a very pejorative meaning, while in reality the cracker's social circle contain lots of very skilled individuals, as well as is pretty well filtered-out from anyone that doesn't dedicate themselves to the cracker community. Maybe this is the reason why Eric Raymond didn't have much info about this topic.
So I wouldn't put much faith in Jargon file entries in the same way I wouldn't trust any other urban dictionary. Maybe it's good to get a general grasp at some subject but taking definitions from it is pretty misleading.
Here's how BIOS works: basically, the computer loads the first 512 bytes of disk into memory and jumps to it. The OS takes over from there and does whatever it needs to, like bootstrapping stage 2 and loading the kernel from the filesystem. The spec[0] is 46 pages long and you are granted the rights to reproduce, distribute, and implement it free of charge.
Want to know how UEFI works? The spec[1] is a 2,899 page PDF which you have to pay to use in any way, including writing an implementation.
[0] https://web.archive.org/web/20110715081320/http://www.phoeni...
[1] https://uefi.org/specifications
Every copy of this specification should be found and burned. The ashes should be buried deep in a dark place and the earth above salted. Anyone who thinks this is the first rootkit made for it is completely insane. This thing was probably explicitly designed with rootkits in mind.