Multiple vulnerabilities have been found in Das U-Boot, a universal bootloader commonly used in embedded devices like Amazon Kindles, ARM Chromebooks and networking hardware. The bugs could allow attackers to gain full control of an impacted device’s CPU and modify anything they choose.
Researchers at ForAllSecure found the flaws in U-Boot’s file system drivers. They include a recursive stack overflow in the DOS partition parser, a pair of buffer-overflows in ext4 and a double-free memory corruption flaw in ext4. They open the door to denial-of-service attacks, device takeover and code-execution.
There are both local and remote paths to exploitation for these flaws. If a vulnerable device is configured to boot from external media, such as an SD card or USB drive, attackers with physical access could subvert the normal boot process of the device and control the loading of the operating system, giving them substantial control over the device.
If the device is configured to network boot, remote attackers could use an initial method to compromise the corporate or Wi-Fi network that a target device is attached to (including social-engineering malware onto a victim’s endpoint or exploiting known vulnerabilities), and from there attacking the U-Boot device from that local network location.
“The most obvious route for exploitation requires physical access, and could either cause denial of service (possible device bricking) or could subvert the boot process for a device or possibly bypass trusted boot,” Maxwell Koo, ForAllSecure analysis engineer, told Threatpost in an interview. “If device is configured to allow pxe boot and is configured with CONFIG_CMD_FS_GENERIC, there is a possible network avenue of exploitation via CVE-2019-13104 through -13106, with the same impact.”
He added, “I’d say it would take moderate-to-high expertise to develop an initial exploit for a given device.”
Technical Details
CVE-2019-13103 is a stack overflow that affects all versions of U-Boot in the archives, which occurs when reading a DOS partition table, which refers to itself. This causes the “part_get_info_extended” function to call itself repeatedly with the same arguments, causing unbounded stack growth.
“On QEMU’s vexpress-a15 board, the CPU returns to 0 but continues executing NOPs until it hits data and executes it,” according to the GitHub write-up from the ForAllSecure interns who discovered the flaws, Paul Emge and Zion Basque.
In a technical analysis shared with Threatpost, the researchers explained that in testing, an emulated ARM CPU “is happy to execute a bunch of NOPs from this memory location, until, after many megabytes, it reaches some data and returns to 0 again.” This would lead to DoS, but depending on the exact system and software installed, something worse could happen.
“For example, other data in this part of the address space could get executed and lead to other anomalous behaviors, including the ability to run attacker provided code,” they wrote.
As for the buffer-overflow flaws, CVE-2019-13104 affects U-Boot versions 2016.11-rc1 through 2019.07-rc4. 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,” the research pair wrote. “This causes all of memory to be overwritten until [in sandbox testing], it segfaults…There’s definitely memory corruption.”
The second, more serious buffer-overflow issue is CVE-2019-13106, affecting U-Boot versions 2016.09 through 2019.07-rc4.. The ext4 code can overwrite portions of the stack with 0s in the ext4fs_read_file function, while listing files in an untrusted filesystem. Researchers said that the bug could “easily give complete control of the CPU,” which would defeat verified boot.
“The bug occurs when a filename (or potentially some other structure) is located across a block boundary,” explained the researchers in the GitHub post. “The number of 0s written to the stack is controllable by changing the position of the filename.”
And in CVE-2019-13105, which affects U-Boot versions 2019.07-rc1 through 2019.07-rc4, 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 issue in ext_cache_ini. A double-free vulnerability occurs when, as the name says, a variable is free()’d twice. The variable is still usable, but the memory pointed to that variable can be free.
ForAllSecure also found five low-severity divide-by-zero bugs, triggered by invalid extended file systems.
U-Boot patched the bugs as of its v. 2019.10 release – but devices are likely still vulnerable given that the update process is controlled by the vendor of the device rather than U-Boot itself.
“As a bootloader, which is often used in embedded devices with a long/non-existent update cycle, the unpatched code is likely present and will remain present on many devices for some time,” Koo told Threatpost. “Severity depends somewhat on configuration of the device in question (U-Boot is pretty configurable and this will differ a lot between devices).”
Amazon did not immediately respond to a request for comment.
If support for DOS partitions or ext4 filesystem images is not present in the U-Boot configuration of a device, then the bugs have impact.
What are the top risks to modern enterprises in the peak era of data breaches? Find out: Join breach expert Chip Witt from SpyCloud and Threatpost senior editor Tara Seals, in our upcoming free Threatpost webinar, “Trends in Fortune 1000 Breach Exposure.” Click here to register.