HTTP Boot Vulnerabilities in GRUB2
Or, "What in God's name is an HTTP client doing in my bootloader?"
I’m a subscriber to the oss-security mailing list. Occasionally, a particularly interesting post will catch my eye.
In this case it was a portion of a larger disclosure of several CVEs in GRUB2. Apparently GRUB contains an HTTP client, albeit one with less-than-perfect bounds checking on its request data buffer:
CVE-2022-28734 grub2: Out-of-bounds write when handling split HTTP headers 7/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H
When handling split HTTP headers, GRUB2 HTTP code accidentally moves its internal data buffer point by one position. This can lead to a out-of-bound write further when parsing the HTTP request, writing a NULL byte past the buffer. It’s conceivable that an attacker controlled set of packets can lead to corruption of the GRUB2’s internal memory metadata.
Reported-by: Daniel Axtens
What surprised me most was that GRUB contains an HTTP client at all. Yet according to the GRUB documentation, HTTP support is indeed built-in:
If you enabled the network support, the special drives (protocol[,server]) are also available. Supported protocols are ‘http’ and ‘tftp’.
I did some cursory research into the history of HTTP boot in UEFI, mostly out of sheer awe. HTTP boot is apparently part of UEFI itself. Firmware Security has some excellent writeups circa 2015, with the introduction of the feature in UEFI 2.5.
To me, this whole ordeal brings to mind Zawinski’s Law:
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
Perhaps an appropriate modern take on this would be, “Every program attempts to expand until it can speak HTTP”.
Simplicity, in a bootloader? Who needs it.
Bonus Round
Here’s a look at the byzantine machinations of UEFI v2.5’s network stack:
(source: Dong Wei, LinuxCon Europe 2015)
Bluetooth, you say? But of course! You read that correctly.
(source: Tony C.S. Lo, UEFI Plugfest - October 2014)