Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection

git.zx2c4.com

Post reply on HN
Print view View original

31–33 of 33 posts

Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection

#31

Post by fomine3 »

aaron_m04 wrote: post #25
elmo2you wrote: post #9

Earlier quoted context omitted.

You may want to think that statement through a bit more. Secure boot, as the name suggests, secures initial loading of the most central/core parts of an operating system: (indeed) the kernel and kernel modules. While APTs can be installed on different levels, anywhere from kernel up to user space, a good (hard to detect) place for those is inside the kernel itself or in a kernel module. Secure boot is definitely inte…

The person you are replying to is confused about what an APT is. Looks like they think it is a package installed with `apt get`.

FYI: APT = Advanced Persistent Threat

Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection

#32

Post by AnthonyMouse »

tsimionescu wrote: post #26
AnthonyMouse wrote: post #24

Earlier quoted context omitted.

> Without secure boot, it is basically impossible to detect the existence of a well written rootkit, since it can control the OS tmand hide itself from any OS API, whether internal or external. You can detect the existence of a rootkit by booting from known-clean read-only media and then scanning for it. It's even possible to implement "secure boot" this way without any hardware support -- have known-clean read-only…

That does not solve the issue of a corrupted BIOS/UEFI, right? I assume at least that UEFI Secure Boot also protects itself from any attempt to be replaced without proper signed keys. Without this kind of protection, you either have to have a readonly BIOS/UEFI (so no possibility to issue updates), or you have a root-writeable, and so root-kit-able BIOS/UEFI.

You don't need all the firmware to be read-only, only the firmware update code, which can then require a hardware jumper to be set in order to update the firmware. Then the firmware can't be corrupted without physical access to set the jumper, and even if it is, the owner can still re-flash clean firmware because the update code is strictly read-only and therefore still clean.

And you already need to be able to at least detect that someone has had physical access, otherwise you can't even be sure that the device hasn't been replaced with a compromised one that forwards your credentials to the attacker.

Post reply on HN