I tried this on one of my systems, and indeed, it dropped me to a root busybox shell in initrd. Since my grub is not password protected, this kind of access (and worse) was already trivial on that system. But, LUKS is still encrypted.
Nowadays grub supports what I call total encryption. (It has support for a LUKS encrypted partition, no need for a separate unencrypted/boot directory.) Now a similar vulnerability was present on one of my total-encrypted systems, but in this case it dropped me to a grub rescue environment.
I would be interested to hear what the possibilities are for evil maid attacts in the grub rescue shell scenario, but I don't believe it's possible, because the kernel and the initrd are still encrypted.
So you have a JTAG or EEPROM programmer -- would you know how to fix it if the efivars had just gotten wiped?? I would love to have access to resources and instructions on what needs to happen..!
THIS! Can this be modded up?? (On the other hand, systems are getting hacked, so just using bash works...) Also, it needs reiterating that all those Androids and routers commonly don't have any bash on board.
I think you got that backwards. Canonical started using systemd because Debian picked it. Also, Canonical doesn't do Gnome3 shell on their main offering, so how do you see any strongarming in this decision?
Slashdot Mirror
I tried this on one of my systems, and indeed, it dropped me to a root busybox shell in initrd. Since my grub is not password protected, this kind of access (and worse) was already trivial on that system. But, LUKS is still encrypted.
Nowadays grub supports what I call total encryption. (It has support for a LUKS encrypted partition, no need for a separate unencrypted /boot directory.) Now a similar vulnerability was present on one of my total-encrypted systems, but in this case it dropped me to a grub rescue environment.
I would be interested to hear what the possibilities are for evil maid attacts in the grub rescue shell scenario, but I don't believe it's possible, because the kernel and the initrd are still encrypted.
It has been said, but the vulnerability is not in cryptsetup, but in initramfs.
So you have a JTAG or EEPROM programmer -- would you know how to fix it if the efivars had just gotten wiped?? I would love to have access to resources and instructions on what needs to happen..!
Number 4 (>/dev/sda) doesn't really do anything, as /dev/sda is a block device. On a regular file it would get truncated to length zero.
THIS! Can this be modded up?? (On the other hand, systems are getting hacked, so just using bash works...)
Also, it needs reiterating that all those Androids and routers commonly don't have any bash on board.
I think you got that backwards. Canonical started using systemd because Debian picked it. Also, Canonical doesn't do Gnome3 shell on their main offering, so how do you see any strongarming in this decision?