msm8916-mainline/cve-2022-22063Problème de sécurité dans le firmware de l'hyperviseur de certains anciens chipsets Qualcomm
CVE-2022-22063 est un problème de sécurité dans le firmware hyperviseur de certains chipsets Qualcomm plus anciens. Un composant matériel non protégé (le « boot remapper ») peut être détourné pour obtenir un accès complet en lecture/écriture à l'hyperviseur à partir d'un système d'exploitation modifié (élévation de privilèges). L'exploitation du problème est triviale sur les plateformes concernées, car aucune connaissance de la version spécifique du firmware (par exemple adresses ou variables) n'est requise.
Remarque : Bien que Qualcomm ait fourni des correctifs à ses clients (avec largement le temps de publier des mises à jour), de nombreux appareils concernés sont déjà assez anciens et risquent de ne pas recevoir le correctif du vendeur. Le problème ne peut être exploité qu'à partir d'un système d'exploitation modifié ou compromis (en utilisant un autre problème de sécurité). Maintenir le système d'exploitation à jour et sécurisé peut être suffisant même si le firmware est vulnérable.
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HLe problème a également été publié dans [Qualcomm's December 2022 Security Bulletin].
Le problème dépend d'une combinaison de matériel et de logiciel s'exécutant sur la cible concernée :
hyp du stockage interne).APCS_BOOT_START_ADDR_NSEC), qui n'est pas protégée par l'hyperviseur et est donc accessible par le noyau du système d'exploitation moins privilégié (par exemple Linux).Plusieurs autres chipsets possèdent probablement le matériel concerné (par exemple MSM8909 et MSM8953), mais ils ne disposent pas d'un firmware hyperviseur distinct qui pourrait être compromis.
Élévation de privilèges : Étant donné un noyau de système d'exploitation déjà compromis (par exemple Linux), le problème permet d'élever trivialement les privilèges au niveau de l'hyperviseur (EL1 -> EL2 sur ARM). Toute la mémoire gérée par l'hyperviseur peut être lue ou écrite. Cela brise l'isolation des différents domaines de sécurité ou machines virtuelles gérés par l'hyperviseur (le cas échéant, selon la configuration).
(Voir aussi : [An introduction to Access Control on Qualcomm Snapdragon Platforms])
Démarrage sécurisé : La plupart des appareils Qualcomm disponibles en production utilisent le démarrage sécurisé pour empêcher toute modification non autorisée du firmware. Le firmware est signé cryptographiquement et vérifié par la chaîne de démarrage. Le problème permet de modifier ou même de remplacer entièrement le firmware hyperviseur chargé à l'exécution à partir d'un système d'exploitation modifié (soit via le « déverrouillage du bootloader » officiellement pris en charge, soit via un autre exploit).
(Voir aussi : [Qualcomm Secure Boot and Image Authentication Technical Overview (v1.0)] et (v2.0))
Remarque : Le problème a été initialement découvert sur la plateforme Qualcomm Snapdragon 410 (MSM8916). Certaines des explications suivantes peuvent être spécifiques à MSM8916, par exemple :
Cependant, le concept général s'applique de la même manière à toutes les plateformes concernées.
L'architecture ARMv8-A 64 bits définit 4 niveaux de privilèges (« niveaux d'exception », EL). Il existe des niveaux distincts qui sont généralement utilisés pour les applications, les noyaux de système d'exploitation et un hyperviseur :
Le CPU bascule entre les niveaux lors des exceptions, par exemple en raison d'une interruption entrante. Il est également possible de basculer entre certains niveaux à l'aide d'instructions spéciales, telles que l'appel hyperviseur (hvc).
(Voir aussi : [AArch64 Exception model])
L'hyperviseur peut héberger une ou plusieurs machines virtuelles avec des noyaux de système d'exploitation distincts. Chaque machine virtuelle peut avoir sa propre vue de la mémoire à l'aide de la traduction de deuxième étape. Tous les accès mémoire d'une machine virtuelle passent par deux étapes de traduction : la première est gérée par le système d'exploitation (virtuel), tandis que la seconde est gérée par l'hyperviseur. La mémoire utilisée par l'hyperviseur ou d'autres machines virtuelles peut être masquée en l'omettant des tables de traduction.
(Voir aussi : [AArch64 virtualization], [AArch64 memory management])
Le firmware hyperviseur de Qualcomm s'exécute en EL2 et utilise la traduction de deuxième étape pour interdire l'accès à la mémoire de l'hyperviseur depuis le noyau du système d'exploitation principal s'exécutant en EL1 (généralement Linux). Notez que dans cette configuration, la traduction de deuxième étape est principalement utilisée pour la protection de la mémoire, sans traduction d'adresse. Le système d'exploitation principal a un accès direct à la plupart des composants matériels de l'espace d'entrée/sortie mappé en mémoire (MMIO), par exemple le contrôleur SD ou le sous-système de caméra. L'accès à la mémoire appartenant à l'hyperviseur/EL2 (hyp) et au moniteur sécurisé/EL3 (partie de tz) est restreint :
Le boot remapper n'est pas lié à la virtualisation : il est nécessaire lors du démarrage précoce d'un cœur de CPU. Sur cette plateforme matérielle, les cœurs de CPU commencent toujours leur exécution à l'adresse 0x0. Le boot remapper est un composant matériel supplémentaire intégré autour du CPU qui réadresse les premiers 64 ou 128 KiB (0x00000 - 0x20000) vers une région mémoire configurable.
Par défaut, le boot remapper pointe vers la ROM de démarrage (le premier code qui s'exécute au démarrage de l'appareil). Plus tard, le mappage est modifié afin que les autres cœurs de CPU démarrent immédiatement leur exécution dans le firmware EL3 (partie de tz) qui a été chargé dans la RAM :
Notez comment l'adresse accédée par le CPU (dans tz) est accessible via deux adresses physiques différentes : l'adresse réelle dans la RAM (0x8650xxxx) et l'adresse réadressée à l'aide du boot remapper (0x0000xxxx).
Il existe en réalité deux instances distinctes du boot remapper :
APCS_BOOT_START_ADDR_SEC (= 0x0b010004) mais uniquement en état sécurisé.APCS_BOOT_START_ADDR_NSEC (= 0x0b010008), même en état non sécurisé.Les deux instances du boot remapper peuvent être configurées à l'aide d'un registre mémoire qui contient l'adresse de base de la région réadressée et deux bits de configuration : REMAP_EN pour activer le réadressage et BOOT_128KB_EN pour réadresser les 128 premiers KiB au lieu de seulement 64 KiB.
(Voir aussi : [Qualcomm Snapdragon 410E Technical Reference Manual rev. D], pages 85 et 116)
En utilisant les connaissances des deux sections précédentes, l'idée de base est simple : utiliser le boot remapper pour contourner la protection mémoire (traduction de deuxième étape) de l'hyperviseur.
Le boot remapper ne fonctionne pas uniquement lors du démarrage du CPU. Il peut être utilisé à tout moment et offre un accès complet en lecture/écriture/exécution à la région réadressée. De plus, l'hyperviseur de Qualcomm ne semble pas empêcher le système d'exploitation de configurer et d'accéder à l'instance non sécurisée du boot remapper sur les appareils concernés (elle n'est pas protégée par la traduction de deuxième étape). Par conséquent, le problème est facile à exploiter en :
hyp commençant à l'adresse 0x8640xxxx), puis
La région réadressée peut être décalée dynamiquement (bloc par bloc) pour accéder à des régions mémoire plus grandes que les 64/128 KiB disponibles via le boot remapper. Il est également possible de l'utiliser pour désactiver entièrement la protection mémoire de l'hyperviseur (voir Preuve de concept).
Remarque : La même exploitation ne fonctionne pas pour le firmware du monde sécurisé (tz). Bien que le boot remapper permette de contourner la traduction de deuxième étape, la région mémoire tz dans la DRAM semble être protégée par un composant matériel supplémentaire (en dehors du CPU) qui bloque l'accès après son passage à travers le boot remapper :
La région mémoire tz n'est probablement accessible qu'en état sécurisé. L'exploitation ne permet que de contourner la protection mémoire de l'hyperviseur ; les autres mécanismes de sécurité du matériel restent en place.
Le boot remapper peut être utilisé pour désactiver complètement et remplacer le firmware hyperviseur d'origine à l'exécution, sans connaissance de la version du firmware. En particulier, il n'est pas nécessaire de recourir à la rétro-ingénierie pour obtenir les adresses mémoire des variables et des fonctions qui pourraient être modifiées. Il suffit de connaître la région mémoire approximative du firmware hyperviseur, par exemple à partir de la réservation mémoire dans le code Linux open source ou en lisant les en-têtes ELF du binaire du firmware hyperviseur (disponible dans la partition hyp du stockage interne).
L'idée générale est la suivante :
hvc) pour passer du système d'exploitation à l'hyperviseur (de EL1 à EL2).Le code qui implémente cela n'est pas long, mais implique un peu d'assembleur AArch64 de bas niveau et une interaction soigneuse avec les caches du CPU. Cependant, la question principale reste ouverte : où exactement le code shell doit-il être écrit, sans rendre le code spécifique à une version particulière du firmware hyperviseur ?
Lors d'un appel hyperviseur (ou de toute exception en général), l'exécution du CPU est forcée à une adresse mémoire spéciale : le vecteur d'exception. Les vecteurs d'exception font partie d'une table de vecteurs plus grande qui contient le code qui gère différents types d'exceptions, provenant des niveaux d'exception actuels ou inférieurs :
Chaque case représente un vecteur d'exception avec un espace pour 32 instructions assembleur. Cet espace n'est pas suffisant, ils contiennent donc généralement des instructions de branchement qui sautent ailleurs où il y a plus d'espace pour du code supplémentaire.
Les décalages sont relatifs au registre d'adresse de base des vecteurs (VBAR) qui définit l'adresse de base de la table de vecteurs pour chaque niveau d'exception. L'hyperviseur écrit l'adresse de base dans le registre CPU VBAR_EL2.
Un appel hyperviseur est une exception synchrone effectuée depuis un niveau d'exception inférieur (le noyau du système d'exploitation s'exécutant en EL1 vers l'hyperviseur en EL2). Si le noyau du système d'exploitation s'exécute en mode 32 bits, le CPU sautera donc vers VBAR_EL2+0x600, ou vers VBAR_EL2+0x400 en mode 64 bits. Après avoir utilisé le boot remapper pour écrire du code personnalisé à cette adresse et effectué un appel hyperviseur, le CPU commencerait à exécuter le code shell.
Malheureusement, VBAR_EL2 n'est pas lisible par le noyau du système d'exploitation s'exécutant en EL1. Il n'est lisible que depuis l'hyperviseur (EL2) lui-même ou un niveau supérieur. Néanmoins, cette connaissance rend beaucoup plus facile la devinette de l'adresse d'entrée par force brute : l'adresse de base de la table de vecteurs doit être alignée sur (un multiple de) sa taille (0x800 = 2 KiB). Cela signifie qu'il n'y a que 64 emplacements possibles dans une région de 128 KiB, ou 512 dans une région de 1 MiB :
Les cases rouges montrent tous les emplacements possibles vers lesquels le CPU pourrait sauter lors de l'appel hyperviseur. Écrire le code shell dans tous ces emplacements suffit pour que l'approche reste indépendante d'une version particulière du firmware (qui aura en réalité la table de vecteurs à une adresse précise).
Cela pourrait être encore amélioré : le boot remapper permet à la fois un accès en lecture et en écriture, il serait donc possible d'ajouter des heuristiques basées sur le code/les données existants lus depuis les emplacements mémoire. Il devrait contenir des instructions AArch64 (A64) valides et probablement des octets de remplissage répétés comme des NOP ou des instructions de branchement. (L'espace pour les 32 instructions par vecteur d'exception n'est souvent que partiellement utilisé, car il est plus facile de bifurquer vers une fonction appropriée avec plus d'espace.)
Le code de preuve de concept inclus dans ce dépôt est une modification du bootloader open source Little Kernel (LK) de Qualcomm pour la plateforme Snapdragon 410 (MSM8916/APQ8016), initialement destiné à être testé avec la carte de développement DragonBoard 410c. Tout cela a été choisi pour simplifier, le problème pouvant également être exploité à partir d'autres systèmes d'exploitation (tels que Linux), d'autres plateformes concernées et même d'appareils avec démarrage sécurisé - tant qu'il existe un moyen d'exécuter du code personnalisé dans le noyau du système d'exploitation.
Le code implémente l'approche décrite ci-dessus pour désactiver complètement l'hyperviseur en cours d'exécution puis le remplace par une version différente. Le nouveau « hyperviseur » ne prend en charge aucune machine virtuelle mais est capable de donner la Réponse à la question ultime sur la vie, l'univers et tout le reste à l'aide d'un simple appel hyperviseur :``` $ fastboot oem CVE-2022-22063 < waiting for any device > (bootloader) Hypervisor, what is the Answer to The Ultimate Question of (bootloader) Life, the Universe and Everything? (bootloader) Old hypervisor returned answer: -2 (bootloader) Old non-secure boot remapper base address: 0x100000 (bootloader) Setting boot remapper to hypervisor memory (0x86400000) (bootloader) Using boot remapper to copy shell code to hypervisor memory (bootloader) Copying to all possible vector tables (starting at 0x600) (bootloader) Calling shell code to disable running hypervisor (bootloader) Found old EL2 vector base address at 0x86404000 (bootloader) Copying new code directly to hypervisor memory (0x86400000) (bootloader) Hypervisor, what is the Answer to The Ultimate Question of (bootloader) Life, the Universe and Everything? (bootloader) New hypervisor returned answer: 42 OKAY [ 0.015s] Finished. Total time: 0.015s
### Tests
Le code de preuve de concept peut être construit et testé comme suit :```shell
$ git clone https://git.codelinaro.org/clo/la/kernel/lk.git -b caf_migration/LA.BR.1.2.9.1_rb1.5
$ cp CVE-2022-22063.c lk/platform/msm8916/
$ git apply LK.diff
# Build LK for msm8916 and flash it to device
$ fastboot oem CVE-2022-22063
...
Cependant, cette configuration ne convient qu'à la carte de développement DragonBoard 410c et à d'autres appareils sans démarrage sécurisé où le chargeur d'amorçage principal peut être facilement (et en toute sécurité) remplacé. Le code de ce dépôt est principalement fourni à titre de référence et non pour une utilisation/des tests faciles.
À l'avenir, il est prévu d'intégrer le code dans une nouvelle version de lk2nd, qui pourra être testée beaucoup plus facilement sur divers appareils sans remplacer le chargeur d'amorçage principal.
Selon Qualcomm, le problème a été corrigé en interdisant l'accès à la région du boot remapper via la traduction de niveau 2 (stage 2 translation). La configuration du boot remapper (le registre APCS_BOOT_START_ADDR_NSEC) est toujours accessible, mais les deux régions mémoire sont désormais bloquées :
Un autre correctif possible consisterait à protéger le registre APCS_BOOT_START_ADDR_NSEC dans l'hyperviseur. La région remappée pourrait rester accessible dans ce cas, puisque le système d'exploitation n'aurait aucun moyen de reconfigurer le boot remapper vers d'autres régions mémoire.
Selon Qualcomm, le problème a été particulièrement difficile à gérer car leurs outils d'automatisation habituels n'ont pas pu être utilisés. La plupart des problèmes qu'ils reçoivent sont des problèmes logiciels, où les appareils concernés peuvent être identifiés en vérifiant le code source. Pour ce problème, il a fallu vérifier manuellement à la fois le matériel et le logiciel (si la plateforme possède le registre problématique et si l'hyperviseur est vulnérable). Malheureusement, le fait de ne pas utiliser l'automatisation a également signifié que le problème n'a pas été automatiquement planifié dans un bulletin de sécurité. La deuxième prolongation de l'embargo a été demandée pour sensibiliser les clients au problème de sécurité et leur donner le temps de corriger leurs appareils. Ils travaillent à l'amélioration du processus pour éviter de tels problèmes à l'avenir.
Rapport et schémas CVE-2022-22063 © 2022 par Stephan Gerhold sont publiés sous la licence Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0). 
Le code de la preuve de concept (CVE-2022-22063.c) est fourni sous la licence MIT.