Hello dear U-Boot maintainers and developers, I hope you are all doing well.
During one of our assessments we found a low impact buffer overread vulnerability in the DHCP implementation of U-Boot.
According to the policy of the project [0] the attached vulnerability advisory is hereby disclosed to the public mailing list and the according maintainers.
We will publish the advisory in the next few hours on our website as well. (see links in the advisory)
If you have any questions feel free to contact me. Best Regards Simon Diepold [0]: https://docs.u-boot.org/en/latest/develop/security.html -- Simon Diepold Security Consultant OSCP SCHUTZWERK GmbH, Pfarrer-Weiß-Weg 12, 89077 Ulm, Germany Zertifiziert / Certified ISO 27001, 9001 and TISAX Phone +49 731 977 191 0 Mobile +49 151 431 446 67 sdiep...@schutzwerk.com / www.schutzwerk.com Geschäftsführer / Managing Directors: Jakob Pietzka, Michael Schäfer Amtsgericht Ulm / HRB 727391 Datenschutz / Data Protection www.schutzwerk.com/datenschutz
-----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-----
OpenPGP_0x4150F146B88CA524.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
