On Thu, Feb 26, 2026 at 02:21:41PM -0500, Stefan Berger wrote: > > > On 2/26/26 1:32 PM, Eric Biggers wrote: > > On Thu, Feb 26, 2026 at 12:22:32PM -0500, Stefan Berger wrote: > > > > I see that IMA indeed never upgraded full file hashes to use > > > > 'struct ima_file_id'. Building a new feature that relies on this seems > > > > like a bad idea though, given that it's a security bug that makes the> > > > > IMA > > > protocol cryptographically ambiguous. I.e., it means that in IMA, > > > > when the contents of some file are signed, that signature is sometimes > > > > also valid for some other file contents which the signer didn't intend. > > > > > > You mean IMA should not sign the digest in the ima_file_id structure but > > > hash the ima_file_id structure in which this file digest is written into > > > (that we currently sign) and sign/verify this digest? And we would do this > > > to avoid two different files (with presumably different content) from > > > having > > > the same hashes leading to the same signature? Which hashes (besides the > > > non-recommended ones) are so weak now that you must not merely sign a > > > file's > > > hash? > > > > > > The problem with this is that older kernels (without patching) won't be > > > able > > > to handle newer signatures. > > > > IMA needs to sign the entire ima_file_id structure, which is indeed what > > IMA already does when it uses that structure. (Well, actually it signs > > a hash of the struct, but that's best thought of an implementation > > detail of legacy signature algorithms that can only sign hashes. For a > > modern algorithm the whole struct should be passed instead.) Just IMA > > uses that structure only for fsverity hashes, which is a bug that makes > > the IMA protocol ambiguous. It needs to use ima_file_id consistently, > > otherwise a signed message sometimes corresponds to multiple unique file > > contents even without a break in the cryptographic hash function. > > Before we jump into making changes on this old stuff I think it's good to > understand the underlying problem and the likelyhood of signatures > validating different data, such as a file and fsverity data. How likely is > this? > > Assuming a strong hash I suppose that is not a concern with RSA because here > the digest is padded and then directly encrypted with the private key. Upon > verification (pub key decrypt) we would unpad and memcmp the digests. > > Again, assuming a strong hash: With ECDSA NIST P256 for example we have a 32 > byte signature. With a SHA512 being used for hashing for example we would be > doing a projection of a 64byte hash space to a 32byte signature space with. > Just by this projection of a much larger space into a smaller space > signatures that validate multiple input data could be a problem. One 'easy' > case where signatures for different input data is the same (not exactly the > same due to nonce involved the signature is verifyable), albeit unlikely, is > that there could be different input data for the SHA512 that lead to the > same 32bytes prefix, which is then used after truncating the sha512 to the > first 32 bytes for the ECDSA signature, and this then leads to a signature > that is verifyable for different input data. So that's the 'simple' case at > least for this thought experiment for a non-expert. > > Now what should still be difficult to do is given a file and a hash-to-use > that you can create fsverity content that leads to a hash that in turn leads > to a NIST-P256 signature that can be used for signature verification(s) of > the file and the totally different fsverity data. Is this a problem that is > as difficult to solve just as finding different input data for a hash that > leads to the same digest?
There's no differentiation between a 'struct ima_file_id' that *represents* the contents of some file, and a file whose contents are *equal to* that 'struct ima_file_id' and that uses a full-file hash. In both cases the same key and message are used for signing and verifying. This means that every time a file is signed using the ima_file_id scheme, it also implicitly signs some other file contents, which an attacker can freely replace the file with. Similarly, every time a file that happens to be a valid ima_file_id is signed using the older scheme, it also implicitly signs the contents that the ima_file_id correspond to, which the attacker can freely replace the file with. In either case, no collision in the cryptographic hash function is required. It's simply a broken protocol. To fix this, IMA must only support signatures that use the ima_file_id scheme. Of course, that will require making them support full-file hashes and not just fsverity hashes. If I recall correctly, this was actually part of the original design of the ima_file_id-based signatures. It's unclear why the implementation is still incomplete. - Eric
