Headline
Das U-Boot Buffer Overread
Das U-Boot suffers from a buffer overread vulnerability. An attacker with access to the local network and faster response times than the default DHCP server can trigger a memory leak by responding with malicious DHCP offers to a vulnerable U-Boot DHCP client.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Title
SCHUTZWERK-SA-2024-004: Buffer overread in U-Boot DHCP
Status
PUBLISHED
Version
1.0
CVE reference
CVE-2024-42040
Link
https://www.schutzwerk.com/advisories/schutzwerk-sa-2024-004/
Text-only version:
https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2024-004.txt
Affected products/vendor
Das U-Boot, https://docs.u-boot.org
Summary
Das U-Boot (U-Boot) is a widespread open-source boot loader used in
embedded devices to perform various low-level hardware initialization
tasks and boot the device’s operating system kernel. During an embedded
security assessment, we identified a buffer overread vulnerability
(CWE-126) in the DHCP implementation of U-Boot that could leak memory
onto the network. The amount of leaked data depends on the later use of
the hostname, DNS-server IP, gateway IP, or other DHCP options in
unencrypted network traffic. The vulnerability has been present since
the “Initial revision” commit (3861aa5) from 2002.
Risk
An attacker with access to the local network and faster response times
than the default DHCP server can trigger a memory leak by responding
with malicious DHCP offers to a vulnerable U-Boot DHCP client. In the
current implementation, only 4 Bytes of data can be leaked via gateway
or DNS server address. When net_hostname would be used and also sent
over the network, 32 Bytes could be retrieved. When the bp_vend field is
filled with zeroes besides the magic number, it could also lead the loop
to continue outside the packet to process data. This can cause further
data to be leaked when values like 0x1,0x3,0x6, and 0x12 are present in
that data. When further vulnerabilities can be found they might be
combined to achieve further harmful impact to the system.
Description
After U-Boot sends an initial DHCP request, the vulnerable bootp_handler
gets registered as a callback for incoming packets. The handler first
checks if the received packet is the expected reply packet. If
VENDOR_MAGIC is in the first four bytes of bp->bp_vend, the address of
bp->bp_vend[4] and the total length of the packet is passed to
bootp_process_vendor (net/bootp.c:381) without being reduced to
len-(offsetof(struct bootp_hdr,bp_vend)+4). There is also a missing
check whether the first four bytes of bp->pb_vend[] are in range of the
packet length before retrieving them to compare with htonl(VENDOR_MAGIC).
In bootp_process_vendor, an incorrect end address is then calculated
based on the full packet length (net/bootp.c:312) instead of the rest of
the bp_vend buffer size. Then, the function increases the ext pointer
until it no longer points to zero bytes within the too-long buffer range
or when one byte is 0xff. When a none-zero value is discovered the ext
pointer is passed to bootp_process_vendor_field.
In bootp_process_vendor_field, the de-referenced value of the passed
pointer is used to select the case for processing the field, and its
length is de-referenced from ext+1. Based on the selected case, values
are then copied to variables and buffers like net_gateway.s_addr or
net_hostname from ext+2. The copied lengths are only limited by the size
of their destination. The end of the bp_vend structure or the end of the
packet is never checked in bootp_process_vendor_field.
This allows an attacker, who can respond to DHCP requests, to craft a
packet that causes the code to copy the contents of the target’s RAM
directly following the received packet into parameters. These parameters
are sent via the network during later use, leaking the RAM content to
the attacker.
Solution/Mitigation
We recommend providing an adequate length to bootp_process_vendor to
prevent the while loop from stepping outside the packet frame and
checking in bootp_process_vendor_field if the copied data is still
within the packet structure’s range.
Disclosure timeline
2024-06-21: Vulnerability discovered
2024-08-19: Vulnerability reported to public mailing list by request of
maintainer.
Contact/Credits
The vulnerability was discovered during an assessment by Simon Diepold
of SCHUTZWERK GmbH.
References
Disclaimer
The information provided in this security advisory is provided “as is” and
without warranty of any kind. Details of this security advisory may be
updated
in order to provide as accurate information as possible. The most recent
version of this security advisory can be found at SCHUTZWERK GmbH’s website
( https://www.schutzwerk.com ).
SCHUTZWERK Advisories: https://www.schutzwerk.com/blog/tags/advisories/
SCHUTZWERK Advisory Policy: https://www.schutzwerk.com/en/advisories/
-----BEGIN PGP SIGNATURE-----
iQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmbC+YgaHGFkdmlzb3Jp
ZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLrtSeRAAi6OrwHBpbFgKlyqROQnw
zYxmHTYBiWzBEEmI1zN+iNb5uQlnZXgBoodbEneiRmVQDSiT4zT/DWe3EGV2TlRR
56hEIGvkvleURqCjwRYeYnPF3Ef/XMTvTu/x08h8UfGr7XNwhwCpANxUTE7aI01b
jZLa4jDv8vpNd7JKNF32S2Ak6GRjfEE9aEAxUKliNXCA5SU1gYvOWQ+BJ0oth7fN
grkTKffltk8dUBFy8TsrxcAG5ye4f1Dvm51dU8JNPBLkmouOrEvX1K4UTjvAyD8e
bCn2dXs2rDLfywrTPV0k2zj3APZiwhYxNA3MaTUGscZAIUMn3WE/cUyYDpQDqOYx
wrZzz9K59m+x8F6c1lBUxlmU3t9Z15/i/tL6Kropb+HDxjWaLCZPG3dzdlR54/fn
gvzS393FNWakNNAJIqN2jvvol+zvJGn2rsSsfp5CPEdrQEHgvQa0TkBOpdtFZ/h1
muVFwj9yDup07yStTXRJHjg2WCH0LdL5x+mDfcBspjLflpVP/0Yj+MnR8e3Eb7v/
Cb12PeBHww9VObUhgbMecanSn6Epf7Nc5a5wIh5kEWKoviBYNY/0cu7GDN+70PK4
JhD86Tww5RFJJfkLcJqlCAMC4AkAc7Sq5FS7WTK5Jx3Ymh/+Lsuhx9ENq38VyVGh
tFe3V0joTUxg7Yy78PoEOrs=
=XKZo
-----END PGP SIGNATURE-----
–
SCHUTZWERK GmbH, Pfarrer-Weiß-Weg 12, 89077 Ulm, Germany
Zertifiziert / Certified ISO 27001, 9001 and TISAX
Phone +49 731 977 191 0
[email protected] / www.schutzwerk.com
Geschäftsführer / Managing Directors:
Jakob Pietzka, Michael Schäfer
Amtsgericht Ulm / HRB 727391
Datenschutz / Data Protection www.schutzwerk.com/datenschutz