Project Zero is team at Google that is responsible for discovering security flaws in different products and then privately reporting them to the respective vendor. A 90-day deadline is provided in order to patch an issue before it is publicly exposed. In some cases, a 14-day grace period may be offered as well.
Google Project Zero has previously reported major issues in Google's own products as well as those belonging to others, such as Windows, iPhone, Qualcomm Adreno GPUs, GitHub, and more. Now, it has publicly disclosed a bug in Chrome OS following the associated team's failure to fix it within the allotted 90 days.
The issue in question deals with how Chrome OS handles USB devices when the device is locked. Essentially, Chrome OS uses USBGuard to configure allowlists and blocklists for USB devices. However, incorrect configurations of this framework can lead to unauthenticated USB devices to be able to access the PC's kernel and storage.
As Google Project Zero security researcher Jann Horn describes, USBGuard in Chrome OS has a blocklist that does not authenticate USB devices with specific class interface descriptors on a locked screen. However, after this validation, all other interfaces are allowed.
What this means is that while an unauthenticated USB device will be blocked correctly on the lock screen, other devices can emulate a mass storage device, modify the attacker kernel to not show up as a USB device, and be authenticated. This is because the USB class does not matter to a kernel so it will allow modification from a seemingly authenticated device too. Horn notes that:
Apart from the problem that there is a large amount of attack surface in drivers for devices that don't belong into those USB interface classes, there is another issue with this approach: The kernel often doesn't care what USB class a device claims to be. The way USB drivers tend to work, even for standardized protocols, is that the driver specifies with low priority that it would like to bind to standards-compliant devices using the proper USB interface class, but also specifies with high priority that it would like to bind to specific USB devices based on Vendor ID and Product ID, without caring about their USB interface class.
[...] If we use a Linux machine with appropriate hardware (I'm using a NET2380 dev board, but you could probably also do it with an unlocked Pixel phone or a Raspberry Pi Zero W or something like that) to emulate a USB Mass Storage device, using (this), and patch one line in the attacker kernel so that it claims to be a billboard, not a storage device.
This issue was flagged as a high severity vulnerability and privately reported to the Chrome OS team on February 24. However, after triaging the flaw, that team assigned it as a low severity vulnerability and stated on March 1 that it would fix the problem by matching based on drivers rather than class interface descriptors. On May 11, the Chrome OS team provided a progress update but since it was unable to fix the flaw in the allotted 90 days, the issue was publicly exposed on May 24.
It is unclear when a patch will be rolled out, but it is important to note that this is a local vulnerability that requires an attacker to manually insert a USB to tamper with the device and its kernel. It can't be exploited remotely but it does act as an attack vector for other exploits if you leave your Chrome OS PC unattended somewhere, even if it's locked.
_(1)_small.jpg)
