Google Project Zero ha informado anteriormente problemas importantes en los propios productos de Google, así como en productos de otras compañías como Windows, iPhone, GPU Qualcomm Adreno, GitHub y otros. Ahora, ha informado públicamente de un error en Chrome OS después de que el equipo correspondiente no pudo solucionarlo dentro de los 90 días asignados.
La pregunta en cuestión es cómo Chrome OS maneja los dispositivos USB cuando el dispositivo está bloqueado. Esencialmente, Chrome OS usa USBGuard para configurar listas permitidas y bloqueadas para dispositivos USB. Sin embargo, la configuración incorrecta de esta plataforma puede provocar que los dispositivos USB no autenticados no puedan acceder al kernel y al almacenamiento de la PC.
Como describe el investigador de seguridad de Google Project Zero, Jann Horn , USBGuard en Chrome OS tiene una lista negra que no autentica los dispositivos USB con ciertos descriptores de interfaz de clase en la pantalla de bloqueo. Sin embargo, después de esta verificación, se permiten todas las demás interfaces.
Esto significa que, si bien un dispositivo USB no autenticado se bloqueará correctamente en la pantalla de bloqueo, otros dispositivos pueden emular un dispositivo de almacenamiento masivo, modificar el núcleo del atacante para que no aparezca como un dispositivo USB y ser autenticados. Esto se debe a que la clase USB es irrelevante para el núcleo, por lo que también permite la modificación desde un dispositivo aparentemente autenticado. Horn señala que:
Además del problema de que los controladores para dispositivos que no pertenecen a estas clases de interfaz USB tienen una gran cantidad de superficies de ataque, existe otro problema con este enfoque: al kernel a menudo no le importa qué clase de USB dice ser el dispositivo. ser – estar. Los controladores USB generalmente funcionan incluso para protocolos estandarizados: el controlador indica con baja prioridad que le gustaría vincularse a dispositivos compatibles con los estándares utilizando la clase de interfaz USB adecuada, pero también indica con alta prioridad que le gustaría vincularse a dispositivos USB específicos basados en en la identificación del proveedor y la identificación del producto sin preocuparse por su clase de interfaz USB.
[…] Si usamos una máquina Linux con el hardware apropiado (estoy usando una placa de desarrollo NET2380, pero probablemente también puedas hacer esto con un teléfono Pixel desbloqueado o una Raspberry Pi Zero W o algo similar) para emular un USB Mass Dispositivo de almacenamiento usando (this) y corrija una línea en el kernel del atacante para que se haga pasar por una valla publicitaria y no por un dispositivo de almacenamiento.
Este problema se marcó como una vulnerabilidad de gravedad alta y se informó de forma privada al equipo de Chrome OS el 24 de febrero. basado en controladores, no en descriptores de interfaz de clase. El 11 de mayo, el equipo de Chrome OS proporcionó actualizaciones de progreso, pero debido a que no pudieron corregir el error en los 90 días asignados, el problema se reveló públicamente el 24 de mayo.
No está claro cuándo se lanzará una solución, pero es importante tener en cuenta que se trata de una vulnerabilidad local que requiere que un atacante inserte manualmente una unidad USB para comprometer el dispositivo y su kernel. No se puede usar de forma remota, pero actúa como un vector de ataque para otras vulnerabilidades si deja su computadora Chrome OS desatendida, incluso si está bloqueada.
Deja una respuesta