3 ms·

From the article: > The attack is not applicable to LUKS1 format, but the attacker can update metadata in place to LUKS2 format as an additional step.

by basemi 5y ago

FeistySkink 5y ago
I'm sorry for being thick, but this sentence sounds like LUKS1 can be update to LUKS2 in-place, so it is affected.
- rjmalagon 5y ago
  It is a fixed bug. Your target needs to be an outdated Linux distro. In a current one or patched one, is more likely to have a non-vulnerable LUKS2 volume that you can not downgrade to a vulnerable one, or a kernel and userspace tools non-vulnerable to the metadata manipulation even for a LUKS1 volume. I concede the plausible scenario of replacing the kernel to a vulnerable one, if you ha access to the drive (by external OS boot or get the hardware) and replacing the kernel on the usually unencrypted boot partition along modifying the LUKS2 metadata of the encrypted volume. Not a quick local or remote feat to do. Not doable on an encrypted boot volume or signed boot files (secure boot thingy). Sincerely, if you have that kind of access, it is easier to modify the initramfs file to grab the LUKS key.
  - pmontra 5y ago
    Not so outdated. No Ubuntu version has the fix up to now. They think 18.04 is not affected [1] Ubuntu 21.10 Needed Ubuntu 21.04 Ignored (reached end-of-life) Ubuntu 20.04 Needed Ubuntu 18.04 Not vulnerable (code not present) [1] https://ubuntu.com/security/CVE-2021-4122 https://ubuntu.com/security/CVE-2021-4122
    - rjmalagon 5y ago
      Yup, Ubuntu is ongoing in this. Debian is in a better shape.
lvass 5y ago
Is that even possible in a cold device?
- vngzs 5y ago
  According to [0] attacks from a cold device require two steps of physical access. That would bypass signed contents of a boot partition, since you're messing with unprotected LUKS header contents. If the contents of the boot partition are unsigned there are probably easier attacks available. You could, for instance, deploy a kernel with crafted reencryption logic baked in over the default boot kernel. That wouldn't require this vulnerability, because the victim will be typing the passphrase into the attacker's (unprotected) kernel from /boot. [0]: https://bugzilla.redhat.com/show_bug.cgi?id=2032401 https://bugzilla.redhat.com/show_bug.cgi?id=2032401

From the article: > The attack is not applicable to LUKS1 format, but the attacker can update metadata in place to LUKS2 format as an additional step.

by basemi 5y ago

From the article: > The attack is not applicable to LUKS1 format, but the attacker can update metadata in place to LUKS2 format as an additional step.

FeistySkink 5y ago

I'm sorry for being thick, but this sentence sounds like LUKS1 can be update to LUKS2 in-place, so it is affected.

rjmalagon 5y ago
It is a fixed bug. Your target needs to be an outdated Linux distro. In a current one or patched one, is more likely to have a non-vulnerable LUKS2 volume that you can not downgrade to a vulnerable one, or a kernel and userspace tools non-vulnerable to the metadata manipulation even for a LUKS1 volume. I concede the plausible scenario of replacing the kernel to a vulnerable one, if you ha access to the drive (by external OS boot or get the hardware) and replacing the kernel on the usually unencrypted boot partition along modifying the LUKS2 metadata of the encrypted volume. Not a quick local or remote feat to do. Not doable on an encrypted boot volume or signed boot files (secure boot thingy). Sincerely, if you have that kind of access, it is easier to modify the initramfs file to grab the LUKS key.
- pmontra 5y ago
  Not so outdated. No Ubuntu version has the fix up to now. They think 18.04 is not affected [1] Ubuntu 21.10 Needed Ubuntu 21.04 Ignored (reached end-of-life) Ubuntu 20.04 Needed Ubuntu 18.04 Not vulnerable (code not present) [1] https://ubuntu.com/security/CVE-2021-4122 https://ubuntu.com/security/CVE-2021-4122
  - rjmalagon 5y ago
    Yup, Ubuntu is ongoing in this. Debian is in a better shape.

lvass 5y ago

Is that even possible in a cold device?

vngzs 5y ago
According to [0] attacks from a cold device require two steps of physical access. That would bypass signed contents of a boot partition, since you're messing with unprotected LUKS header contents. If the contents of the boot partition are unsigned there are probably easier attacks available. You could, for instance, deploy a kernel with crafted reencryption logic baked in over the default boot kernel. That wouldn't require this vulnerability, because the victim will be typing the passphrase into the attacker's (unprotected) kernel from /boot. [0]: https://bugzilla.redhat.com/show_bug.cgi?id=2032401 https://bugzilla.redhat.com/show_bug.cgi?id=2032401