oscardagrach/cve-2019-5700CVE-2019-5700
Malheureusement, je n'ai pas de nom tendance et astucieux pour cette vulnérabilité. Ce bug est assez simple à exploiter. Je l'ai en fait gardé pendant un certain temps jusqu'à ce que je réalise qu'il pourrait affecter plus d'appareils que je ne le pensais initialement.
Ce bug affecte les SoC Nvidia Tegra t114-t210 qui démarrent des images de démarrage Android, mais il y a une distinction importante à faire :
Les appareils basés sur t114 sont nettement plus affectés en raison de leur chargeur de démarrage unifié qui charge également le TOS (TLK – le moniteur sécurisé de Nvidia), ce qui signifie que le chargeur de démarrage s'exécute déjà en contexte sécurisé...
Sur les appareils t124+, Nvidia utilise désormais nvtboot comme chargeur de démarrage de première étape qui charge le TOS avant que le chargeur de démarrage vulnérable ne s'exécute, lequel charge et exécute le noyau. Cela signifie que nous nous exécutons dans un contexte non sécurisé.
Examinons l'en-tête de l'image de démarrage Android (v1 – avant Android 9) :
struct boot_img_hdr
{
uint8_t magic[BOOT_MAGIC_SIZE];
uint32_t kernel_size; /* size in bytes */
uint32_t kernel_addr; /* physical load addr */
uint32_t ramdisk_size; /* size in bytes */
uint32_t ramdisk_addr; /* physical load addr */
uint32_t second_size; /* size in bytes */
uint32_t second_addr; /* physical load addr */
uint32_t tags_addr; /* physical addr for kernel tags */
uint32_t page_size; /* flash page size we assume */
uint32_t unused;
uint32_t os_version;
uint8_t name[BOOT_NAME_SIZE]; /* asciiz product name */
uint8_t cmdline[BOOT_ARGS_SIZE];
uint32_t id[8]; /* timestamp / checksum / sha1 / etc */
uint8_t extra_cmdline[BOOT_EXTRA_ARGS_SIZE];
};
Nous voyons les champs pour certaines images familières : noyau, ramdisk :
uint32_t kernel_size; /* size in bytes */
uint32_t kernel_addr; /* physical load addr */
uint32_t ramdisk_size; /* size in bytes */
uint32_t ramdisk_addr; /* physical load addr */
et parfois les tags (souvent utilisés pour l'arbre de périphériques ou les ATAGS)
uint32_t tags_addr; /* physical addr for kernel tags */
uint32_t page_size; /* flash page size we assume */
Et les champs 'second' ?
uint32_t second_size; /* size in bytes */
uint32_t second_addr; /* physical load addr */
Bien que je ne l'aie jamais vu utilisé sur un appareil de production personnellement, il me semble que l'image 'second' peut être utilisée pour un chargeur de démarrage de seconde étape ou une image supplémentaire qui doit être chargée. D'après mon expérience de recherche, la plupart des chargeurs de démarrage d'autres OEM ignorent ce champ – car il n'est pas utilisé – ou appliquent des contrôles de validité sur la taille et l'adresse.
Le chargeur de démarrage de Nvidia applique BIEN des contrôles de validité au noyau, au ramdisk et au dtb – tous ont des adresses de chargement codées en dur, ce qui signifie que les adresses de chargement dans l'en-tête sont ignorées. Cependant, il semble que Nvidia a peut-être oublié cette image largement oubliée... en la chargeant arbitrairement sans aucun contrôle de validité sur l'adresse ou la taille. C'est exact – vous pouvez charger arbitrairement n'importe quelle image, de n'importe quelle taille, vers n'importe quelle adresse mémoire accessible (tout sur t114, mémoire non sécurisée sur t124+).
Cela signifie que nous pouvons librement patcher le chargeur de démarrage en mémoire pour l'adapter à nos besoins. Que nous voulions contourner la vérification de signature (qui vient immédiatement après le chargement de toutes les images), détourner le chargement du TOS sur t114 pour obtenir une exécution de code en contexte sécurisé, ou simplement charger du shellcode pour extraire des informations sensibles.
L'exploitation est aussi simple que de créer une image de démarrage avec l'image secondaire comme charge utile/shellcode et les champs addr/len définis de manière appropriée à la taille de votre charge utile et à l'endroit où vous voulez la placer. L'image peut être aussi petite que 4 octets.
Sur les appareils t124+, nous n'avons pas le contexte sécurisé, car nvtboot a déjà chargé le TOS à une étape précédente du démarrage, puis cède l'exécution à un chargeur de démarrage d'étape ultérieure (EBT), mais nous pouvons toujours écrire librement dans ce chargeur de démarrage d'étape ultérieure en mémoire. Le chargeur de démarrage vulnérable est celui qui charge le noyau, il reste donc assez précieux si vous voulez exécuter du code non signé arbitraire.
Non seulement l'adresse de chargement n'est pas vérifiée, mais la taille non plus, ce qui ouvre la porte à CVE-2019-5699 puisque nous pouvons déborder diverses variables/pointeurs en créant un champ second_size malveillant. Je ne peux pas en prendre le crédit cependant, car je ne l'ai réalisé qu'après coup, après la publication du bulletin de sécurité initial. Cela semble aussi beaucoup plus de travail...
t114 :
IROM->BCT->EBT->TOS->KERNEL
t124+ (peut être légèrement différent pour les SoC 64 bits plus récents) :
IROM->BCT->NVTBOOT->TOS->EBT->KERNEL
Ce problème a été initialement signalé le 29 juillet 2019 à l'équipe PSIRT de Nvidia (Product Security Incident Response Team). Ils m'ont poliment demandé de retarder la divulgation jusqu'à ce que tous les clients concernés aient été informés et que les correctifs soient déployés – ce que j'ai fait avec plaisir. Ils ont maintenu la communication tout au long du processus et ont été agréables à travailler. Aujourd'hui (5 décembre 2019), Nvidia a enfin terminé la distribution du correctif au code concerné et a publié deux bulletins de sécurité différents reflétant ce problème, tout en me donnant le feu vert pour la divulgation.
https://nvidia.custhelp.com/app/answers/detail/a_id/4875
https://nvidia.custhelp.com/app/answers/detail/a_id/4910
balika011
beaups
npjohnson
djrbliss/Dan Rosenberg pour m'avoir fait vérifier méticuleusement comment les chargeurs de démarrage analysent les en-têtes d'image de démarrage