vl4dr/cve-2024-42642Exploits de preuve de concept pour trois vulnérabilités dans le mécanisme de mise à jour du firmware du SSD Crucial MX500, permettant des dépassements de tampon et une exécution de code potentielle via des commandes ATA.
L'appareil en question est un SSD de la série MX500. Ces SSD sont contrôlés par un microcontrôleur Sillicon-Motion SM2259 (les lots plus anciens avaient un contrôleur plus ancien, Sillicon-Motion SM2258, mais ce document se concentre principalement sur le plus récent).
SM2259 est un microcontrôleur SATA 6 Gb/s à 4 canaux qui embarque un CPU 32 bits little-endian basé sur l'architecture ARC.
En observant le dernier firmware applicable à la date de ce document, à savoir M3CR046, quelques problèmes ont été identifiés et confirmés à la fois statiquement et dynamiquement.
Tous les problèmes ont été identifiés dans le mécanisme de mise à jour du firmware du contrôleur, qui correspond au gestionnaire du microcontrôleur de la commande ATA PIO DOWNLOAD-MICROCODE (0x92), plus précisément dans la logique qui télécharge le firmware en utilisant la méthode des offsets, qui correspond aux sous-commandes 0x03 et 0x0E.
Tous les bugs couverts dans ce document ont été vérifiés sur un Crucial MX500 500 Go (CT500MX500SSD1), contrôleur SM2259H-AC exécutant le FW M3CR046 avec des puces flash NY112, en utilisant un PC avec un CPU x86_64.
Le code FW est mappé à l'adresse de base 0x80020000, et le gestionnaire ATA vulnérable est situé à l'adresse 0x80024A9C. Une version décompilée de la fonction se trouve dans resources/download_microcode_handler.c pour votre commodité.
Pour ceux qui préfèrent éviter les détails techniques et comprendre l'essentiel, veuillez vous référer à la section FAQ ci-dessous.
Comme M3CR046 contient plusieurs images firmware parmi lesquelles celle appropriée est choisie par le mécanisme de mise à jour (peut-être en fonction des puces flash réelles utilisées, ou d'autres caractéristiques matérielles), ce document couvrira les spécificités de la première variante du firmware (car c'est le firmware pris en charge sur notre disque spécifique, et nous n'avons donc pu tester que cette variante). Cependant, les bugs présentés dans ce document semblent s'appliquer à toutes les variantes du firmware, mais il peut y avoir quelques différences dans les spécificités lors de leur reproduction.
Ce problème concerne les cas où le premier bloc envoyé a une taille supérieure à 0x200 secteurs. Si nous examinons le gestionnaire de commandes ATA, plus précisément la logique exécutée lorsque la taille du bloc est supérieure à la taille du secteur et lorsque le bloc est le premier envoyé :
Cela définit certaines variables en fonction de l'offset suivant (qui dans notre cas, puisque nous n'avons envoyé qu'un seul bloc jusqu'à présent, correspond à la longueur du bloc en secteurs) et d'une variable nommée lower_bound_fw_offset qui est l'offset de bloc (c'est-à-dire l'offset en granularité de secteurs) au sein de l'image téléchargée d'entrée où notre image firmware est censée se trouver. C'est une valeur codée en dur par variante de firmware, qui dans notre cas (la première variante) est égale à 0.
Dans ce cas, un dépassement inférieur se produit lors du calcul du résultat de soustraction pour some_index, faisant que some_index atteint une valeur aussi élevée que 0xFFFF. C'est un comportement inattendu, car d'après la logique qui déplace les données vers le tampon de téléchargement :
Nous observons que l'adresse source à partir de laquelle les données sont copiées pourrait ne pas être valide étant donné la valeur inattendue calculée pour some_index.
Lors du test dynamique en envoyant une demande de mise à jour du firmware avec le premier bloc d'une taille supérieure à 0x200 secteurs, le contrôleur se bloque et n'envoie même pas de réponse à la demande initiale. C'est cohérent et facilement reproductible.
Il est probable que cela se produise en raison d'une référence invalide à l'adresse source calculée, ce qui déclenche une exception provoquant le blocage du contrôleur. Cela n'a pas été prouvé, mais c'est une conjecture qui pourrait expliquer le blocage.
L'image téléchargée d'entrée (pour M3CR046) a une taille de 0x242400 octets, et à l'intérieur de cette image se trouvent 3 images firmware internes dont une seule est finalement écrite dans la flash après un processus de mise à jour du firmware, chacune de ces images ayant une taille de 0xC0C00 octets (ou 0x606 secteurs).
Cela signifie que lorsque le mécanisme de mise à jour du firmware extrait la copie correcte du firmware à partir de l'image téléchargée d'entrée, il doit vérifier que sa taille ne dépasse pas 0xC0C00 octets.
Le contrôleur tente effectivement de le faire, mais il existe certains cas particuliers qui peuvent conduire à un comportement inattendu. Jetons un coup d'œil à l'extrait suivant (qui partage du code avec le bug précédent) :
Si le bloc actuel a une taille supérieure à 0x200 secteurs et qu'il ne s'agit pas du premier bloc de la séquence, alors 0x200 secteurs (0x40000 octets) seront copiés à la fois. Ensuite, il y a une vérification dont le but est de tronquer les octets excédentaires du nombre d'octets à copier si la taille totale de l'image firmware dépasse higher_bound_fw_offset (qui dans notre cas, est de 0x606 secteurs, puisque la taille du firmware devrait être exactement cela).
Cette logique semble globalement cohérente, mais il y a un défaut – si le dernier bloc envoyé fait que l'offset suivant devient trop élevé, de sorte que le nombre d'octets excédentaires dépasse 0x200 secteurs (ou 0x40000 octets), alors curr_bytes_to_copy obtient une valeur « négative », qui provoque un dépassement inférieur à environ ~4 Go (~0xFFFFFFFF). Comme nous l'avons vu précédemment, cette variable est utilisée pour déterminer le nombre d'octets à transférer vers le tampon de téléchargement.
Si nous examinons r_maybe_some_efficient_data_transfer, nous voyons le morceau de code suivant :
Ce qui signifie que la taille de copie est tronquée à 32 Mo (à partir de la taille de copie originale de ~4 Go), mais c'est encore un grand nombre qui pourrait également provoquer un comportement indéfini si la plage mémoire commençant à 0x40000000 a une taille inférieure à 32 Mo.
Lors du test dynamique en envoyant des blocs ATA pour atteindre un offset de 0x600, puis en envoyant un grand bloc de taille 0x207 secteurs pour déclencher le dépassement inférieur, le contrôleur se bloque à nouveau, probablement en raison d'un accès mémoire invalide lors de la copie.
Ce bug est plus intéressant que le précédent, car même si nous n'avons pas d'écrasement contrôlé (mais plutôt un grand écrasement qui déclenche probablement une exception bloquant le contrôleur), si la fonction qui déplace les données vers le tampon de téléchargement parvient à transférer autant de données avant de planter (écrasant la plage mémoire située juste après le tampon de téléchargement en mémoire principale), alors le comportement du gestionnaire d'exceptions pourrait être modifié en fonction des données écrasées. Cela pourrait éventuellement se produire si, par exemple, le gestionnaire d'exceptions lit un pointeur dans la zone écrasée puis saute dessus (ce cas spécifique n'est pas particulièrement probable, mais avec un peu plus de recherche, quelque chose de ce genre pourrait être découvert).
