
Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection - zx2c4
https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language.sh
======
jm1337
The author has published a new lockdown bypass that affects the mainline
kernel as well: [https://www.openwall.com/lists/oss-
security/2020/06/15/3](https://www.openwall.com/lists/oss-
security/2020/06/15/3)

------
rswail
Requires the ability to edit information in /boot and to reboot, so
effectively root access but it does circumvent secure boot.

~~~
est31
The idea of secure boot is to have a security level above root. So that even
if you gain root level access, you can't put an APT onto the box or similar.

~~~
rswail
Agreed, so it's definitely a bug. But it does require disabling kernel address
translation and two reboots.

Secure boot doesn't disable installing APTs, it disables installing kernel
modules.

If you want to disable apts etc, you need SELinux or AppArmor or equivalent.

~~~
elmo2you
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 intended to prevent APTs, even if its only a part of
the the full equation. You still need additional tools on top of a kernel,
e.g. SELinux or AppArmor, that monitor, audit and (hopefully) prevent the
introduction of APTs. However, without a trusted kernel (and kernel modules),
all of those tools can be compromised/circumvented, making it ultimately an
impossible task to secure the system as a whole.

~~~
aaron_m04
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`.

~~~
elmo2you
After reading it again, you may indeed be right. I didn't see it the first
time around. My bad.

Still, "installing APTs" as a synonym for installing packages with apt? I
guess I would have noticed it, if it had been "installing DEBs".

Also, using SELinux or AppArmor to disable the ability to install packages
with apt is a new thing to me. But I have to admit that I'm not an expert at
either.

------
rgrs
What is SSDT? What's exactly going on in this exploit?

~~~
rswail
Refer to [https://uefi.org/specifications](https://uefi.org/specifications)

> ACPI defines many tables that provide the interface between an ACPI-
> compliant operating system, and system firmware. This includes
> Differentiated System Description Table (DSDT), Secondary System Description
> Table (SSDT), and Static Resource Affinity Table (SRAT), for example.

[https://en.wikipedia.org/wiki/Advanced_Configuration_and_Pow...](https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface)

------
snuxoll
So building a signed kernel that doesn’t support the nokalsr would be
sufficient to stop this attack.

------
rurban
Never heard of iasl, but it is automatically installed and looks cool.

------
mmm_grayons
Does this affect Debian, or Ubuntu only?

~~~
egberts1
No, and APTs refer to Advanced Persistent Threat (can be an organization, a
malware, but with non-friendly or unintended intent).

And nothing to do with Debian package management that had the command and file
type of “apt”.

~~~
mmm_grayons
Thanks. I'm aware it's not related to the package manager, just wanted to
check.

------
fearingreprisal
Very cool. A very clever exploit.

------
josteink
In every UEFI thread there’s a bunch of critics saying, “See! It doesn’t work!
UEFI secure boot is pointless!”

I say that it takes this much effort to bypass it shows the opposite: that it
_does_ work, it does increase security.

Because without it, you’d be compromised already at step zero.

But like every security measure so far, it’s seemingly not perfect. Nobody is
honestly surprised by that, are they?

~~~
stefan_
This "security" protects the kernel and the boot chain, not any user data. You
will find people care very little about the security of their didn't-even-
know-it-existed-kernel when it protects purely against a scenario _in which
all their fricking data is already considered compromised_.

~~~
anonymousDan
It's an interesting point, but surely it is useful to know when you have been
compromised (e.g. to change passwords)?What about post-infection where you
want to e.g. clean up the machine without reinstalling the OS unnecessarily?
Or in general preventing rootkits from persisting across reboots will at least
help to prevent new data being exposed?

