Google Project Zero ha precedentemente segnalato problemi importanti nei prodotti di Google e in prodotti di altre aziende come Windows, iPhone, GPU Qualcomm Adreno, GitHub e altri. Ora, ha segnalato pubblicamente un bug in Chrome OS dopo che il team competente non è riuscito a risolverlo entro i 90 giorni assegnati.
La domanda in questione riguarda il modo in cui Chrome OS gestisce i dispositivi USB quando il dispositivo è bloccato. In sostanza, Chrome OS utilizza USBGuard per configurare gli elenchi consentiti e bloccati per i dispositivi USB. Tuttavia, impostazioni errate di questa piattaforma potrebbero impedire ai dispositivi USB non autenticati di accedere al kernel e all’archiviazione del PC.
Come descrive il ricercatore di sicurezza di Google Project Zero Jann Horn , USBGuard in Chrome OS ha una lista nera che non autentica i dispositivi USB con determinati descrittori di interfaccia di classe nella schermata di blocco. Tuttavia, dopo questo controllo, tutte le altre interfacce sono consentite.
Ciò significa che mentre un dispositivo USB non autenticato verrà bloccato correttamente nella schermata di blocco, altri dispositivi possono emulare un dispositivo di archiviazione di massa, modificare il kernel dell’attaccante in modo che non venga visualizzato come dispositivo USB ed essere autenticati. Questo perché la classe USB è irrilevante per il kernel, quindi consente anche la modifica da un dispositivo apparentemente autenticato. Horn osserva che:
Oltre al problema che i driver per dispositivi che non appartengono a queste classi di interfaccia USB hanno un gran numero di superfici di attacco, c’è un altro problema con questo approccio: al kernel spesso non importa quale classe USB afferma di essere il dispositivo. essere. I driver USB generalmente funzionano anche per protocolli standardizzati: il driver indica a bassa priorità che desidera eseguire il binding a dispositivi conformi agli standard utilizzando la classe di interfaccia USB appropriata, ma indica anche ad alta priorità che desidera eseguire il binding a dispositivi USB specifici basati su Vendor ID e Product ID senza preoccuparsi della loro classe di interfaccia USB.
[…] Se utilizziamo una macchina Linux con l’hardware appropriato (sto usando una scheda di sviluppo NET2380, ma probabilmente puoi farlo anche con un telefono Pixel sbloccato o un Raspberry Pi Zero W o qualcosa di simile) per emulare una massa USB Dispositivo di archiviazione che utilizza (this) e correggere una riga nel kernel dell’attaccante in modo che rappresenti un cartellone pubblicitario e non un dispositivo di archiviazione.
Questo problema è stato segnalato come una vulnerabilità di gravità elevata ed è stato segnalato privatamente al team di Chrome OS il 24 febbraio. basato sui driver, non sui descrittori dell’interfaccia di classe. L’11 maggio, il team di Chrome OS ha fornito aggiornamenti sui progressi, ma poiché non è stato in grado di correggere il bug nei 90 giorni assegnati, il problema è stato divulgato pubblicamente il 24 maggio.
Non è chiaro quando verrà rilasciata una correzione, ma è importante notare che si tratta di una vulnerabilità locale che richiede a un utente malintenzionato di inserire manualmente un’unità USB per compromettere il dispositivo e il suo kernel. Non può essere utilizzato in remoto, ma funge da vettore di attacco per altri exploit se lasci il tuo computer Chrome OS incustodito, anche se è bloccato.
Lascia un commento