Hi Greg, Adding Mikulas and dm-devel. We are requesting CVE IDs for the issues fixed by the two commits already included in released kernels: 24d7e5e39b04 and 8bde1033f9cf.
On (3), we understand the timing concern. It has not appeared in a release yet, so we will return to it once v7.3 has shipped. The substance below applies regardless. > If this is such a serious issue, why was it not marked for any stable > backports at all? The commit message explains that integritysetup versions before 2.8.7 pass "fix_hmac" on open even when the user specifies --integrity-legacy-hmac. Backporting the fix before 2.8.7 is available would therefore break activation with older userspace. > Also, "raw write access" is not something that dm-integrity is supposed > to protect against, right? The documentation states: > "the section number is mixed to the mac, so that an attacker can't copy > sectors from one journal section to another journal section ... disallow > the attacker to move sectors from one disk to another." These are cryptographic properties that are meaningful when an attacker can write to the backing device. In (1), the superblock protection was not enforced. Clearing the flag disables verification entirely, defeating standalone keyed-HMAC mode. > We can assign this, but why? We are preparing a write-up of our dm-integrity analysis and would like an unambiguous CVE identifier for each issue. The fixes are also already in stable kernels, and downstreams shipping guest images may need CVE IDs to determine whether they are covered. > Again, I didn't think that unrestricted access to a backing block device > was part of the threat model here. And the whole "confidential vm" > threat model is constantly being argued about Issues (1) and (3) require neither timing observations nor single-stepping and are not specific to confidential VMs. They enable offline forgeries by any attacker who can write to the backing device, such as an untrusted storage backend, a compromised NBD or iSCSI target, or someone handling a disk outside the owner's control. Issue (2) is a standard constant-time cryptography concern. The fix brings dm-integrity in line with the rest of the kernel, which uses crypto_memneq() for exactly this purpose. Concretely: - (1) Clearing SB_FLAG_FIXED_HMAC in the on-disk superblock via a direct write is sufficient. The target then activates without verifying the superblock MAC, after which the remaining superblock fields can be modified freely. - (3) Overwriting a block's tag with 0xf6 bytes causes the block to be returned without HMAC verification, so attacker-chosen content is accepted as authentic. In both cases, exploitation requires only a single write to the backing device and no key material. We have working PoCs for all three issues and can send them off-list. Mikulas, we would welcome your view on 24d7e5e39b04 and 8bde1033f9cf, and on whether backporting the former makes sense once integritysetup 2.8.7 is available. Kind regards, Shukai Ni and Jo Van Bulck DistriNet, KU Leuven
