Esta semana em segurança: GTA, Apple e Android e inicialização insegura

Quando vimos os tweets pela primeira vez sobre um problema de segurança no Grand Theft Auto V, parecia um troll. “Pressione ‘alt e f4’ para desbloquear um modo de trapaça”, ou o hacker que afirma ser capaz de deletar seu personagem. [Tez2]tweet de aviso que você não deve jogar GTA Online sem um firewall soa como outra dessas lendas urbanas online. Mas este realmente parece legítimo. O NIST está participando da diversão, atribuindo CVE-2023-24059 para o exploit.

Ao jogar um jogo online, outros usuários enviam uma “solicitação de entrada” para entrar na sessão ativa. Esses pacotes podem conter dados malformados que podem travar o cliente do jogo remotamente. Acredita-se, embora não confirmado publicamente, que também seja uma vulnerabilidade de Execução Remota de Código (RCE). Parece provável que esse aspecto seja adicionado a alguns dos vários painéis de truques que já são amplamente usados ​​neste jogo de 10 anos. Portanto, agora, em vez de apenas dar ao seu próprio personagem munição e saúde infinitas, você pode causar estragos em outros jogadores, possivelmente até corromper seus arquivos de personagem e bani-los.

Mas por que parar por aí? Se tivermos execução de código dentro do jogo, o que impede outro jogador de lançar um ataque real? Um videogame não é protegido como um navegador, e não há nada que impeça um ataque de limpador de disco ou mesmo um worm de comprometer vários jogadores. A pior parte é que é um jogo antigo e, embora haja uma grande base de jogadores, não é garantido que seja corrigido. Há pelo menos um projeto com o objetivo de ser um firewall para evitar o problema.

Bugs de 19 e 20 anos de XNU

[Adam Doupé] parece ter um talento especial para encontrar bugs antigos no código da Apple, e desta vez é um par de falhas realmente antigas no kernel da Apple, XNU. A primeira é uma questão em dlil.c, o manipulador de interface de rede. Esse problema é um erro de conversão de tipo, em que um int é convertido em um uint_16. Se essa conversão transbordar, o valor se tornará um grande número negativo e a gravação de dados subsequente transbordará do buffer e gravará fora dos limites. O método para acionar este é um pouco complicado, pois requer a criação de 65536 interfaces de rede.

Existem duas abordagens para desencadear essa condição. A primeira é a mais simples, um pequeno script rodando como root, que chama ifconfig repetidamente para criar as interfaces. Embora isso possa ser interessante como parte de uma cadeia de exploração, a ideia mais interessante é criar um dongle USB malicioso que se apresente como várias interfaces de rede. O resto da postagem é [Adam]tentativa de transformar o underflow em um exploit. Ele não conseguiu, mas parece que é possível.

O segundo bug é ainda mais antigo, uma falha de 20 anos no XNU’s ndrv.c, o manipulador de soquete bruto. É um caso extremo em que uma lista vinculada com dois membros é percorrida incorretamente, um dos membros da lista é liberado, mas o item pai ainda contém um ponteiro para a memória agora liberada. Ambos os bugs foram corrigidos nas versões mais recentes do iOS e macOS.

Android (ARM) também

O Android não pode ser deixado de fora, com um ótimo artigo de [Man Yue Mo] do Github Security Lab, sobre um problema na GPU Arm Mali enviada como parte dos dispositivos Pixel 6. Com grande ironia, somos informados de como o único elemento que não é do Google no telefone totalmente do Google levou à exploração do espaço do kernel de dentro de um aplicativo. Especificamente, é o driver dessa GPU e como ela lida com a memória JIT, que são segmentos de memória gerenciados pelo kernel e acessados ​​pelo espaço do usuário e diretamente pela GPU. E, como você pode esperar, ter três componentes diferentes acessando a memória ao mesmo tempo pode causar problemas.

Nesse caso, o problema é como o despejo é tratado. Esses pedaços de memória são processados ​​e, em seguida, podem ser devolvidos ao armazenamento gratuito. Uma otimização de desempenho pelo driver é manter os buffers de memória “quentes”, não realmente pedindo ao kernel para liberá-los e pular o processo de alocação quando a próxima solicitação for necessária. O problema é que a memória nesse estado de limbo é considerada “removível” e o kernel pode liberar essas regiões sem fazer isso por meio do driver da GPU. Isso deixa o sistema em um estado estranho, onde o driver da GPU e o espaço do usuário ainda possuem ponteiros válidos para um local de memória, mas o kernel o marcou como livre. A verdadeira diversão começa quando o local de memória liberado é reivindicado por um processo de ataque e um objeto JIT falso é colocado em seu lugar. Por alguma manipulação de memória inteligente, isso pode ser aproveitado para produzir um mapeamento de espaço de usuário do código do kernel, que pode ser lido e escrito. E o passo mais simples a partir daí é apenas modificar o aplicativo userspace, fazendo-o rodar como root.

É uma descoberta inteligente, mas o que realmente se destaca é o problema de consertá-lo. Isso foi relatado aos engenheiros do Android em julho de 2022 e, algumas semanas depois, o relatório foi encerrado como um problema “Não será corrigido”. Há um ponto legítimo aqui, que não é o código do Android que contém o problema, e isso precisava ser corrigido no driver ARM. A ARM emitiu uma atualização que corrigiu o problema menos de três meses depois, em agosto de 2022. Uma divulgação coordenada foi agendada com a ARM para novembro, mas parece que os engenheiros do Android abandonaram completamente o bug e esperaram até a atualização de janeiro para finalmente enviar o patch para usuários do Android. E quando finalmente chegou, foi rastreado como um bug completamente diferente, o que significa que o relatório original foi fechado e esquecido. É um pouco desanimador ver o Google mostrar uma atitude tão irreverente em relação a uma vulnerabilidade dessa gravidade em seu próprio produto.

KSMBD novamente

Está começando a parecer uma má ideia colocar o driver Server Message Block Daemon no kernel do Linux, já que temos outro subfluxo inteiro pré-autenticação levando à negação de serviço. Os pesquisadores da Sysdig descobriram a falha desta vez, pesquisando com base no ZDI-22-1690 anterior, que era um RCE mais sério no mesmo módulo do kernel. Este é um pouco diferente de outros underflows inteiros que vimos. Em vez disso, a natureza envolvente dos números inteiros evita que essa vulnerabilidade seja mais séria.

O verdadeiro problema é que durante a autenticação SMB, a estrutura de dados do usuário remoto contém um par de valores de comprimento, que são usados ​​para analisar os dados de autenticação recebidos. É óbvio que esses valores não são confiáveis ​​implicitamente e algumas boas verificações de erros são feitas para evitar um estouro de buffer trivial. O caso que nos confunde é quando nt_len é menos do que CIFS_ENCPWD_SIZE, e o valor resultante é negativo. Quando este inteiro negativo é convertido para o unsigned size_t em um memcpy() chamada, o inteiro negativo é “desempacotado” para um valor quase máximo size_t. A função de cópia de memória tentará a instrução, mas esta é uma operação bastante descontrolada e, eventualmente, atinge a memória inacessível e faz com que o kernel entre em pânico. Até agora não parece haver uma maneira de transformar essa falha específica em um verdadeiro RCE. Além disso, depois de tantos anos, certamente todo mundo sabe que não deve expor um serviço SMB a usuários não confiáveis, certo?

Inicialização insegura

Embora o Secure Boot não tenha provado ser o bloqueio distópico do PC que alguns de nós temíamos, ainda é ocasionalmente difícil lidar com isso ao tentar consertar algo em uma máquina quebrada. Precisa de um disco de inicialização personalizado para executar uma ferramenta? Sim, hora de desativar a inicialização segura. Mas há alguns casos em que é útil, como impedir que o malware de inicialização se infiltre em um sistema criptografado. Talvez haja algo a ser dito sobre uma quantidade conhecida, como inicialização segura.

É por isso que é um pouco estranho descobrir que a MSI decidiu comprometê-lo em massa em suas placas-mãe de desktop em uma atualização de firmware lançada em janeiro passado. E observe que o MSI não desativou a inicialização segura. Verifique as configurações do firmware ou execute mokutil --sb-state, e essas máquinas informariam com prazer que o Secure Boot ainda estava ativado. Mas uma configuração de firmware obscura, “Política de Execução de Imagem” está definida como “Sempre Executar” – então o Secure Boot ainda verificaria a assinatura na pilha de inicialização e, em seguida, inicializaria independentemente do que fosse encontrado. Vou apenas citar o descobridor, [Dawid Potocki]A conclusão de: “Não confie que quaisquer recursos de segurança que você habilitou estão funcionando, TESTE-OS!”

RCE do QT Vulnerabilidade Erro

O pacote QT tem um problema, onde o Javascript embutido no código QML (Qt Modeling Language) pode desencadear um dos dois problemas de manipulação de memória e atingir o RCE. Há um pouco de desacordo entre o Cisco Talos e o QT, se isso é um bug simples ou uma vulnerabilidade de segurança. O código QML é explicitamente destinado a ser um código de interface do usuário para aplicativos e nunca deve executar código não confiável. Na verdade, de acordo com o QT, a vulnerabilidade de segurança seria qualquer “aplicativo que está passando entrada não confiável para o QtQml”.