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