Uma vulnerabilidade aparentemente importante foi descoberta pelo pesquisador de segurança e estudante de doutorado da Northwestern Zhenpeng Lin, afetando o kernel no Pixel 6 e 6 Pro e outros dispositivos Android rodando Linux versões do kernel baseadas em 5.22 como o Galaxy S Series. Detalhes precisos sobre como a vulnerabilidade funciona ainda não foram publicados, mas o pesquisador afirma que ela pode habilitar leitura e gravação arbitrária, escalonamento de privilégios e desabilitar as proteções de segurança do SELinux – em suma, isso é um problema. O pesquisador verificou à Polícia Android que o Google não foi informado da vulnerabilidade antes de sua demonstração no Twitter.
VÍDEO DA POLÍCIA ANDROID DO DIA
Nenhum dos detalhes técnicos precisos por trás de como o exploit funciona foi lançado, mas um vídeo alegando mostrar o exploit (aparentemente chamado ” raviole” no vídeo) usado em um Pixel 6 Pro conseguiu fazer root e desabilitar o SELinux. Com ferramentas como essa, um ator mal-intencionado pode causar muitos danos.
window.arrayOfEmbeds = {‘twitter’ : ‘”nO Google Pixel 6 mais recente foi lançado com 0 dia no kernel! Leitura/escrita arbitrária para escalar privilégios e desabilitar o SELinux sem seqüestrar o fluxo de controle. O bug também afeta o Pixel 6 Pro, outros pixels não são afetados 🙂 pic.twitter.com/UsOI3ZbN3Ln— Zhenpeng Lin (@Markak_) 5 de julho, 2022 Tu pode verificar para ver o seu telefone s versão do kernel com bastante facilidade, se você está preocupado, apenas as versões 5.+ deve ser afetado.
Falando com Lin por e-mail, ele confirmou à Polícia do Android que os detalhes precisos da vulnerabilidade foram divulgados publicamente. Ele confirmou ainda que, na noite passada, o Google ainda não havia sido informado sobre a vulnerabilidade e não há CVE correspondente, embora tenhamos sido informados de que um relatório estava sendo elaborado para a empresa naquele momento.
Freqüentemente, os pesquisadores de segurança se abstêm de divulgar publicamente detalhes de qualquer tipo sobre vulnerabilidades em um período que conhecido como “divulgação coordenada de vulnerabilidades”, em que os pesquisadores de segurança apenas divulgam uma exploração ao público como um esforço de última hora para proteger os usuários finais se e quando tentativas anteriores de alcançar as empresas envolvidas falharem. Por exemplo, Google a divisão de pesquisa de segurança interna (Projeto Zero) tem um 12-dia para uma resposta sobre vulnerabilidades que são't sendo ativamente explorado e uma política de 7 dias para aqueles que são (mais um 10 dias se os patches caírem dentro dessa janela).
Enquanto o pesquisador não tem't lançou um conjunto completo de instruções sobre como esta vulnerabilidade funciona, nós não ' geralmente não vemos uma exibição pública de uma grande vulnerabilidade como esta acontecer antes ou as empresas envolvidas com ele são informadas. Isso pode afetar coisas como pagamentos de recompensas por bugs. No ano passado, o Google emitiu US$ 8,7 milhões em recompensas por bugs, e atualmente a empresa diz que paga até US$ 728, para vulnerabilidades no nível do kernel, o que parece ser. A vulnerabilidade pode até se qualificar para outras categorias de recompensas separadas, mas divulgar a vulnerabilidade publicamente antes de denunciá-la ao Google pode afetar tudo isso. As circunstâncias são analisadas caso a caso, mas as regras publicadas parecem que divulgar a vulnerabilidade no Twitter pode impedir a recompensa típica, mesmo que o vídeo não descreva completamente como a vulnerabilidade funciona. O Google, em última análise, tem a última palavra, e a maioria dos pesquisadores parece errar no lado da cautela.
O Google e a Samsung ainda não responderam às nossas perguntas sobre a vulnerabilidade, então istoZ não está claro em que tipo de cronograma ele pode ser corrigido. Dada a linha do tempo e como o Google se os patches de segurança funcionarem, talvez não vejamos esse problema resolvido até o nível de patch de setembro, no mínimo, e a falta de divulgação poderia afetar ainda mais isso. Outros fabricantes podem conseguir uma correção para o problema em seus próprios patches antecipadamente, caso um esteja disponível separadamente – a Samsung aparentemente fez isso no caso do Dirty Pipe no início deste ano.
