[PATCH] FIT: Address Secure Boot Bypass for Signed FIT Images

[Nussel, Ludwig]

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