90-day deadline has passed, Google research team publicly exposed Chrome OS notebook high-risk USB vulnerability

IT House May 27 news, according to Neowin reports, Project Zero is Google’s team, responsible for finding security vulnerabilities in different products, and then privately report them to the appropriate suppliers. And provided a 90-day deadline to patch the issue before it became public. In some cases, a 14-day grace period may also be provided.

Google Project Zero has previously reported significant issues with Google’s own products as well as other products such as Windows, iPhone, Qualcomm Adreno GPUs, GitHub, and more. Now, the team has publicly disclosed a bug in Chrome OS after the team failed to fix it within the allotted 90 days.

The question concerns how Chrome OS handles USB devices when the device is locked. Essentially, Chrome OS uses USBGuard to configure allow and block lists for USB devices. but,Misconfiguration of this framework can result in unauthenticated USB devices being able to access the PC’s core and storage.

As described by Google Project Zero security researcher Jann Horn, USBGuard in Chrome OS has a block list that does not use specific class interface descriptors to authenticate USB devices on the locked screen. However, after this verification, all other interfaces will be allowed.

This means that while an unauthenticated USB device will be properly blocked on the lock screen, other devices can emulate a mass storage device, modify the attacker’s kernel to not appear as a USB device, and authenticate. This is because the USB class is irrelevant to the kernel, so it also allows modifications from seemingly authenticated devices. Jann Horn points out:

“In addition to the problem of having a large attack surface in drivers for devices that do not belong to these USB interface classes, there is another problem with this approach: the kernel generally doesn’t care which USB class a device claims to belong to. The way USB drivers tend to work , even for standardized protocols, the driver specifies with low priority that it wants to bind to a standards-compliant device using the appropriate USB interface class, but also specifies with high priority that it wants to bind to a specific USB based on Vendor ID and Product ID devices, regardless of their USB interface class.

[…] If we use a Linux device with proper hardware (I’m using a NET2380 board, but you can also use an unlocked Pixel phone or a Raspberry Pi Zero W or something similar) to emulate a USB mass storage device, use (this), And patch a line in the attacker kernel to make it claim to be a billboard, not a storage device. “

This issue was marked as a High Severity Vulnerability and was reported privately to the Chrome OS team on February 24th. However, after classifying the vulnerability, the team designated it as a low-severity vulnerability and said on March 1 that the issue would be resolved by matching based on the driver rather than the class interface descriptor. On May 11, the Chrome OS team provided a progress update, but the issue was publicly exposed on May 24 after the vulnerability could not be fixed within the allotted 90 days.

It’s unclear when the patch will roll out, but it’s 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, and cannot be exploited remotely.