1

Here is what I have done:

  1. Generated my own SSL keys (db, KEK, PK) x (cer, key)
  2. Removed existing signatures from kernel, GRUB, shim (and all other EFI binaries in /boot) and signed them with my own certificate (db).
  3. Rebooted and enrolled my certificates in UEFI (which moved it to User Mode).

So far so good. I was hoping that starting from this point, an adversary has only two ways of changing my bootloaders (GRUB):

  • Go to UEFI and disable SecureBoot (=> needs a password)
  • Compromise my private KEK key (or PK), which authorise changes in db (or KEK) EFI variable, which will allow adding another certificate, which can sign another bootloader.

BUT

What happens in reality, is shim DOES detect that GRUB is compromised/modified, it shows this:

ERROR
Verification failed: (0x1A) Security Violation
<OK>

and then, when I press <OK>, it happily offers me to add another key(!)

Press any key to perform MOK management

Enroll key from disk

Obviously, it breaks entire "chain of trust" - it makes all previous steps useless, in some sense it is a backdoor (I understand that it is trying to be helpful, too helpful probably...).

Questions

  1. Am I right? Maybe I missing something or misunderstood something? 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...)
  2. Are there workarounds? Can I remove MokManager (mmx64.efi) completely? Is it possible to remove the behaviour, make it "less helpful"?

P.S.

Just in case you were wondering, what about grub.cfg / initrd... - I am using standalone version of GRUB that checks GPG signatures of everything it loads (set check_signatures=enforce)

Update

In the end I decided to get rid of the chain: shim -> grub/grub.cfg > initrd -> linux kernel entirely (as each transition has to be verified).

Instead, it is possible to boot kernel directly (unified kernel image). More info, as well as tools can be found here.

1
  • 1
    REVIEWERS AND USERS: This has been forwarded to the Ubuntu Security Team. The Ubuntu Security Team has indicated that because this has been up already in the public eye for a day, this does not need to be switched to a deleted / embargoed state. DO NOT put flags on this post that this needs embargoed - the Security Team has indicated we can leave it open/visible for now. They will investigate this further, regardless.
    – Thomas Ward
    Apr 26 at 17:52
2

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.

1

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.

7
  • Just a couple of clarifications below. Your bruteforce time calculations do not take into account PBKDF settings. Essentially I can choose arbitrary time for just one attempt. I can make just one attempt to take 10minutes. Google for "LUKS PBKDF Argon2"
    – DimanNe
    Sep 27 at 8:20
  • Nevertheless, stealing LUKS password is easy (if you can compromise boot chain, which shim allows) - just create a fake password prompt. There were even demos on YouTube. But here is text description - whonix.org/wiki/AEM "so a false password prompt later appears. When the victim inputs the password, it is sent to the attacker and the compromised firmware removes itself."
    – DimanNe
    Sep 27 at 8:31
  • > You could... go back to Legacy mode and turn off UEFI mode, at least that's the easiest way. There is another way - EFIStub. It allows you to boot directly into signed Linux kernel (unified image of linux kernel + initrd made as an EFI binary, to be more precise). It is also much faster.
    – DimanNe
    Sep 27 at 8:36
  • And one one final remark. It seems that your answer is mostly about (1) the fact that there are much easier ways to compromise / attack and (2) whatever I do it is not bulletproof. I agree with both statements 100%. However, the original question was specifically about shim/mok, and it was about reducing attack surface (not making it bulletproof, which is indeed impossible).
    – DimanNe
    Sep 27 at 8:39
  • 1
    Regardless of the fact though, my apologizes, I digress. This topic seems to revisit, and for good reason, a conversation that also stirred up individuals at Defcon 21 back in 2013 where a conversation between the developers of TrueCrypt and Joanna Rutkowska, a security researcher was paraphrased to highlight the defeated point of encryption vs a defeated point of carrying around an impenetrable strongbox to keep our data safe. As if for every bit of security we give up, we gain a bit of convenience that can later be given up for a bit more security.
    – Doedigo
    Sep 27 at 10:50
0

I don't see how it "breaks the entire chain of trust:. It warned the local human with physical access to the machine that the chain of trust was broken, then let the human make the executive decision on what do about it.

That's the expected behavior.

There is, fundamentally, no set of defenses that is completely effective against a skilled human with access to the hardware and time to abuse that access (a different standard than a traditional "Evil Maid" attack). If there were, it's unlikely that any of us would be able to install Ubuntu on our Desktop PCs and Laptops in the first place -- we would be forever stuck with whatever OS came from the vendor.

I'm not sure this shows a high-priority vulnerability. Everything in /boot is owned by root, so seems like this process requires an attacker to have already gained root some other way.

8
  • > It warned the local human. It warned a local adversary (who does not have my keys (which I can keep on a Yubikey which has a hardware-backed PIN entry counter), and allowed the adversary to replace my bootloaders in such a way that I will not be able to notice it.
    – DimanNe
    Apr 25 at 20:39
  • Yep, addressed by the final paragraph. There's a reason server room has a lock and a surveillance camera. Security is a multi-layered sandwich.
    – user535733
    Apr 25 at 20:42
  • 1
    Discussion of such workaround is the Security Team's lane. You should ask this question in the Security section of discourse.ubuntu.com or the Security Team's IRC channel
    – user535733
    Apr 25 at 20:47
  • 1
    @DimanNe you'll have to provide minimum exploitable execution examples, and take that to the Ubuntu Security Team. However, I don't believe there's a way to directly accept anything via shim/mok without any user interaction whatsoever, so while the risk may exist, it's probably still minimal and considered a 'local' attack vector as the user would still have to do something and can't directly be executed as a 'remote' attack. (using CVSS metric definitions of this)
    – Thomas Ward
    Apr 25 at 21:15
  • 1
    All: Refer to my comment on the question - this is something that I forwarded to the Security team and they will dig more on this. Discussions surrounding this of a speculating nature are not helpful, PoCs and such should be sent to the Ubuntu Security Team - contact details can be found at: wiki.ubuntu.com/SecurityTeam/Contacts
    – Thomas Ward
    Apr 26 at 17:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.