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?
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 .
Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection
21–30 of 33 posts
Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection
#22What is SSDT? What's exactly going on in this exploit?
Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection
#23In 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?
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 .
Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection
#24Earlier quoted context omitted.
If by "compromised already at step zero" you mean "just the way computers worked for decades prior to secure boot", then yeah, I suppose. The issue that I have heard people bring up is that it could potentially make it harder to install free and open source operating systems and thus turn consumer-grade and relatively cheap computers into less of a tool that you can use the way you want and more into an appliance. Fo…
Secure boot, when working correctly, prevents the survival of rootkits. This alone is not sufficient, but it is necessary in order to allow a user of a system where a rootkit was installed to know this. 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 boot media that contains your signing keys and then verifies and boots the operating system of your choice.
Implementing this in rushed closed-source system firmware is then purely a misfeature, along with the legitimate concern that it could lead to systems where the device owner can't install their own signing keys. Give people a USB stick with a hardware write protect switch, not signing keys hard-coded in firmware.
Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection
#25Earlier quoted context omitted.
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.
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…
Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection
#26Earlier quoted context omitted.
Secure boot, when working correctly, prevents the survival of rootkits. This alone is not sufficient, but it is necessary in order to allow a user of a system where a rootkit was installed to know this. 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.
> 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…
Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection
#27In 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?
People cheer UEFI failures because Microsoft's actions with Secure Boot and such could align with an effort to eventually completely lock out the ability to install other operating systems on bare metal on hardware you own and don't rent from Microsoft. Microsoft isn't making OEMs only install their own platform keys now, but there's nothing guaranteeing the future will be the same, especially since they can claim to…
Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection
#28Earlier 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`.
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.
Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection
#29Earlier 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`.
Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection
#30Earlier quoted context omitted.
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`.
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.