Google’s Project Zero team is good at finding security vulnerabilities in different products (covering Windows operating systems, iPhone smartphones, Qualcomm Adreno GPUs, GitHub code hosting platform), and then reporting to suppliers in a timely manner, giving them a standard 90-day patch repair latitude. deadline. However, recently, Project Zero researchers also disclosed a high-risk USB vulnerability in their Chrome OS system.
Jann Horn wrote in the report that the problem stems from Chrome OS’s strategy for handling USB devices when the device is locked. Although the system configures a black/white list (allow/block list) for USB devices through USBGuard, an incorrect configuration framework could allow unauthenticated USB devices to access the computer’s kernel and storage.
Specifically, the USBGuard blocklist does not use a specific class interface descriptor on the lock screen to authenticate USB devices. However, if an attacker modifies the kernel to disguise the relevant device as a mass storage device, he or she can break through the limit after authentication. The reason is that the kernel feels that the USB class is somewhat irrelevant and allows modifications from what appears to be an authenticated device.
Aside from the large attack surface in device drivers that do not belong to these USB interface classes, the system kernel usually doesn’t care which USB type a device claims to be. As a widely used standardized protocol, drivers can either specify the appropriate USB interface class they wish to use (bound to a standards-compliant device) with low priority or refer to the manufacturer/product ID with high priority. Bonded (regardless of its USB interface class).
If you use a Linux machine with the proper hardware – the NET2380 development board was chosen in this example, but you can also use an unlocked Pixel smartphone / Raspberry Pi Zero W or similar – to emulate a USB mass storage device. Then use ( this ) and patch a line in the attacker’s kernel and do whatever it claims to be (without being considered a storage device).
Project Zero flagged the issue as a high-severity vulnerability and sent a private message to the Chrome OS team on February 24. Embarrassingly, the Chrome OS team later dismissed the issue as a low-severity vulnerability, arguing on March 1 that it would be resolved with proper driver-based matching (rather than class interface descriptors).
Although the Chrome OS team notified the progress update on May 11, after failing to fix the vulnerability within the allotted 90 days, Project Zero security researchers finally decided to publicly expose it on May 24.
It’s unclear when the official Chrome OS patch will be rolled out, but thankfully, as a local vulnerability, attackers need to manually connect a USB to tamper with the device and its kernel, and cannot be exploited remotely. In other words, if you leave your Chrome OS PC unattended, even if it’s locked, it could become a springboard for other attacks.