Why does shim/mokmanager allow to circumvent _ALL_ protections of SecureBoot? And how to fix it?

Solution 1:

This is an official response posted by Thomas Ward (while wearing his server team / dev hat) on behalf of the Ubuntu Security Team itself, relaying from their IRC channel with direct quotes

The Ubuntu Security Team, in response to me triaging this to the Security Team, has gotten back to me regarding this issue. I am going to direct-quote Alex Murray from the Security Team (amurray in #ubuntu-hardened on the Freenode IRC network):

This is an intentional choice to allow the user to be able to enrol their own cert since they have resigned grub/shim anyway - if they want to use their own certs etc then they should rebuild shim without this or just remove the mokmanager binary itself - since we don't do TPM-backed full-disk-encryption there are a number of ways to still do evil maid style attacks currently and this is just one of them

-- amurray, #ubuntu-hardened, Freenode IRC, April 26, 2020 22:25:28 UTC-4

As such, the Ubuntu Security Team acknowledges that this is an risk, but that it is an intentional choice to leave this as is.

If you want to protect against this, remove mokmanager binaries or rebuild shim without the ability to adjust the certs.

In either case, Ubuntu does not do any TPM Backed Full Disk Encryption, so there are a number of ways to do this 'evil maid' style attack. While the Ubuntu Security Team acknowledges this, they do not consider this as something that needs immediate action given that this was an intentional choice.

Keep in mind also - mokmanager gives the user the warning about the keys, and as such it's up to the user or the admin who set the system up to accept the risk - this is fixable by simply removing mokmanager entirely thereby hardening the system and NOT providing a mechanism to change those keys via this vector. However, there's still ways to do this kind of attack in other ways.

Solution 2:

To answer your most pressing questions:

Why does shim/mokmanager allow to circumvent ALL protections of SecureBoot? And how to fix it? The answer to why is simple but it can't be provided based on what sounds like a misconception of what Secure Boot actually is, what it's intended for, and why Sim/MokManager was designed to allow end-users to self-sign there own certificates. First we have to dispel the notion of "Secureboot" being any form of 'security' per se or in the sense of an attack dog meant to defend and protect your hardware, it is merely...

...a security standard developed by members of the PC industry to help make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM). (Secure Boot, Microsoft Windows Hardware Developer )

So another way to look at it, is that it is a software verification checker of sorts. While there is some validity to your concerns regarding a BIOS password, there are other technologies your system probably has that serve the function you are looking for. Such as, a TPM hardware device which can also be activated through the BIOS, locked with a password, and sometimes physically removed for added protection. It's probably more in line with what you were hoping secure boot did and is known as a Trusted Platform Module (TPM), and represents technology designed to provide hardware-based, security-related functions.

A TPM chip is a secure crypto-processor that helps you with actions such as generating, storing, and limiting the use of cryptographic keys. Many TPMs include multiple physical security mechanisms to make it tamper resistant, and malicious software is unable to tamper with the security functions of the TPM. Microsoft Hardware Developer Documentation

So with that in mind, if you're not already familiar with the difference between UEFI on while Secure Boot (On), and UEFI on with Secure Boot (Off), or with Legacy Mode on and UEFI off with Secure Boot off, then you may not be familiar with why we need it and you can read more about why it had been created and why Ubuntu had to expand support for it some way, some how. Simply put, with so many different OS packages out there, some companies simply can't make hundreds of iterations of their driver library files for each distro in order to sign them off and that meant if users wanted to install some for of Linux, they'd face a risk of of not being able to use any hardware that this situation applied., You can learn more about that here.

To wrap it up with your other questions:

Am I right? To an extent...

Maybe I missing something or misunderstood something? The most important factor actually...

I had an impression that only owner of keys can replace bootloaders/EFI/kernels (otherwise, EvilMaid attacks become possible, stealing LUKS passwords becomes an easy task, and so on...) You're right about that, but the more accurate impression would be to consider, it's true only the owner of keys can do those things, if they're not otherwise willing to wipe the whole system to take the hardware or something else instead. But essentially your data would be fairly safe while anyone with the owner physical access to your device has the [potential to replace your bootloader/kernels and enter your system but there is a very very heavy emphasis on potential. And, it's why I say you're forgetting or missing the most important factor of your device's security, and that's YOU! No sarcasm. This means, that yes, there are things you can do that will make it so that only you (or technically the holder of the key) is the only one able to access your device and gather any sort of data from it. Since Grub 2 and as early as Ubuntu 14.04.

Are there workarounds? The strongest of them all, besides just a good strong password is to separate your LUKS2 headers and install them on a separate drive. Most people install their system all one one hard drive, allowing the default partitions. But, if you kept your boot partition on a separate USB drive and (hopefully with at least one backup, no one could access anything on your computer without that USB drive. There's no chance of infecting your bootloader if there's no bootloader stored locally! And with an instantly loading screen of no operating system, chances are Be that as it may, let's examine the realistic nature of these concerns as they're well-warranted but are they very likely to occur? Unless you're a high=power official or corporate's board member, or a simply friggin rich person who'd be the target of a coordinated espionage attack, chances are and average joe isn't going to go snooping into your room to do an Evil Maid attack on your system. But, even if they did, you can easily protect yourself by being more careful, taking advantage of the built-in safe most hotels have. (I mean, if you're doing well enough to be a target, you can afford the rooms with safes, practically all hotel rooms have them, at least, domestically).

Can I remove MokManager (mmx64.efi) completely? Is it possible to remove the behavior, make it "less helpful"? You could... go back to Legacy mode and turn off UEFI mode, at least that's the easiest way. Of course, it's not necessarily the "safest" but I think we've established that's all relative by now. MokManager is there to help you, if you remove it and find yourself wondering why a program wont run or a game wont start, might just be the driver from the repo isn't going to work and you need to download the Nvidia driver or something, so it's there to help you bypass driver signature enforcements which cause security warning that only appears because you're likely taking a machine that once had Windows, was built for Windows, and was intended to be used with Windows software but preferred to use it on Ubuntu and to facilitate that, they had to figure out how to work with Ubuntu.

Finally, in case it wasn't emphasized enough, bear in mind that it really is about physical access to your device. These Evil Maid, LUKS header extraction methods and whatnot, require an attacker to be physically present to implement them. Sure, it's true they can hack you in OTHER ways over the internet, but in terms of what you're concerned about, if they could get that close to your property, wouldn't you be more protective of your possessions anyway?

Software protection and encryption is not an excuse for recklessness. Take the precautionary steps and do more on your end. And to speak brief only your comment on retrieving a LUKS password being an easy task I wouldn't go that far. I mean, it's easy to carry a 15 lb backpack when you go to school right, but if you had to carry it around20 to 40 years, it might still be "easy" in a sense, but is it worth the $500 bucks to wear it for that long? To get an idea of what it might be like to watch a brute force password attack on a LUKS encrypted, you could much more quickly consider the math: It's fairly simple, if they know almost nothing about the password and we pretend what they did know was that its 9 characters long, and they know it doesn't have any symbols guess every possible letter, whether it's lower case or upper case, an integer or a letter, that would be the probability of 62^9 iterations or 13,537,086,546,263,552 combinations and at a cracking hash rate of 100M/s this would require more than 4 years to complete. So you can imagine the amount of trouble it would require from them to even want to bother to go out and try to retrieve some of the data off of some random person. Unless it's the patent for a hovering vehicle, as long as you do your due diligence, you can manage to be safe.