6 ms·

Decryption through LUKS2 reencryption crash recovery

143 points by beermonster 5y ago

lvass 5y ago
I still don't get how the fix works. If I just mount an external LUKS2 device in an updated system, It's good to go?
- frankjr 5y ago
  The way I understand it the reencryption process now requires additional digest of reencryption metadata. This digest cannot be calculated without knowledge of the passphrase. This means that the attacker can still modify the metadata but cryptsetup will scream loudly when you try to open the device because the digest will be incorrect/missing. So yes, updating the package should be all that's required.
FeistySkink 5y ago
Does this affect LUKS1?
- 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
chopin 5y ago
What's still unclear to me: can you just grab an encrypted device (cold) and decrypt it? Or does the attack require a "live" device i.e one where the passphrase already have been given and the device is online?
- basemi 5y ago
  Here a more clear explanation step-by-step of such attack: https://bugzilla.redhat.com/show_bug.cgi?id=2032401 https://bugzilla.redhat.com/show_bug.cgi?id=2032401
- Macha 5y ago
  From reading the links, you can modify a cold volume, so that next time it's loaded and written, cryptsetup will write out the data decrypted to the disk, so that you can access it cold a second time and the data will be decrypted. So a legitimate user does have to decrypt it in the middle, but you don't need to control what they do or access it the same time they do.
  - lvass 5y ago
    Great explanation, thanks. Now I assume that, having an encrypted external LUKS2 device, if someone may have had access to it I should never decrypt it in a system with a vulnerable cryptsetup version.
  - GekkePrutser 5y ago
    To be fair, once you have the device in your hands you can do other nastiness as well such as loading a modified initramfs (such contains cryptsetup) that intercepts the entered key and writes it somewhere. This part of the boot system is normally not encrypted as it's the very step that asks for the passphrase. Good 'evil maid' mitigations should be sufficient here too, like encrypting at the SSD level with a boot password. However I do wonder if this bypasses secure boot checks as I doubt the Luks header is signed. That's normally an evil maid mitigation but I don't think it'll suffice here.
- rjmalagon 5y ago
  Your second guess is the correct one. This is a bug in the LUKS2 header metadata that can trick the kernel to "recover and resume" an unsolicited decryption/reencryption process. Very hard to do because you need access to the drive and later someone to unlock the modified drive. It as fixed bug, and a plausible scenario is if someone wants to decrypt a LUKS2 (in and old linux kernel system) which is auto unlocked by a TPM like device.
josephcsible 5y ago
What does this let an attacker do exactly that they couldn't already do with a regular evil maid attack?
- Macha 5y ago
  I think this doesn't care about secure boot? As it works on the unauthenticated data, rather than the bootloader + kernel which in a properly configured secure boot system will not boot if modified.
  - gruez 5y ago
    secureboot can be trivially disabled in firmware.
    - rosndo 5y ago
      But your computer will complain loudly because it’s 2022 and you use tpm2-totp because that’s the normal thing to do.
  - mnw21cam 5y ago
    You need to be able to modify the contents of the disc, which implies that either you have managed to boot your own OS or you have been able to temporarily plug the storage into something else. This is as you say a much lower bar to clear than modifying the OS of the device as in a classical evil maid. Effectively, the maid is already built in to the OS in the form of the bug.
- frankjr 5y ago
  Technically you can have access to an encrypted device (e.g. USB stick) but not the machine the owner uses to enter the passphrase.
akeck 5y ago
Some people keep the LUKS2 volume header in a separate file that's encrypted (e.g., with gpg). Would someone still be able to attack a cold volume using this vulnerability in that case?
aborsy 5y ago
Could then NSA crack any LUKS encrypted container held on cloud storage such as Dropbox or GDrive (opened with a key on client side, never entered on server)?
- formerly_proven 5y ago
  LUKS should not be used on top of an rclone mount or something like that.
  - aborsy 5y ago
    The container could be held in a local drive that syncs to a remote, such as Dropbox. The sync will be incremental. Still it’s not a good approach. Also I sometimes use LUKS on top of a LAN network share such as Samba, but I don’t recommend this either. XTS mode and lack of authentication used in disk encryption are drawbacks.
formerly_proven 5y ago
Generally speaking hard drive encryption protects against theft and not tampering. I.e. the idea is that if your laptop or NAS is "lost and found", then you wipe the drive and restore from backup, not continue to use the drive. - Since the protocol used here is broken the fix is to change the protocol - so keep in mind that... > The former reencryption operation (without the additional digest) is no longer supported (reencryption with the digest is not backward compatible). You need to finish in-progress reencryption before updating to new packages. The alternative approach is to perform a repair command from the updated package to recalculate reencryption digest and fix metadata. Just in case you were thinking about upgrading the software during re-encryption - don't.
- zokier 5y ago
  cryptsetup supports using AEAD modes for encryption, primarily using AEGIS-128 as algorithm. Some background information https://arxiv.org/abs/1807.00309 https://arxiv.org/abs/1807.00309 There is also old presentation, which explicitly refers to protecting against "returned disk" scenario: https://archive.fosdem.org/2018/schedule/event/cryptsetup/attachments/slides/2506/export/events/attachments/cryptsetup/slides/2506/fosdem18_cryptsetup_aead.pdf https://archive.fosdem.org/2018/schedule/event/cryptsetup/at...
- sedatk 5y ago
  > Just in case you were thinking about upgrading the software during re-encryption - don't. You'd expect such a critical software had necessary failsafe mechanisms around that.
Aardwolf 5y ago
> LUKS2 online reencryption is an optional extension to allow a user to change the data reencryption key while the data device is available for use during the whole reencryption process. Since it's optional, is it possible to see if this is enabled or disabled, and how to disable it?
gray_-_wolf 5y ago
> The attack is not applicable to LUKS1 format, but the attacker can update metadata in place to LUKS2 format as an additional step. First time I'm glad grub cannot boot LUKS2.
- fernovus 5y ago
  Grub doesn't support LUKS2 encrypting the boot partition with Grub config files inside, but it can decrypt a LUKS2 root partition
  - saladuh 5y ago
    I thought grub2 does support this now?
    - beermonster 5y ago
      LUKS2 is supported with some know limitations [0] Argon2id (cryptsetup default) and Argon2i PBKDFs are not supported, only PBKDF2 is. grub-install does not support creating a core image that could be used for unlocking LUKS2. [0] https://wiki.archlinux.org/title/GRUB#LUKS2 https://wiki.archlinux.org/title/GRUB#LUKS2

143 points by beermonster 5y ago

lvass 5y ago

I still don't get how the fix works. If I just mount an external LUKS2 device in an updated system, It's good to go?

frankjr 5y ago
The way I understand it the reencryption process now requires additional digest of reencryption metadata. This digest cannot be calculated without knowledge of the passphrase. This means that the attacker can still modify the metadata but cryptsetup will scream loudly when you try to open the device because the digest will be incorrect/missing. So yes, updating the package should be all that's required.

FeistySkink 5y ago

Does this affect LUKS1?

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

chopin 5y ago

What's still unclear to me: can you just grab an encrypted device (cold) and decrypt it? Or does the attack require a "live" device i.e one where the passphrase already have been given and the device is online?

basemi 5y ago
Here a more clear explanation step-by-step of such attack: https://bugzilla.redhat.com/show_bug.cgi?id=2032401 https://bugzilla.redhat.com/show_bug.cgi?id=2032401
Macha 5y ago
From reading the links, you can modify a cold volume, so that next time it's loaded and written, cryptsetup will write out the data decrypted to the disk, so that you can access it cold a second time and the data will be decrypted. So a legitimate user does have to decrypt it in the middle, but you don't need to control what they do or access it the same time they do.
- lvass 5y ago
  Great explanation, thanks. Now I assume that, having an encrypted external LUKS2 device, if someone may have had access to it I should never decrypt it in a system with a vulnerable cryptsetup version.
- GekkePrutser 5y ago
  To be fair, once you have the device in your hands you can do other nastiness as well such as loading a modified initramfs (such contains cryptsetup) that intercepts the entered key and writes it somewhere. This part of the boot system is normally not encrypted as it's the very step that asks for the passphrase. Good 'evil maid' mitigations should be sufficient here too, like encrypting at the SSD level with a boot password. However I do wonder if this bypasses secure boot checks as I doubt the Luks header is signed. That's normally an evil maid mitigation but I don't think it'll suffice here.
rjmalagon 5y ago
Your second guess is the correct one. This is a bug in the LUKS2 header metadata that can trick the kernel to "recover and resume" an unsolicited decryption/reencryption process. Very hard to do because you need access to the drive and later someone to unlock the modified drive. It as fixed bug, and a plausible scenario is if someone wants to decrypt a LUKS2 (in and old linux kernel system) which is auto unlocked by a TPM like device.

josephcsible 5y ago

What does this let an attacker do exactly that they couldn't already do with a regular evil maid attack?

Macha 5y ago
I think this doesn't care about secure boot? As it works on the unauthenticated data, rather than the bootloader + kernel which in a properly configured secure boot system will not boot if modified.
- gruez 5y ago
  secureboot can be trivially disabled in firmware.
  - rosndo 5y ago
    But your computer will complain loudly because it’s 2022 and you use tpm2-totp because that’s the normal thing to do.
- mnw21cam 5y ago
  You need to be able to modify the contents of the disc, which implies that either you have managed to boot your own OS or you have been able to temporarily plug the storage into something else. This is as you say a much lower bar to clear than modifying the OS of the device as in a classical evil maid. Effectively, the maid is already built in to the OS in the form of the bug.
frankjr 5y ago
Technically you can have access to an encrypted device (e.g. USB stick) but not the machine the owner uses to enter the passphrase.

akeck 5y ago

Some people keep the LUKS2 volume header in a separate file that's encrypted (e.g., with gpg). Would someone still be able to attack a cold volume using this vulnerability in that case?

aborsy 5y ago

Could then NSA crack any LUKS encrypted container held on cloud storage such as Dropbox or GDrive (opened with a key on client side, never entered on server)?

formerly_proven 5y ago
LUKS should not be used on top of an rclone mount or something like that.
- aborsy 5y ago
  The container could be held in a local drive that syncs to a remote, such as Dropbox. The sync will be incremental. Still it’s not a good approach. Also I sometimes use LUKS on top of a LAN network share such as Samba, but I don’t recommend this either. XTS mode and lack of authentication used in disk encryption are drawbacks.

formerly_proven 5y ago

Generally speaking hard drive encryption protects against theft and not tampering. I.e. the idea is that if your laptop or NAS is "lost and found", then you wipe the drive and restore from backup, not continue to use the drive. - Since the protocol used here is broken the fix is to change the protocol - so keep in mind that... > The former reencryption operation (without the additional digest) is no longer supported (reencryption with the digest is not backward compatible). You need to finish in-progress reencryption before updating to new packages. The alternative approach is to perform a repair command from the updated package to recalculate reencryption digest and fix metadata. Just in case you were thinking about upgrading the software during re-encryption - don't.

zokier 5y ago
cryptsetup supports using AEAD modes for encryption, primarily using AEGIS-128 as algorithm. Some background information https://arxiv.org/abs/1807.00309 https://arxiv.org/abs/1807.00309 There is also old presentation, which explicitly refers to protecting against "returned disk" scenario: https://archive.fosdem.org/2018/schedule/event/cryptsetup/attachments/slides/2506/export/events/attachments/cryptsetup/slides/2506/fosdem18_cryptsetup_aead.pdf https://archive.fosdem.org/2018/schedule/event/cryptsetup/at...
sedatk 5y ago
> Just in case you were thinking about upgrading the software during re-encryption - don't. You'd expect such a critical software had necessary failsafe mechanisms around that.

Aardwolf 5y ago

> LUKS2 online reencryption is an optional extension to allow a user to change the data reencryption key while the data device is available for use during the whole reencryption process. Since it's optional, is it possible to see if this is enabled or disabled, and how to disable it?

gray_-_wolf 5y ago

> The attack is not applicable to LUKS1 format, but the attacker can update metadata in place to LUKS2 format as an additional step. First time I'm glad grub cannot boot LUKS2.

fernovus 5y ago
Grub doesn't support LUKS2 encrypting the boot partition with Grub config files inside, but it can decrypt a LUKS2 root partition
- saladuh 5y ago
  I thought grub2 does support this now?
  - beermonster 5y ago
    LUKS2 is supported with some know limitations [0] Argon2id (cryptsetup default) and Argon2i PBKDFs are not supported, only PBKDF2 is. grub-install does not support creating a core image that could be used for unlocking LUKS2. [0] https://wiki.archlinux.org/title/GRUB#LUKS2 https://wiki.archlinux.org/title/GRUB#LUKS2