1. 10
      1. 2

        I have merged stories mnpjst and bqw8wv in to story jb8fpk. Thank you for keeping track of them.

      2. 2

        So, the two situations where this vulnerability applies (requires SecureBoot to be enabled):

        • Inside an already booted system where user-space has write access to the EFI partition, or, in general to the grub.cfg file
        • In an offline attack where someone pulls out the disk, changes the grub.cfg file to exploit this (and inserts an implant which, for example, reads the passphrase for any encrypted root partitions, while you type it) I believe this is an evil maid scenario.

        The outcome is always the same. The attacker gains arbitrary code execution, while bypassing SecureBoot. The most common result: privileged access to the booted system, after the first reboot.

        1. 1

          I think many people are experiencing issues in Europe because of that, and probably soon, US will wake up with the same pain… https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509

          1. 1

            Does this affect VMs? Or is this a pure hardware vuln?

            1. 1

              Read the advisory. It depends on where your VM’s grub.cfg is coming from, which probably depends on exactly what kind of VM you’re using and how it’s booted. If the VM cannot persistently alter its grub.cfg, then no, it isn’t affected.

            2. 1

              An authenticated, local attacker could modify the contents of the GRUB2 configuration file to execute arbitrary code that bypasses signature verification.

              If the attacker can do this, they can also overwrite the whole bootloader with something that bypasses signature verification. If you can do this, your system is already compromised.

              1. 2

                No they can’t. Or rather they can, but if Secure Boot is on the UEFI firmware will refuse to load the modified grub.efi image, so the system won’t boot.

                1. 1

                  So, this vulnerability allows jailbreaking, but does not affect security against attacker without a root password?

                  1. 3

                    How about an attacker armed with a local root privilege escalation vulnerability aiming to achieve persistence?

                    1. 1


                      To do what? They already have root for plenty of persistence. I mean, yeah, they can penetrate deeper. They can also exploit a FS vulnerability or infect HDD or some other peripheral.

                      But that’s just not economical. In most cases, it’s the data they are after. Either to exfiltrate then or to encrypt them.

                      In other cases they are after some industrial controller. Do you seriously believe there to be anyone competent enough to catch the attack but stupid enough not to wipe the whole drive?

                      The only thing I can imagine TEE being used for is device lockdown.

                    2. 1

                      Not sure what you mean by jailbreaking - can you clarify? We’re talking about a laptop/desktop/server context, not mobile. Secure Boot does not necessarily imply that the system is locked down like Apple devices are. See Restricted Boot.

                      If the attacker cannot write to /boot, then they can’t exploit this vulnerability. If the attacker has physical access this probably doesn’t hold true, regardless of whether they have a root password. If the attacker is local and has a root password or a privilege escalation exploit then this also doesn’t hold true, and can be used to persistently infect the system at a much deeper level.