HN Theater @HNTheaterMonth

⬐ CaliforniaKarl

Hmmm, looking at the post from u/voltagex_, I'd suggest changing the URL to https://media.ccc.de/v/35c3-9561-first_sednit_uefi_rootkit_u..., and changing the title to "First Sednit UEFI Rootkit Unveiled".

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.

⬐ dang

Ok, we changed the URL from https://threatpost.com/uefi-rootkit-sednit/140420/.

Looks like this work was discussed a few months ago: https://news.ycombinator.com/item?id=18090651

⬐ voltagex_

Writeup: https://www.welivesecurity.com/wp-content/uploads/2018/09/ES...

Video: https://media.ccc.de/v/35c3-9561-first_sednit_uefi_rootkit_u...

⬐ atswimtwobirds

Will this rootkit run on Linux?

⬐ na85

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.

⬐ bcl

The UEFI payload would work on Linux systems, yes. But the delivery system described would not.

⬐ atswimtwobirds

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

⬐ jasonjayr

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.

⬐ mises

New article, but it's old news: https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-r...

⬐ lelandgaunt

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

Promise?

⬐ aortega

Isn't this computrace repurposed? this research is about 10 years old. https://www.blackhat.com/presentations/bh-usa-09/ORTEGA/BHUS...

⬐ cjhanks

I hope it's not too off topic. But on Linux systems with NVIDIA drivers - is it even possible/reasonable to re-enable secure boot?

⬐ paulfurtado

What made you ask about Nvidia drivers specifically?

⬐ Intermernet

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]

[0]: http://download.nvidia.com/XFree86/Linux-x86/390.48/README/i...

⬐ mjg59

Yes, you can add a key with mokutik and sign your locally built drivers.

⬐ bubblethink

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.

⬐ Xylakant

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.

⬐ bubblethink

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.

⬐ cjhanks

Yeah, sounds like it's possible but an unreasonably high burden (imo).

⬐ Xylakant

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.

⬐ CaliforniaKarl

Ah, interesting video! Now I've got something to watch/listen to while I'm on the bus today.

⬐ gammateam

Its interesting that nobody does a SHOW HN on their rootkits on Hackernews

Instead third party stuff like this comes very occassionally

The name is a misnomer

⬐ JetSpiegel

Why do a Show HN for work than can feature on a CCC?

⬐ hug

Only because you're completely unaware of the history of the word "hacker"; It certainly doesn't just mean someone who breaks into other computers.

Reading the old Jargon File entry for the word might clue you in: http://www.catb.org/jargon/html/H/hacker.html

⬐ gammateam

Nah, that doesnt actually explain whats going on now

A) Either people dont post that kind of stuff here, which is still ironic anytime this century

B) People do post and it doesn't get upvoted

C) People do post and it gets moderated away

⬐ rbanffy

I don't think it's ironic at all. It's just that most of us may be a different kind of hacker.

⬐ gammateam

Right......

I get that it was an all encompassing term, but it hasnt been colloquially this entire century

But to be fair, the Pedantic News wouldnt be a misnomer

⬐ self_awareness

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.

⬐ ddevault

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.

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

⬐ peter_d_sherman

Agreed completely.

But remember Hanlon's Razor: "Never attribute to malice that which is adequately explained by stupidity" (https://en.wikipedia.org/wiki/Hanlon%27s_razor).

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>

⬐ vladimirralev

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.

⬐ duckMuppet

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.

⬐ bubblethink

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.

⬐ HankB99

Thanks for clarifying. From the article:

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

⬐ the8472

Have you heard about the intel management engine?

⬐ Sir_Cmpwn

At least the code is presumably sane. Minix is a good system.

⬐ janci

> UEFI is perhaps the single most egregious pile of garbage ever concieved by humans

Don't forget systemd.

⬐ userbinator

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:

https://github.com/tianocore/tianocore.github.io/wiki/Corebo...

On the other hand, I agree with you and Linus on the actual spec itself:

https://yarchive.net/comp/linux/efi.html

⬐ Sir_Cmpwn

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

Quote from the link above

⬐ userbinator

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.

⬐ sandov

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?

⬐ cookiecaper

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.