Firmware with corrupted rustboot header run by rustboot

[lionelains]

When manually modifying the flash partition for the current firmware (that previously validated boot), rustboot still boots the firmware in that partition, if it has not been compiled with the defmt feature.

Found in 8437fd2a6ebf79d68a885da895e009fafccfccee

Scenario to reproduce:

1. A board is programmed following the demo process: with rustboot followed by two valid firmwares (the board is ready to upgrade to the second firmware).
2. We let the upgrade process complete until the new firmware has booted properly (rustboot's update_success() is invoked).
3. We now modify the flash content to alter byte at offset +112 within the currently active partition, which is inside the rustboot header (:warning: Flash modifications should however not be accessible to an attacker, but flash corruption may also happen even without an attack)
4. The board is rebooted.
5. At startup, rustboot is executed and goes through partition integrity and authenticity checks, this fails because of the modified flash content
6. The attempt to rollback fails as well.
7. If the defmt feature has not been enabled during build, then no panic() occurs.
8. Execution continues outside of the match and if statements, thus the corrupted firmware is executed.

This has been reproduced on a STM32H723 board.

[lionelains]

After some digging, it appears that this happens only if flash corruption occurs in the rustboot header, and not in the firmware itself. If the firmware is damaged, there is always a panic(), boot will not proceed.

[nihalpasham]

@imrank03 - can you help?

[imrank03]

Sure, I'll go through the scenario and try to reproduce the issue, and I'll get back.

[imrank03]

• We encountered an issue where we modified the content at offset +112, specifically where the public key digest value is located. rustBoot does not currently handle the integrity and authenticity checks for this digest value effectively. As a result, even if we modify the header at offset 112 or alter the digest value, the system still proceeds with the boot process without triggering a failure.

• Additionally, the rollback condition is not handled properly in the rustboot. This causes rollback attempts to fail, leaving the system vulnerable to running compromised firmware.

• The panic() function, which should halt the system if all boot options are exhausted or if an emergency update fails, did not trigger as expected due to a defmt feature condition. This allows the execution to continue outside of the match statement, leading to the BootInSuccessState being executed every time. Consequently, the compromised firmware continues to run, as the system fails to properly handle the integrity and authenticity checks or the rollback process.