Supermicro BMC firmware update validation bypass

Image preview

The firmware image for the X12STW-F motherboard version 01.07.09 has the following regions defined in the fwmap:

1. offset: 0x0000000, size: 0x00a6280, signed: true - bootloader
2. offset: 0x0100000, size: 0x0001000, signed: true - sig_table
3. offset: 0x0110000, size: 0x0010000, signed: true - pdb_seca
4. offset: 0x0130000, size: 0x031f880, signed: true - kernel
5. offset: 0x0530000, size: 0x272c080, signed: true - rootFS
6. offset: 0x2dc0000, size: 0x0010000, signed: false - pdb_isec
7. offset: 0x2dd0000, size: 0x0000000, signed: false - nvram1
8. offset: 0x2e80000, size: 0x0000000, signed: false - uboot_env
9. offset: 0x2ec0000, size: 0x0000000, signed: false - nvram

The fix for CVE-2025-7937 introduced two additional checks in the fwmap_parser function. The first of these validates that the offset of the pdb_seca region ("PDBA offset"), which contains the fwmap table used during the validation process, is equal to the hardcoded value 0x110000. The second checks that the fwmap table contains a region whose offset is equal to or greater than the "PDBA offset", and whose (offset + size) is greater than the "PDBA offset". However, since the offset and size of the pdb_seca region used during the validation process is not checked against that defined in the fwmap table, a potential attacker can replace the pdb_seca region provided by the vendor with a custom one and place the original data somewhere in the unreserved firmware space to bypass the validation process.

In our example attack, we attempt to update the BMC firmware using an image containing a customised bootloader. First, we move the content of the original pdb_seca region to unreserved space between the end of the pdb_seca region (0x120000) and start of the kernel region (0x130000) – 0x10000 bytes available, and then we move the content of the original bootloader region to unreserved space between the end of the rootFS region (0x2c5c080) and start of the pdb_isec region0x2dc0000 (0x163f80 bytes available). To align with the additionally introduced checks described above, the offset of the nvram region can be set to 0x110000 and its size to 0x1 (as it is not signed, this will not affect the validation). Finally, the modified pdb_seca region can be placed at offset 0x110000 with the custom fwmap table content as follows:

1. offset: 0x2c5c080, size: 0x00a6280, signed: true - bootloader
2. offset: 0x0100000, size: 0x0001000, signed: true - sig_table
3. offset: 0x0120000, size: 0x0010000, signed: true - pdb_seca
4. offset: 0x0130000, size: 0x031f880, signed: true - kernel
5. offset: 0x0530000, size: 0x272c080, signed: true - rootFS
6. offset: 0x2dc0000, size: 0x0010000, signed: false - pdb_isec
7. offset: 0x2dd0000, size: 0x0000000, signed: false - nvram1
8. offset: 0x2e80000, size: 0x0000000, signed: false - uboot_env
9. offset: 0x0110000, size: 0x0000001, signed: false - nvram

There is another validation step that is implemented in the find_respective_image_info function. It additionally checks that the firmware structure specified in the uboot_env region is aligned with the fwmap table data before writing the contents of the uploaded firmware image to the SPI flash. More specifically, for each entry defined in the uboot_env region, it is checked that its offset and size is matched against the corresponding values specified in the fwmap table (which is part of the pdb_seca region, located at offset 0x110000). Also, CRC values provided for each entry in the uboot_env region is checked against the calculated ones.
This check can be bypassed by removing all entries from the uboot_env region except the first one (u-boot.bin), renaming remaining entry to out_webfs_img.bin and update the CRC value to the correct one (the CRC of the custom bootloader content). This works because the out_webfs_img.bin region is defined in the partition_name_translate function, however, it is not part of the fwmap table, so it won't be validated in the check_fwmap_info_cb function.

Now, the content of the bootloader region can be modified in an arbitrary way. At the same time, validation of such an image will still succeed.

Image preview

This bug is subject to a 90 day disclosure deadline. After 90 days elapsed or a patch has been made broadly available (whichever is earlier), the bug report will become visible to the public.

Image preview

BINARLY team

Image preview