Pwning the boot process: Uboot CVE-2019-13103 to CVE-2019-13106

TL;DR

Background

Due to the nature of finding these bugs, which was some time ago, I only have the notes of finding these bugs with Paul Emge while we were interns at @ForAllSecure.

Fuzzing

All of the CVEs below were obtained using the Mayhem Fuzzer from ForAllSecure along with some easy harnessing. For the most part, you can run Uboot in it’s sandbox mode and submit Filesystems for it to be parsed. Using Mayhem, you can use a normal ext4 file system as the seed and let it mutate from there.

CVE-2019-13103:

There is a stack overflow when reading a DOS partition table which refers to itself. This causes part_get_info_extended to call itself repeatedly with the same arguments, causing unbounded stack growth. In the sandbox configuration, this results in a segfault. On QEMU’s vexpress-a15 board, the CPU returns to 0 but continues executing NOPs until it hits data and executes it.

CVE-2019-13104:

At ext4fs.c:74 it is possible for len to underflow while listing files in a crafted filesystem. If this happens, eventually there is a memcpy with a negative (so effectively infinite) length. This causes all of memory to be overwritten until, on the sandbox, it segfaults. On a real platform, I’m not sure what would happen, but there’s definitely memory corruption. This affects versions 2016.11-rc1 through 2019.07-rc4.

CVE-2019-13105:

If there is an invalid/out-of bounds block number, ext_cache_read doesn’t set the freed cache->buf to 0, which results in a double free in ext_cache_ini.

CVE-2019-13106:

The ext4 code can overwrite portions of the stack with 0s in the ext4fs_read_file function, while listing files in an untrusted filesystem. The bug occurs when a filename (or potentially some other structure) is located across a block boundary. The number of 0s written to the stack is controllable by changing the position of the filename. The bug could easily give complete control of the CPU, which would defeat verified boot. This affects versions 2016.09 through 2019.07-rc4.

Media Coverage

Semmle Blog, and Threat Post.

Thanks

As stated earlier, this bug would have been impossible without Paul Emge and the amazing team at ForAllSecure who developed the Mayhem system.