-----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