[HN Gopher] Decryption through LUKS2 reencryption crash recovery
___________________________________________________________________
Decryption through LUKS2 reencryption crash recovery
Author : beermonster
Score : 126 points
Date : 2022-01-27 14:48 UTC (8 hours ago)
(HTM) web link (seclists.org)
(TXT) w3m dump (seclists.org)
| gray_-_wolf wrote:
| > 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.
| aborsy wrote:
| 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 wrote:
| LUKS should not be used on top of an rclone mount or something
| like that.
| aborsy wrote:
| 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.
| chopin wrote:
| 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?
| Macha wrote:
| 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 wrote:
| 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.
| rjmalagon wrote:
| 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.
| gruez wrote:
| >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.
|
| how's the TPM ecosystem on linux like? On windows bitlocker,
| it mostly just works, but IIRC on linux you had to jump
| through a bunch of hoops to get everything configured.
| Macha wrote:
| It's not auto setup like bitlocker, but once setup it is
| reliable (if your TPM itself is, unlike the Zen 2 fTPM...)
| and working.
| basemi wrote:
| Here a more clear explanation step-by-step of such attack:
|
| https://bugzilla.redhat.com/show_bug.cgi?id=2032401
| TillE wrote:
| It would be a pretty wild design failure if you could just take
| an encrypted drive and quickly crack it.
|
| I mean, unless there's a deliberate backdoor, any half-
| competent drive encryption implementation will require a
| passphrase or key to decrypt.
| dathinab wrote:
| neither
|
| it requires you to:
|
| 1. mess with a device
|
| 2. and then the device to be used (with the proper password)
|
| 3. and then you having access to it again
|
| At lest that, for certain attacks maybe multiple iterations of
| this, not sure.
|
| So it's not braking the main security model: Device Theft =
| Data Theft protection.
| akeck wrote:
| 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?
| lvass wrote:
| 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?
| jiripospisil wrote:
| 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.
| formerly_proven wrote:
| 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 wrote:
| cryptsetup supports using AEAD modes for encryption, primarily
| using AEGIS-128 as algorithm.
|
| Some background information 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/at...
| Aardwolf wrote:
| > 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?
| FeistySkink wrote:
| Does this affect LUKS1?
| basemi wrote:
| 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.
| lvass wrote:
| Is that even possible in a cold device?
| vngzs wrote:
| 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
| FeistySkink wrote:
| I'm sorry for being thick, but this sentence sounds like
| LUKS1 can be update to LUKS2 in-place, so it is affected.
| rjmalagon wrote:
| 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 wrote:
| 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
| rjmalagon wrote:
| Yup, Ubuntu is ongoing in this. Debian is in a better
| shape.
| josephcsible wrote:
| What does this let an attacker do exactly that they couldn't
| already do with a regular evil maid attack?
| jiripospisil wrote:
| Technically you can have access to an encrypted device (e.g.
| USB stick) but not the machine the owner uses to enter the
| passphrase.
| Macha wrote:
| 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.
| mnw21cam wrote:
| 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.
| gruez wrote:
| secureboot can be trivially disabled in firmware.
| rosndo wrote:
| But your computer will complain loudly because it's 2022
| and you use tpm2-totp because that's the normal thing to
| do.
___________________________________________________________________
(page generated 2022-01-27 23:01 UTC)