vl4dr/cve-2024-42642Exploits de prova de conceito para três vulnerabilidades no mecanismo de atualização de firmware do SSD Crucial MX500, permitindo buffer overflows e potencial execução de código via comandos ATA.
O dispositivo em questão é qualquer SSD da série MX500. Estes SSDs são controlados por um microcontrolador Sillicon-Motion SM2259 (lotes mais antigos possuíam um controlador mais antigo, Sillicon-Motion SM2258, mas o foco principal deste documento é o mais novo).
SM2259 é um microcontrolador SATA de 4 canais a 6Gb/s que possui uma CPU little-endian de 32 bits baseada na arquitetura ARC.
Observando o firmware mais recente aplicável à data deste documento, que é M3CR046, alguns problemas foram identificados e confirmados tanto estática quanto dinamicamente.
Todos os problemas foram identificados no mecanismo de atualização de firmware do controlador, que corresponde ao manipulador do microcontrolador para o comando ATA PIO DOWNLOAD-MICROCODE (0x92), especificamente na lógica que baixa o firmware usando o método de offsets, que corresponde aos subcomandos 0x03 e 0x0E.
Todos os bugs abordados neste documento foram verificados em um Crucial MX500 500GB SSD (CT500MX500SSD1), controlador SM2259H-AC rodando FW M3CR046 com chips flash NY112, usando um PC com CPU x86_64.
O código do FW está mapeado para o endereço base 0x80020000, e o manipulador ATA vulnerável está localizado no endereço 0x80024A9C. Uma versão descompilada da função pode ser encontrada em resources/download_microcode_handler.c para sua conveniência.
Para aqueles que preferem não lidar com os detalhes técnicos e preferem entender o resultado final, consulte a seção de FAQ abaixo.
Como o M3CR046 contém múltiplas imagens de firmware, das quais a apropriada é escolhida pelo mecanismo de atualização de firmware (talvez dependendo dos chips flash reais utilizados ou de outras características de hardware), este documento cobrirá as especificidades da primeira variante de firmware (já que este é o firmware suportado em nossa unidade específica e, portanto, só pudemos testar essa variante). No entanto, os bugs apresentados neste documento parecem se aplicar a todas as variantes de firmware, mas pode haver algumas diferenças nas especificidades reais ao reproduzi-los.
Este problema refere-se a casos em que o primeiro bloco enviado tem tamanho maior que 0x200 setores. Se observarmos o manipulador do comando ATA, especificamente na lógica executada quando o tamanho do bloco é maior que o tamanho do setor e quando o bloco é o primeiro enviado:
Isso define algumas variáveis com base no próximo offset (que no nosso caso, como enviamos apenas um bloco até agora, é o comprimento do bloco em setores) e em uma variável chamada lower_bound_fw_offset, que é o offset de bloco (ou seja, offset na granularidade de setores) dentro da imagem de download de entrada onde nossa imagem de firmware é esperada. Este é um valor hardcoded por variante de firmware, que no nosso caso (a primeira variante) é igual a 0.
Neste caso, ocorre um underflow ao calcular o resultado da subtração para some_index, fazendo com que some_index atinja o valor de 0xFFFF. Este é um comportamento inesperado, pois, com base na lógica que move os dados para o buffer de download:
Observamos que o endereço de origem do qual os dados são copiados pode não ser válido, dado o valor inesperado calculado para some_index.
Ao testar isso dinamicamente, enviando uma solicitação de atualização de firmware com o primeiro bloco de tamanho maior que 0x200 setores, o controlador trava e nem sequer envia uma resposta à solicitação original. Isso é consistente e facilmente reproduzível.
É provável que isso aconteça devido a uma referência inválida ao endereço de origem calculado, que então dispara uma exceção que causa a trava do controlador. Isso não foi comprovado, mas é uma conjectura que pode explicar a trava.
A imagem de download de entrada (para M3CR046) tem tamanho 0x242400 bytes, e dentro desta imagem existem 3 imagens internas de firmware, das quais apenas uma é eventualmente gravada na flash após um processo de atualização de firmware. Cada uma dessas imagens tem tamanho 0xC0C00 bytes (ou 0x606 setores).
Isso significa que, quando o mecanismo de atualização de firmware extrai a cópia correta do firmware da imagem de download de entrada, ele deve verificar se seu tamanho não excede 0xC0C00 bytes.
O controlador realmente tenta fazer isso, mas há alguns casos extremos que podem levar a um comportamento inesperado. Vamos dar uma olhada no seguinte trecho (que compartilha algum código com o bug anterior):
Se o bloco atual tiver tamanho maior que 0x200 setores e não for o primeiro bloco na sequência, então 0x200 setores (0x40000 bytes) serão copiados de cada vez. Em seguida, há uma verificação cujo propósito é truncar os bytes excedentes do número de bytes a copiar se o tamanho total da imagem de firmware exceder higher_bound_fw_offset (que no nosso caso é 0x606 setores, já que o tamanho do firmware deve ser exatamente este).
Essa lógica faz sentido de modo geral, mas há uma falha – se o último bloco enviado fizer com que o próximo offset se torne muito alto, de modo que o número de bytes excedentes ultrapasse 0x200 setores (ou 0x40000 bytes), então curr_bytes_to_copy recebe um valor "negativo", que sofre underflow para aproximadamente ~4GB (~0xFFFFFFFF). Como vimos antes, esta variável é usada para determinar o número de bytes a serem transferidos para o buffer de download.
Se observarmos o interior de r_maybe_some_efficient_data_transfer, vemos o seguinte trecho de código:
O que significa que o tamanho da cópia é truncado para 32MB (a partir do tamanho de cópia original de ~4GB), mas ainda é um número grande que também pode causar um comportamento indefinido se o intervalo de memória começando em 0x40000000 tiver tamanho inferior a 32MB.
Ao testar isso dinamicamente, enviando blocos ATA para chegar a um offset de 0x600 e, em seguida, enviando um bloco grande de tamanho 0x207 setores para disparar o underflow, o controlador trava novamente, provavelmente devido a um acesso de memória inválido durante a cópia.
Este bug é mais interessante que o anterior, porque, embora não tenhamos uma sobrescrita controlada (mas sim uma grande sobrescrita que possivelmente dispara uma exceção que trava o controlador), se a função que move os dados para o buffer de download realmente conseguir transferir essa quantidade de dados antes de travar (sobrescrevendo o intervalo de memória localizado logo após o buffer de download na memória principal), então talvez o comportamento do manipulador de exceções possa ser alterado com base nos dados sobrescritos. Isso pode acontecer, por exemplo, se o manipulador de exceções ler um ponteiro da área sobrescrita e então pular para ele (este caso específico não é particularmente provável, mas com mais pesquisa, algo do tipo pode ser descoberto).
Conforme afirmado, o tamanho da imagem de download é 0x242400 (ou 0x1212 setores). O firmware verifica que o tamanho total da imagem transferida não excede este tamanho, verificando se o próximo offset não ultrapassa 0x1212 setores. Esta verificação faz sentido, mas o cálculo do próximo offset é falho:
