| 1 | + | # CVE-2021-3625 |
| 2 | + | |
| 3 | + | This repository contains a few example exploits for CVE-2021-3625. |
| 4 | + | |
| 5 | + | All Zephyr-based usb devices up to (and including) version 2.5.0 suffer from |
| 6 | + | a buffer overflow allowing readout of up to 65kB. Depending on the actual device |
| 7 | + | this may result of leakage of sensitive data like encryption keys or credentials. |
| 8 | + | |
| 9 | + | The issue may be triggered by issuing crafted usb control transfer requests |
| 10 | + | with IN direction (reads, to host) and a write specific request - in example |
| 11 | + | set address (0x05). In such cases write to host is not expected thus response |
| 12 | + | length is not updated resulting in a initially set value of request->wLength. |
| 13 | + | Since wLength is user controlled it can be set to an arbitrary two byte value like |
| 14 | + | 0xffff resulting in readout of 65 kilobytes microcontroller memory. Since size of |
| 15 | + | buffer is significantly smaller a overflow takes place allowing an attacker |
| 16 | + | to extract memory contents past the buffer boundary. |
| 17 | + | |
| 18 | + | Besides application layer also MCUBoot builds with Zephyr USB device stack enabled |
| 19 | + | are affected. Furthermore along memory readout past buffer bounaries the DFU class |
| 20 | + | may also be exloited to achive buffer overflow write. |
| 21 | + | |
| 22 | + | For best results it is recommended to use a libusb build with MAX_CTRL_BUFFER_LENGTH |
| 23 | + | size increased from default 4096 bytes to 0xFFFF (libusb/os/linux_usbfs.h). |
| 24 | + | |
| 25 | + | Security Advisory: https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-c3gr-hgvr-f363 |
| 26 | + | |