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)

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.

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.