On Tue, 2026-03-03 at 09:53 -0600, Tom Rini wrote: > On Tue, Mar 03, 2026 at 09:08:59AM +0100, Ahmad Fatoum wrote: > > Hello Tom, > > > > On 3/2/26 23:09, Tom Rini wrote: > > > There is a flaw in how U-Boot verifies and generates signatures for FIT > > > images. To prevent mix and match style attacks, it is recommended to > > > use signed configurations. How this is supposed to work is documented in > > > doc/usage/fit/signature.rst. > > > > > > Crucially, the `hashed-nodes` property of the `signature` node contains > > > which nodes of the FIT device tree were hashed as part of the signature > > > and should be verified. However, this property itself is not part of the > > > hash and can therefore be modified by an attacker. Furthermore, the > > > signature only contains the name of each node and not the path in the > > > device tree to the node. > > > > > > This patch reworks the code to address this specific oversight. > > > > Do I understand correctly that this is a breaking change > > for FIT with signed configurations? > > > > - New U-Boot hashes more than intended for old FIT > > - Old U-Boot hashes less than intended for new FIT > > Sadly yes, similar to:
I'm a bit confused why this doesn't cause an outcry. Aren't both the problem and the proposed fix a disaster for anyone relying on FIT signatures? :-) If I understand the issue description right, the problem is that the `hashed-nodes` property is used for verification as is. I wonder whether a simpler fix that doesn't break compatibility is possible by treating this property differently. Consider the config from the example at https://docs.u-boot.org/en/latest/usage/fit/signature.html: configurations { default = "conf-1"; conf-1 { kernel = "kernel-1"; fdt = "fdt-1"; signature-1 { algo = "sha256,rsa2048"; value = <...conf 1 signature...>; }; }; ... }; The example doesn't actually list the `hashed-nodes` property. It would be hashed-nodes = "/", "/configurations/conf-1", "/images/kernel-1", "/images/kernel-1/hash-1", "/images/fdt-1", "/images/fdt-1/hash-1"; Is there a legitimate use case where this value would be any different? Maybe for adding some unused properties that are only used for documentation purposes? If there aren't such, the `hashed-nodes` value would be actually redundant and can be calculated at verification time. No need to write it into the fit image. So an alternative fix could be to make u-boot work without the `hashed- nodes` property. For backwards compatibility with vulnerable u-boots we could read the value if present. Instead of using it as is, u-boot could calculate the intersection with what it would use. If the result is equal or a subset of the calculated value it's fine to use and an error if not. So even if an attacker can modify the `hashed-nodes` value, u-boot couldn't be tricked to mess up verification. Maybe it makes sense to also issue a warning about unverified properties. cu Ludwig -- Ludwig Nussel Siemens AG www.siemens.com
