What are potential security implications of using older unsupported motherboards/laptops that do not get BIOS(UEFI) updates anymore, but run an up to date GNU/Linux distribution? Do measures like using secure boot or setting up a BIOS password help mitigate any of the potential threats?
3 Answers
Most security vulnerabilities that can be mitigated by firmware are either microarchitectural side-channel attacks (such as the Spectre class of vulnerabilities), or issues that can only be exploited from a superuser context. In most threat models, an exploited superuser is game over.
Secure Boot can help prevent malware persistence, and a BIOS password makes the computer a bit more secure in the hands of a non-motivated and non-sophisticated physical attacker. None of those help mitigate the kinds of issues that can be caused by outdated firmware.
Sometimes vulnerabilities are discovered that can be mitigated by setting MSRs (Model-Specific Registers) or tweaking certain "chicken bits" in the microcode. While it is true that the UEFI does not have much to do with the running system beyond SMM (System Management Mode), it is not entirely true that outdated firmware has no security implications. You can use the popular CHIPSEC framework to check for security vulnerabilities. They have a very detailed manual explaining how to use their modules. The framework is described on their GitHub page:
CHIPSEC is a framework for analyzing the security of PC platforms including hardware, system firmware (BIOS/UEFI), and platform components. It includes a security test suite, tools for accessing various low level interfaces, and forensic capabilities. It can be run on Windows, Linux, Mac OS X and UEFI shell.
CHIPSEC can alert you to various security issues in your firmware. In some cases, although not all, only updating the firmware can mitigate them. You might be surprised at how many issues your old computer has that cannot be reasonably mitigated if the firmware cannot be updated.
Once the machine is booted, the bios has no involvement in the system (except for TPM), so in general, there are no security implications for lack of bios updates after boot.
However, if there are bugs in the secure boot and tpm path itself, then there may be ways to hack the machine before or during boot. In some cases, this is a serious problem, but in many cases, it's fairly irrelevant. Obviously, if there are bugs in secure boot, secure boot isn't going to mitigate the issue well.
The exception to this is (mostly enterprise level) machines with a base board management controller that runs independent from the rest of the system. If there are bugs in that firmware, the boot state of the machine is not relevant. Bugs in the BMC network stack can be a huge problem, but in general the BMC should be on a protected network anyway. Bugs there could even affect availability rather than integrity, as the BMC monitors system temperatures and adjusts fan speeds, so a bug there could cause the machine to burn out or fail prematurely. (I have seen multiple bios/firmware updates to fix BMC fan speeds on multiple platforms and architectures, and even had some machines burn out due to this; it's a real issue.)
SoHo PCs/laptops: no threat whatsoever aside from physical but updates or no updates will not help you deal with this. For normal devices BIOS/EFI should have zero network attack vectors if your software is updated, secure and set up properly.
Corporate managed workstations: Intel ME and AMD PSP have seen quite a large number of vulnerabilities, including remote ones but corporations should have strict LAN access policies which should mitigate that.
Do measures like using secure boot or setting up a BIOS password help mitigate any of the potential threats?
For an attacker with physical access it's nearly completely useless unless you also use full disk encryption and TPM. Even if both are used, the attacked may implant something, including a hardware keylogger and all the protections are bust.
Secure boot in case of Linux only allows to make sure your boot loader, kernel and its modules are signed. The Linux kernel will then happily run everything and anything, so if your userspace is compromised one way or another, secure boot and BIOS password won't make any difference.
Windows is secured much better because absolute most Windows userspace components (binaries and shared libraries) are digitally signed, so you can be sure that the entire boot chain is verified. Even in this case there are multiple ways to have the system pertinently infected with malware which can use CMD, PowerShell, VBS, etc. scripts to run and those can be stored in a ton of places including the registry, Windows Task Scheduler and many others. Hackers find new ways to store malware in Windows without touching any normal files all the time.
-
For those like me who need to look up what "SoHo" stands for in this context, it's "Small office/Home office". Commented Aug 25, 2022 at 23:58
-
1You can use signed executables on Linux using either IMA or dm-verity. In fact, most mobile devices based on Linux use this to secure their entire boot chain.– forestCommented Aug 26, 2022 at 1:07
-
This is a question about PCs/laptops/servers/workstations, not mobile devices. Mobile devices such as smartphones and tables, don't have a concept of BIOS/EFI at all. It's there but its part of ROM. Commented Aug 26, 2022 at 5:01
-
Of course I've got downvotes based on forest's answer but oh boy people love very rare exceptions here, and again "Bugs in the BMC network stack can be a huge problem, but in general the BMC should be on a protected network anyway" - exactly as I said in my answer. As for transient execution vulnerabilities those are fixed by microcode updates which come to you if you keep your system up to date. If you downvote, at least make it clear why. Commented Aug 26, 2022 at 7:00