vl4dr/cve-2024-42642Pruebas de concepto de explotación para tres vulnerabilidades en el mecanismo de actualización de firmware del SSD Crucial MX500, que permiten desbordamientos de búfer y posible ejecución de código mediante comandos ATA.
El dispositivo en cuestión es cualquier SSD de la serie MX500. Estos SSD están controlados por un controlador Sillicon-Motion SM2259 (los lotes antiguos tenían un controlador más antiguo, Sillicon-Motion SM2258, pero el enfoque principal de este documento es el más reciente).
SM2259 es un micro-controlador SATA 6Gb/s de 4 canales que cuenta con una CPU de 32 bits little-endian basada en la arquitectura ARC.
Al observar el firmware más reciente aplicable a la fecha de este documento, que es M3CR046, se identificaron y confirmaron varios problemas, tanto estática como dinámicamente.
Todos los problemas fueron identificados en el mecanismo de actualización de firmware del controlador, que corresponde al manejador del micro-controlador del comando ATA PIO DOWNLOAD-MICROCODE (0x92), específicamente en la lógica que descarga el firmware usando el método de offsets, que corresponde a los subcomandos 0x03 y 0x0E.
Todos los bugs cubiertos en este documento fueron verificados en un SSD Crucial MX500 de 500GB (CT500MX500SSD1), con controlador SM2259H-AC ejecutando el FW M3CR046 con chips de memoria flash NY112, usando un PC con CPU x86_64.
El código del FW está mapeado a la dirección base 0x80020000, y el manejador ATA vulnerable se encuentra en la dirección 0x80024A9C. Una versión descompilada de la función se puede encontrar en resources/download_microcode_handler.c para su conveniencia.
Para aquellos que prefieran no lidiar con los detalles técnicos y solo quieran entender el resultado final, por favor consulte la sección de Preguntas Frecuentes más abajo.
Como M3CR046 contiene múltiples imágenes de firmware de las cuales el mecanismo de actualización de firmware elige la apropiada (quizás dependiendo de los chips de memoria flash reales utilizados, u otras características de hardware), este documento cubrirá los detalles de la primera variante de firmware (ya que es el firmware soportado en nuestro disco específico, y por lo tanto solo pudimos probar esa variante de firmware). Sin embargo, los bugs presentados en este documento parecen aplicar a todas las variantes de firmware, pero puede haber algunas diferencias en los detalles específicos al reproducirlos.
Este problema se refiere a los casos en los que el primer fragmento enviado es de tamaño mayor que 0x200 sectores. Si miramos dentro del manejador de comandos ATA, específicamente en la lógica que se ejecuta cuando el tamaño del fragmento es mayor que el tamaño de sector y cuando el fragmento es el primero que se envía:
Esto establece algunas variables basadas en el siguiente offset (que en nuestro caso, dado que solo hemos enviado un solo fragmento hasta ahora, es la longitud del fragmento en sectores) y en una variable llamada lower_bound_fw_offset que es el offset de bloque (es decir, offset en granularidad de sectores) dentro de la imagen de descarga de entrada donde se espera que se encuentre nuestra imagen de firmware. Este es un valor hardcodeado por variante de firmware, que en nuestro caso (la primera variante), es igual a 0.
En este caso, se produce un underflow al calcular el resultado de la resta para some_index, haciendo que some_index sea tan alto como 0xFFFF. Este es un comportamiento inesperado, ya que según la lógica que mueve los datos al búfer de descarga:
Observamos que la dirección de origen desde la cual se copian los datos podría no ser válida dado el valor inesperado calculado para some_index.
Al probar esto dinámicamente enviando una solicitud de actualización de firmware con el primer fragmento de tamaño mayor que 0x200 sectores, el controlador se cuelga y ni siquiera envía una respuesta a la solicitud original. Esto es consistente y fácilmente reproducible.
Es probable que esto ocurra debido a una referencia inválida a la dirección de origen calculada, lo que luego desencadena una excepción que causa el cuelgue del controlador. Esto no ha sido probado, sino que es una conjetura que podría explicar el cuelgue.
La imagen de descarga de entrada (para M3CR046) es de tamaño 0x242400 bytes, y dentro de esta imagen hay 3 imágenes de firmware internas de las cuales solo una es finalmente escrita a la flash después de un proceso de actualización de firmware, cada una de estas imágenes es de tamaño 0xC0C00 bytes (o 0x606 sectores).
Esto significa que, cuando el mecanismo de actualización de firmware extrae la copia correcta del firmware de la imagen de descarga de entrada, debe verificar que su tamaño no exceda 0xC0C00 bytes.
El controlador efectivamente intenta hacerlo, pero hay algunos casos límite que pueden llevar a un comportamiento inesperado. Echemos un vistazo al siguiente fragmento (que comparte algo de código con el bug anterior):
Si el fragmento actual es de tamaño mayor que 0x200 sectores y no es el primer fragmento en la secuencia, entonces se copiarán 0x200 sectores (0x40000 bytes) a la vez. Luego, hay una verificación cuyo propósito es truncar los bytes sobrantes del número de bytes a copiar si el tamaño total de la imagen de firmware excede higher_bound_fw_offset (que en nuestro caso, es 0x606 sectores, ya que el tamaño del firmware debería ser exactamente este).
Esta lógica tiene sentido en general, pero hay un fallo: si el último fragmento enviado hace que el siguiente offset sea demasiado alto, de modo que el número de bytes sobrantes exceda 0x200 sectores (o 0x40000 bytes), entonces curr_bytes_to_copy obtiene un valor "negativo", que hace underflow hasta aproximadamente ~4GB (~0xFFFFFFFF). Como vimos antes, esta variable se usa para determinar el número de bytes a transferir al búfer de descarga.
Si observamos dentro de r_maybe_some_efficient_data_transfer, vemos el siguiente fragmento de código:
Lo que significa que el tamaño de copia se trunca a 32MB (desde el tamaño de copia original de ~4GB), pero sigue siendo un número grande que también podría causar un comportamiento indefinido si el rango de memoria que comienza en 0x40000000 es de tamaño menor que 32MB.
Al probar esto dinámicamente enviando fragmentos ATA para llegar a un offset de 0x600, y luego enviando un fragmento grande de tamaño 0x207 sectores para provocar el underflow, el controlador se cuelga nuevamente, probablemente debido a un acceso a memoria inválido durante la copia.
Este bug es más interesante que el anterior, porque aunque no tenemos una sobrescritura controlada (sino más bien una sobrescritura grande que posiblemente provoca una excepción que cuelga el controlador), si la función que mueve los datos al búfer de descarga realmente logra transferir esa cantidad de datos antes de fallar (sobrescribiendo el rango de memoria que se encuentra justo después del búfer de descarga en la memoria principal), entonces quizás el comportamiento del manejador de excepciones pueda ser alterado según los datos sobrescritos. Eso posiblemente podría ocurrir si, por ejemplo, el manejador de excepciones lee un puntero del área sobrescrita y luego salta a él (este caso específico no es particularmente probable, pero con un poco más de investigación, algo de ese tipo podría descubrirse).
