Hi Ludwig, On Wed, 4 Mar 2026 at 02:22, Nussel, Ludwig <[email protected]> wrote: > > 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.
Yes, I was playing around with that yesterday...I'll try to create a patch. Regards, Simon > > cu > Ludwig > > -- > Ludwig Nussel > Siemens AG > www.siemens.com
