Trent NovellyI'm a very infrequent poster on any social media platform, so the chances of this getting any kind of attention are slim... But it's worth a try.
I've been investigating #CVE-2024-50302, one of the vulnerabilities purportedly used in the Cellebrite 0-day chain. (This CVE received a bit of attention due to it's reported use in the wild while being a "low scoring" CVE based on CVSS.)
The fix was simple. Just change a heap allocation call in hid_alloc_report_buf to a zero-initialized version. Cool.
However, identifying the trigger for the info leak as elluded me. I'll try to set a bit of high level background context for searching for the bug.
The quirks or kernel behaviors triggered by emulating an "Anton device" apparently allow uninitialized bytes allocated by the vulnerable function to be sent from the host to the device via crafted HID reports (there's actually another VID/PID that should enable the same behavior since the exact same quirk class is specified.)
An "Anton device" is a special kind of multitouch device, handled by the hid-multitouch driver. I'm assuming the usbhid transport driver is used since USB devices were emulated, and not some other kind (I2C, or bluetooth for instance)
HID reports include 'INPUT', 'OUTPUT', and 'FEATURE' requests. INPUT reports are sent from the device to the host. OUTPUT reports are sent from the host to the device. And FEATURE reports can go either direction depending on what they are used for.
Considering there wasn't any fix related to INPUT reports being incorrectly sent from host to device, I've focused on execution paths related to OUTPUT reports and FEATURE reports that are sent to the device via SET_REPORT (I did look into GET_REPORT paths too, but that request type is for requesting and then receiving report data, rather than sending a report)
This is where I've hit my biggest roadblock. It seems that every execution flow for the hid-multitouch device driver that allocates a buffer with the vulnerable function ,hid_alloc_report_buf, to be used in a SET_REPORT request or passed to an OUTPUT endpoint, ends up passing the bytes allocated to the hid_output_report, which memsets the bytes to be used for the report to zero. I can't find a discrepancy in the calculation of the number of bytes to memset, and the number of bytes to send. (And if there was, that would be it's own vulnerability...)
There are a few paths through a GET_REPORT request where hid_alloc_report_buf allocates a buffer that is attached to the USB request structure, however that buffer shouldn't be transferred to the device. That path is also not unique to the behaviors enabled by an Anton device.
So I'm either missin the control/dataflow path that results in the uninitialized buffers getting transferred via the "send" pipes as a part of otherwise expected behavior, or there's something else going on. And if there's something else going it's hard to imagine it's not some separate bug or abusing other vulnerabilities to manipulate the kernel structures to artificially "build" an info leak path.
That's all for now... but that is likely to be my platform activity for the year...
ity [unit X-69] - VIOLENT FUCK