O Google Project Zero relatou anteriormente grandes problemas nos próprios produtos do Google, bem como em produtos de outras empresas, como Windows, iPhone, GPUs Qualcomm Adreno, GitHub e outros. Agora, ele relatou publicamente um bug no Chrome OS depois que a equipe relevante não conseguiu corrigi-lo dentro dos 90 dias previstos.
A questão em questão é sobre como o Chrome OS lida com dispositivos USB quando o dispositivo está bloqueado. Essencialmente, o Chrome OS usa o USBGuard para configurar listas permitidas e bloqueadas para dispositivos USB. No entanto, configurações incorretas desta plataforma podem fazer com que dispositivos USB não autenticados não consigam acessar o kernel e o armazenamento do PC.
Como o pesquisador de segurança do Google Project Zero Jann Horn descreve, o USBGuard no Chrome OS tem uma lista negra que não autentica dispositivos USB com determinados descritores de interface de classe na tela de bloqueio. No entanto, após esta verificação, todas as outras interfaces são permitidas.
Isso significa que, embora um dispositivo USB não autenticado seja devidamente bloqueado na tela de bloqueio, outros dispositivos podem emular um dispositivo de armazenamento em massa, modificar o kernel do invasor para não aparecer como um dispositivo USB e ser autenticados. Isso ocorre porque a classe USB é irrelevante para o kernel, portanto, também permite a modificação de um dispositivo aparentemente autenticado. Horn observa que:
Além do problema de drivers para dispositivos que não pertencem a essas classes de interface USB terem um grande número de superfícies de ataque, há outro problema com essa abordagem: o kernel geralmente não se importa com qual classe USB o dispositivo afirma ser. ser. Os drivers USB geralmente funcionam mesmo para protocolos padronizados: o driver indica em baixa prioridade que gostaria de se conectar a dispositivos compatíveis com os padrões usando a classe de interface USB apropriada, mas também indica em alta prioridade que gostaria de se vincular a dispositivos USB específicos baseados no ID do fornecedor e no ID do produto sem se preocupar com a classe de interface USB.
[…] Se usarmos uma máquina Linux com o hardware apropriado (estou usando uma placa de desenvolvimento NET2380, mas provavelmente você também pode fazer isso com um telefone Pixel desbloqueado ou um Raspberry Pi Zero W ou algo semelhante) para emular um USB Mass Dispositivo de armazenamento usando (this) , e corrija uma linha no kernel do invasor para que ele represente um outdoor e não um dispositivo de armazenamento.
Esse problema foi sinalizado como uma vulnerabilidade de alta gravidade e foi relatado em particular à equipe do Chrome OS em 24 de fevereiro. baseado em drivers, não em descritores de interface de classe. Em 11 de maio, a equipe do Chrome OS forneceu atualizações de progresso, mas como não conseguiram corrigir o bug nos 90 dias previstos, o problema foi divulgado publicamente em 24 de maio.
Não está claro quando uma correção será lançada, mas é importante observar que esta é uma vulnerabilidade local que exige que um invasor insira manualmente uma unidade USB para comprometer o dispositivo e seu kernel. Ele não pode ser usado remotamente, mas atua como um vetor de ataque para outras explorações se você deixar seu computador Chrome OS sem vigilância, mesmo que esteja bloqueado.
Deixe um comentário