Re: two questions on verified boot

[Dhananjay Phadke <dphadke@linux.microsoft.com>]

On 11/21/2021 6:55 AM, Rasmus Villemoes wrote:
> (2) Assuming for the moment that I would be happy with just using
> required=image, am I right in that not only does that mean that the
> combination of kernel/fdt/initramfs is not verified, merely the
> individual parts, but more importantly (a mix'n'match attack isn't
> really very likely), _only_ the data property in each node is part of
> what gets signed, not the other important properties such as load= and
> entry=? IOW, suppose I have a FIT image with
> 
> and I know that the boot process uses $loadaddr = 0x40000000. What is to
> stop me from modifying that FIT image to read
> 
> where 0xabcde is chosen to coincide with where the data part of the
> pwned property lies in the modified FIT? (That pwned property can be put
> anywhere; I could even just replace the signer-name property inside the
> signature node with a value of "mkimage\0<padding><my payload>".)
> 
> In fit_config_process_sig(), there's this elaborate dance with
> fit_config_get_data()/fdt_find_regions() which, AFAICT, ends up
> including all the property values (and the FDT_PROP tags and string
> offsets etc.), and then we call info.crypto->sign() with some
> appropriate region_count. But in fit_image_process_sig(), we call
> info.crypto->sign() with nregions==1, and AFAICT, the data being signed
> is just the value of the "data" property, nothing else.
Couldn't agree more, I've been wondering on similar lines. It would be
great to actually run digest over entire image (data + attributes) or
config node (minus signature and hash subnodes if re-signing). It would
have avoided CVE-2020-10648?

Regards,
Dhananjay