Description of problem: Last November, a number of security vulnerabilities were identified in hardware with UEFI firmware, collectively called 'logoFAIL'. Essentially, malicious software is inserted into a POST image, which is then executed at boot before the respective OS has a chance to take over. There were several articles about the subject, with scary-sounding headlines about it affecting both Windows and Linux machines. One example: https://www.zdnet.com/article/this-is-how-to-protect-your-computers-from-logofail-attacks/ The articles explain that the only sure way of avoiding this issue is for the hardware manufacturer to issue a firmware addressing it. Some have done this, especially for newer hardware, but others have not, especially for older hardware. (I have two UEFI machines. One has a firmware update, but the other doesn't.) The articles also explain that in the absence of a firmware update, the only solution is to keep the OS security up-to-date, to protect the hardware from being infected in the first place. Unfortunately, as I understand it, this is where Mageia should make a change. By necessity, the EFI System Partition (/boot/EFI) is a FAT32 partition, and as such can be accessed by anybody, even a bad actor bent on installing Deity-knows-what. The best solution for Mageia would be to somehow change things so that only root can access it. In another discussion, TMB proposed a way to do this: https://bugs.mageia.org/show_bug.cgi?id=20164#c17 The problem is, how to implement this in Mageia? Not being a developer I would think adding it to the installer(s) for new installs would not be particularly difficult, but what about upgrades? And of course, Mageia 9 is also affected, so how would that be addressed? Calling this critical, because as I understand it, an affected user could lose all data.
Whiteboard: (none) => MGA9TOO
We are mixing two topics. To quote zdnet: > I mean, who wants to change the bootup logos on their computers? The answer, according to security expert Bruce Schneier, is companies: "Corporate buyers want the ability to display their own logos. We are talking about a logo at BIOS time. > The trick is to keep attackers from getting access to the EFI System Partition (ESP) in the first place. This is wrong. One can remove the HDD/SSD and still see the manufacturer logo from the BIOS/UEFI. For example, how to change the logo for lenovo: https://ittutorials.net/tutorials/computer-repair/change-bios-boot-screen-logo-image-lenovo-laptops/ This procedure requires to flash the bios. Protecting or not the ESP partition will NOT protect from logofail. But, this is also true that the ESP partition is one element of the chain and being world writable is a security issue. Let imagine a malicious software triggered by a user changed the ESP, replacing the efi file with another that is able to flash the BIOS to add the logoFAIL. This is one possibility, one attack vector in order to exploit the logofail. But this is not the only one realisable exploit with a world-writtable ESP. The recommanded solution does not also prevent physical access. Open the computer, change the .efi, and that's it, even if it is mounted as root-only access. One plausible solution is to develop a security that takes input from the bootchain metrics, this is the purpose of the TPM chip. Altering the BIOS configuration alters the metrics. This does not prevent an attack but this detects an attack.
CC: (none) => j.biernacki+mga
(In reply to Jybz from comment #1) > This procedure requires to flash the bios. Protecting or not the ESP > partition will NOT protect from logofail. From https://www.binarly.io/blog/finding-logofail-the-dangers-of-image-parsing-during-system-boot (posted by the people who discovered this vulnerability): "Normally, the logo is read directly from a firmware volume. Since the volumes are often signed and protected by a hardware-based Verified Boot technology (e.g., Intel Boot Guard), an attacker cannot store a custom logo there — that’s it, as long as the OEM private keys used to sign these sections are not leaked affecting the entire industry. But in this case, an attacker wouldn't care about the logo at all, because it allows them to inject any custom modules instead. "In other cases, OEM-specific customizations allow users to supply their own logo, so attackers can do that too. Most of these OEMs-specific customization read the logo from the EFI System Partition (ESP), a disk partition that is used by system firmware to load additional software such as boot loaders." So protecting the ESP will help protect against logofail on some machines.
CC: (none) => mageia
Thank you Martin, So protecting the esp partition at the mounting time is a protection from users/software during the usage of Mageia. (No protection from physical access, nor from other OS like windows (dual boot). It is a partial protection. But better than nothing. In my opinion; it renders Mageia more robust against new users that are freeing space on ESP partition or using it as exchange partition between linux and windows :D
(In reply to Martin Whitaker from comment #2) > (In reply to Jybz from comment #1) > > This procedure requires to flash the bios. Protecting or not the ESP > > partition will NOT protect from logofail. > > From > https://www.binarly.io/blog/finding-logofail-the-dangers-of-image-parsing- > during-system-boot (posted by the people who discovered this vulnerability): > ... > > "In other cases, OEM-specific customizations allow users to supply their own > logo, so attackers can do that too. Most of these OEMs-specific > customization read the logo from the EFI System Partition (ESP), a disk > partition that is used by system firmware to load additional software such > as boot loaders." > > So protecting the ESP will help protect against logofail on some machines. My Asus Q270M-C motherboard is like that. I purchased it used from a recycler on eBay. Going by the logo at boot time, the 2018 firmware that was on it was customized by the original computer manufacturer, Bytespeed. When I installed Mageia on it in December, I told it to install rEFInd on the ESP. That worked fine, until last week when I decided to check on what firmware updates there were, and what they were supposed to address. I found one that was supposed to address the Spectre/Meltdown issue, and another, from January, that is supposed to address logoFAIL. Now that I knew about it, it was too much to ignore. I downloaded the latest firmware, and installed it. The Bytespeed logo disappeared, replaced by an Asus logo. And, I couldn't boot into Mageia anymore. I spent a lot of precious time going through the firmware settings, until I finally realized that the firmware update must have overwritten refind IN THE EFP. Eventually, I used netinstall to "upgrade" Mageia, telling it at the end to install refind again. (There probably was another way to do that, but by then I had run out of patience. I knew this way would work.) That took care of it - until I decided to turn off display of the boot logo as extra protection. Doing that overwrote refind AGAIN, and it had to be re-installed once more. So, while my UEFI firmware is, according to Asus, now protected from logoFAIL, my EFP still has little protection from bad actors that want to do mischief if I happen to innocently click on a link in a browser or something.
My other UEFI hardware is an HP Pavilion 15 from 2014. It has the latest firmware, from 2017. I've owned it for a couple of years now. It came with (UGH) Windows 8.1 on it, but I soon eliminated that and installed Mageia 8, also choosing refind. It now has two installs of Mageia 9, one primarily for production, the other for QA testing. That firmware is different in that it has no boot logo at all, and I don't see any setting in the firmware to activate one. So, it may well be immune from the logoFAIL vulnerabilities. But, the EFP is NOT protected from alteration. It is still accessible to anybody. I know this because I am able to edit the refind config file as an ordinary user. It's a hole that should be filled.
Changing the summary field to better reflect the issue. This isn't just about logoFAIL vulnerabilities.
Summary: Protecting users from logoFAIL vulnerabilities => /boot/EFI access should be root-only, to avoid unauthorized tampering
FWIW these are what must be our standard permissions for the ESP: lrwxrwxrwx 1 root root 3 Med 27 2022 /boot/efi -> EFI/ drwxrwxrwx 3 root root 1024 Ion 1 1970 /boot/EFI/ drwxrwxrwx 7 root root 1024 Chw 16 2020 /boot/EFI/EFI/ Curious, because I recall having to 'su[do]' to play in the ESP; never mind. This reference in comment 0: https://bugs.mageia.org/show_bug.cgi?id=20164#c17 and the following comment are both simple & clear enough: Changing the ESP mount from: UUID=xxxx-yyyy /boot/EFI vfat iocharset=utf8,umask=000 0 0 to (one line): UUID=xxxx-yyyy /boot/EFI vfat umask=000,iocharset=utf8,rw,uid=0,gid=0,umask=133,dmask=022 0 0 resulted in: drwxr-xr-x 5 root root 4096 Jan 1 1970 /boot/EFI/ drwxr-xr-x 3 root root 4096 Jul 16 2022 /boot/EFI/EFI/ All the background info given in TJ's & Martin's links make it clear that this is really a UEFI firmware issue, and protecting the ESP is - as others have commented - a safeguard better than nothing. And it should be like that anyway.
CC: (none) => lewyssmith
I realised later "Is there any reason for the ESP not to have permissions drwx------ ?". Is there any reason for a user other than root to have any access at all - even read?
Allowing group access gives root the option of adding users to the root group to give them r/w access.
CC: (none) => davidwhodgins
OK; unsure about a 'root group': drwxrwx---
There is a consensus about the need to restrict access to the ESP. Where to place this bug? Installer (both install & upgrade)? Can we do it as an update?
$ rpm -q -f /boot/EFI efi-filesystem-5-3.mga9 $ rpm -q -i efi-filesystem|grep ^Source Source RPM : efi-rpm-macros-5-3.mga9.src.rpm I think it should be done in an update. http://maintdb.mageia.org/efi-rpm-macros shows tv as the assigned maintainer.
Assignee: bugsquad => thierry.vignaudSource RPM: (none) => efi-rpm-macros-5-3.mga9.src.rpm
(In reply to Lewis Smith from comment #8) > I realised later "Is there any reason for the ESP not to have permissions > drwx------ ?". > Is there any reason for a user other than root to have any access at all - > even read? Only possibility I can think of would be if an update for grub2-efi or refind that was authorized by the user through our update app needed to write something there, could it still do it? The only reason that question comes to mind is that we just had a grub2 update a few days ago. I have no idea if it would involve needing /boot/EFI access.
(In reply to Thomas Andrews from comment #13) > (In reply to Lewis Smith from comment #8) > > I realised later "Is there any reason for the ESP not to have permissions > > drwx------ ?". > > Is there any reason for a user other than root to have any access at all - > > even read? > > Only possibility I can think of would be if an update for grub2-efi or > refind that was authorized by the user through our update app needed to > write something there, could it still do it? > > The only reason that question comes to mind is that we just had a grub2 > update a few days ago. I have no idea if it would involve needing /boot/EFI > access. All of our programs that install package updates either run as root, or use PolicyKit to perform privileged operations. Remember, everything outside of "/home" and "/tmp" is protected against writes by normal users, so the only packages that can be updated without privileges are per-user Flatpak installations (which are not the default, and must be manually specified using the "--user" flag). RPMs, and the default system-wide Flatpak installations, always require privileges to update. As such, revoking write permissions (or even all permissions) for "/boot/EFI" from non-root users, should only break malware, not well-behaved programs. Well-behaved programs should already know how to circumvent permission issues. For example, both drakrpm-update (a.k.a. Software Packages Update) and rpmdrake (a.k.a. Install Software Packages) use pkexec-run when they start up, to change their effective user to root; the password requirements to authorise this (root password, current user password, or no password) can be configured in MSEC. For the record, I checked the permissions for "/boot/EFI" on a Linux Mint system, and they're set to "drwx------". Linux Mint doesn't seem to have any problems that result from this.
CC: (none) => penguin.sekai+mageiaidentity.writing
I forgot to add: Ubuntu-based distros (including Mint) deliver security and bugfix patches for GRUB on a regular basis. Denying non-root access to /boot/EFI doesn't cause any problems with this. Aside from that, shouldn't this bug's "Component:" be set to "Security", rather than "RPM Packages"? I know this bug doesn't have a CVE number (because it's specific to our obscure distro), but it's still a genuine security nightmare. We're not just talking about installing malicious UEFI updates on certain machines that are vulnerable to Logofail. Every Mageia installation in UEFI mode (which should be the majority these days) is affected. A malicious unprivileged user (e.g. in a kiosk, an educational institution, a partially compromised server, etc.), or any program that isn't running in a sandbox (or can escape the sandbox, as in Bug 33119), can replace the boot manager or boot loader, thereby achieving privilege escalation, and allowing for the installation of a rootkit.
(In reply to Andrew Piubellini from comment #15) > I forgot to add: Ubuntu-based distros (including Mint) deliver security and > bugfix patches for GRUB on a regular basis. Denying non-root access to > /boot/EFI doesn't cause any problems with this. > > Aside from that, shouldn't this bug's "Component:" be set to "Security", > rather than "RPM Packages"? > I agree. The reason I filed under "rpm packages" was a failure on my part to scroll down in the little window that gave me the choices when I filed. I shall do better in the future. > I know this bug doesn't have a CVE number (because it's specific to our > obscure distro), but it's still a genuine security nightmare. We're not just > talking about installing malicious UEFI updates on certain machines that are > vulnerable to Logofail. Every Mageia installation in UEFI mode (which should > be the majority these days) is affected. A malicious unprivileged user (e.g. > in a kiosk, an educational institution, a partially compromised server, > etc.), or any program that isn't running in a sandbox (or can escape the > sandbox, as in Bug 33119), can replace the boot manager or boot loader, > thereby achieving privilege escalation, and allowing for the installation of > a rootkit. You put it much better than I did, but that is the very reason I filed the bug in the first place. The Logofail situation only brought it to my attention. I did not expect us to address that in particular. Because of the manufacturer's firmware update, my desktop computer is now supposedly safe from Logofail. But, it's still vulnerable to a boot manager/loader replacement.
Component: RPM Packages => SecurityQA Contact: (none) => security
It turns out that changing the setting "WIN_PARTS_UMASK" in MSEC to "077" fixes the issue, apparently by modifying "/etc/fstab", to add "umask=077" as a mount option for every FAT/NTFS filesystem. I've confirmed that, as an unprivileged user, I can still mount a FAT32-formatted USB flash drive, even after altering this setting. That being said, it would be a problem if we blindly rolled out this change to the MSEC setting, via an update to all Mageia users. While this setting doesn't break on-demand mounting of removable storage (so it's a safe default for most users), it would break any system that lists a non-EFI FAT/NTFS partition in "/etc/fstab" (e.g. the user's Windows partition in a dual-boot environment, which they expect to be able to access from Mageia without privileges). We need a solution that only applies the "umask=077" option to partitions with the "EFI" flag.