Google Project Zero team is good at discovering security vulnerabilities in different products (including windows operating system, iPhone smartphone, Qualcomm Adreno GPU and GitHub code hosting platform), and then timely reporting to suppliers and giving them a standard 90 day grace period for patch repair Recently, however, Project Zero researchers also disclosed a high-risk USB vulnerability in their Chrome OS system
Jann horn at report The problem stems from the USB device coping strategy of Chrome OS when the device is locked.
Although the system will configure the black / white list (allow / block list) for USB devices through usbguard, the wrong configuration framework may cause unauthenticated USB devices to access the computer's kernel and storage.
Specifically, the usbguard block list will not use specific class interface descriptors on the lock screen to authenticate USB devices.
However, if an attacker modifies the kernel and disguises the related devices as mass storage devices, he can break the limit after authentication.
The reason is that the kernel feels that the USB class is somewhat irrelevant and allows modifications from seemingly authenticated devices.
In addition to the large attack surface in the device drivers that do not belong to these USB interface classes, the system kernel usually does not care which USB type the device claims to belong to.
As a widely used standardized protocol, the driver can specify the appropriate USB interface class it wants to use with low priority (bound to a standard compliant device), and can also reference the manufacturer / product ID with high priority (regardless of its USB interface class).
If you use a Linux machine with appropriate hardware - the net2380 development board is selected in this example, but you can also use the unlocked pixel smart machine / raspberry pie zero W and other similar devices - to simulate a USB mass storage device.
Then use (this ) And patch a line in the attacker's kernel, so that it can claim whatever it wants (instead of being treated as a storage device).
Project Zero marked the problem as a high severity vulnerability and sent a private letter to the Chrome OS team on February 24.
Embarrassingly, the Chrome OS team later regarded the problem as a low severity vulnerability and argued on March 1 that it would solve the problem through appropriate matching based on drivers (rather than class interface descriptors).
Although the Chrome OS team reported the progress update on May 11, because it failed to fix the vulnerability within the specified 90 days, the project zero security researchers finally decided to make it public on May 24.
At present, it is not clear when the official Chrome OS patch will be launched. Fortunately, as a local vulnerability, an attacker needs to manually connect USB to tamper with the device and its kernel, which cannot be remotely exploited.
In other words, only if you leave the Chrome OS PC unattended, even if it is locked, can it become a springboard for other attacks.