[TW#18644] Secure Boot enabled before checking partition table signature

[catalinio]

Hi,
In the SecureBoot description there is this paragraph:

NOTE Secure boot won’t be enabled until after a valid partition table and app image have been flashed. This is to prevent accidents before the system is fully configured.

After I've checked the code from bootloader_start.c, it seems that if I flash: bootloader(with Secure Boot enabled), partitions.bin and application.bin; then the SecureBoot efuse (ABS_DONE_0) is set, even if partitions and application are not signed (or wrong SHA digest).

Basically, what happens:

1. Bootloader started, Secure Boot efuse is not written (yet) so partition and application are not checked
2. Secure Boot is enabled (Flash Encryption is enabled), and application is loaded successful
3. after first reset, the partition and application are checked, and fail, so bootloader is stuck

Solution here, would be to re-sign partition and application and re-flash them on serial.

More tragic, is that if Flash Encryption is enabled, all the partitions (bootloader, parition table, factory app) are encrypted (with the secret efuse key). I guess, the esp32 chip is bricked; can't even use OTA for updating.

[negativekelvin]

It looks like partition table is not checked

esp-idf/components/bootloader/subproject/main/bootloader_start.c

Lines 148 to 151 in f8bda32

	#ifdef CONFIG_SECURE_BOOT_ENABLED
	if(esp_secure_boot_enabled()) {
	ESP_LOGI(TAG, "Verifying partition table signature...");
	err = esp_secure_boot_verify_signature(ESP_PARTITION_TABLE_ADDR, ESP_PARTITION_TABLE_DATA_LEN);

But app image is checked

esp-idf/components/bootloader_support/src/esp_image_format.c

Lines 103 to 104 in 98e5c47

	#ifdef CONFIG_SECURE_BOOT_ENABLED
	if (1) {

esp-idf/components/bootloader_support/src/esp_image_format.c

Lines 169 to 171 in 98e5c47

	#ifdef CONFIG_SECURE_BOOT_ENABLED
	// secure boot images have a signature appended
	err = verify_secure_boot_signature(sha_handle, data);

@projectgus

[projectgus]

Hi @catalinio ,

Sorry for the delay in getting back to you. I believe @negativekelvin is right here. The app signature is checked on the first boot before secure boot is enabled, but the partition table signature is not checked until the second boot after secure boot is enabled (only basic partition table integrity is checked on the first boot). If someone accidentally flashes an unsigned but otherwise valid partition table and enables flash encryption, they can be left with an unbootable ESP32.

As it happens, we've recently discussed removing the partition table signature check entirely to speed up boot times when secure boot is on. Any hypothetical attacker who can rewrite the partition table is able to make arbitrary flash writes, so they can always rewrite existing partition contents instead.[*]. So we will probably solve this by removing the partition table signature check entirely (improving the boot time when secure boot is enabled).

[*] Previously there may have been a hypothetical weakness if an attacker could write to but not erase arbitrary flash. They could hypothetically extend an unsigned partition table rather than rewriting it. However the new MD5 appended to the partition table fixes this as it's impossible to repurpose that entry without erasing first.

[negativekelvin]

@projectgus while you are in there, what about write protect flash_crypt_cnt automatically when secure boot and non-reflashable bootloader selected?

[projectgus]

@negativekelvin That seems reasonable. FWIW I don't think there's a situation where this can lead to permanent problems, though (even if it's accidentally burned again to disable encryption, you can always burn it one more time to get encryption back on.)

[negativekelvin]

Unless it is burned to 0xff. Probably not a big concern but someone could permanently disable a device that way.

[projectgus]

Fair enough, will change this. Although please note that if a hypothetical malicious attacker is in a position to burn arbitrary efuses, they have lot of ways to permanently disable the device (via efuses and via other means.)

[negativekelvin]

That is true, other efuses would need to have write protect set but that could be done before first boot. Yes someone could still corrupt the flash chip, but at least we can take all reasonable measures.

What is EFUSE_ABS_DONE_1 for and what do bits 4&11 of efuse_wr_disable do?

[negativekelvin]

@projectgus these changes didn't make it into bootloader refactor?

[projectgus]

@negativekelvin No, those were separate changes. But we haven't forgotten about this.