SmmExploit

Il s'agit d'un rapport et d'un exploit de CVE-2021-26943, la vulnérabilité d'élévation de privilèges locale du noyau vers SMM dans la version 303 du BIOS ASUS UX360CA. Le problème a été corrigé dans la version 304.

Description du problème

Résumé

Le BIOS UX360CA version 303 contient 3 modules vulnérables qui permettent à un attaquant disposant du privilège ring0 d'écraser une mémoire physique presque arbitraire, y compris la SMRAM, et d'exécuter du code arbitraire en mode SMM.

Ces modules peuvent être identifiés comme suit :

Ces modules proviennent d'AMI (fournisseur de BIOS) et peuvent être présents dans les BIOS d'autres OEM.

Vulnérabilités

Les modules vulnérables et les SMI correspondants sont : UsbRt (0x31), SdioSmm (0x40) et NvmeSmm (0x42). Tous ces gestionnaires SMI lisent l'adresse mémoire physique 0x40E pour obtenir une adresse sur laquelle travailler et écrivent un octet à cette adresse en cas d'erreur, même s'il s'agit de la SMRAM.

Par exemple, le gestionnaire SMI de SdioSmm se présente comme suit :

EFI_STATUS
EFIAPI
SdioSmm_SwSmi_40h(
  EFI_HANDLE  DispatchHandle,
  CONST VOID  *Context,
  VOID        *CommBuffer,
  UINTN       *CommBufferSize
  )
{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if ( EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0)))
    || userControlled->Offset0_FunctionCode >= 4 )
  {
    userControlled->Offset2 = 7;
  }
  else
  {
    // ...
  }
  return EFI_SUCCESS;
}

Ce problème semble identique à INTEL-SA-00057, qui est très bien décrit dans Aptiocalypsis. La version 303 du BIOS pour UX360CA n'inclut toutefois pas de correctifs pour ces derniers.

Exploitation

Cela permet à un attaquant ayant accès en écriture à la mémoire physique et à l'instruction OUT (c'est-à-dire les privilèges ring0) d'écraser le contenu de la SMRAM avec les étapes suivantes :

1. Assurez-vous que l'adresse physique 0x40e est à zéro (ce qui est très probablement déjà le cas)
2. Écrivez une adresse de la SMRAM, par exemple 0x88400000, à l'adresse physique 0x104
3. Déclenchez le SMI 0x40
4. 0x88400000+2 est mis à jour avec 0x7.

Cela peut être utilisé pour exécuter du code arbitraire en mode SMM comme suit :

1. Trouvez l'adresse de la System Management Service Table (SMST) dans la SMRAM, avec les étapes ci-dessous :
   1. Obtenez une plage d'adresses physiques pour le code d'exécution UEFI à partir du contenu de la valeur .Raw dans HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader Reserved
   2. Trouvez l'adresse de SMM_CORE_PRIVATE_DATA en recherchant la signature 'smmc' dans la plage d'adresses.
   3. SMM_CORE_PRIVATE_DATA contient le pointeur vers la SMST à l'offset 30h
2. Écrasez le pointeur vers la fonction SmmLocateProtocol à l'offset d0h de la SMST en utilisant la primitive d'écriture ci-dessus. La valeur est mise à jour à 0x07070707.
3. Écrivez le shellcode à l'adresse mémoire physique 0x07070707
4. Déclenchez un autre SMI qui appelle Smst->SmmLocateProtocol, comme le SMI 0xdf. Le shellcode à 0x07070707 est exécuté en mode SMM.

L'exécution de code arbitraire en mode SMM permettrait à un attaquant de contourner les mesures de sécurité du noyau et de l'hyperviseur telles que HVCI, comme démontré dans un autre rapport de vulnérabilité SMM, et d'établir une persistance en mettant à jour le contenu de la flash SPI (BIOS).

Preuve de concept (PoC)

Le projet de démonstration joint démontre une exploitation réussie et extrait le contenu des MSR uniquement accessibles en mode SMM ainsi que l'adresse physique de l'EPTP. Il modifie également le code de gestion des VM-exit CPUID de l'hyperviseur Hyper-V pour renvoyer une chaîne de nom de fournisseur d'hyperviseur modifiée.

La PoC a été testée sur Windows build 18362.1256, avec et sans HVCI activé.

Un enregistrement de l'exploitation réussie est disponible sur YouTube.

Instructions de test

1. Ouvrez demo.sln dans Visual Studio 2019
2. Compilez la solution en configuration Debug ou Release
3. Copiez le demo.sys compilé sur le système cible (par exemple, C:\users\user\desktop\demo.sys)

Sur le système cible,

1. Désactivez le Secure Boot dans le BIOS, puis redémarrez
2. Activez le mode de signature de test, puis redémarrez
   root@kitploit:~

   > bcdedit /set testsigning on
   

3. Créez le service pour charger demo.sys
   root@kitploit:~

   > sc create demo type= kernel binPath= C:\users\user\desktop\demo.sys
   

4. Démarrez DebugView et activez « Capture Kernel » dans le menu « Capture ».
5. Démarrez la démo
   root@kitploit:~

   > sc start demo
   

6. En cas de succès, DebugView affichera les valeurs des MSR liés au SMM.
   root@kitploit:~

   [+] ReportSmramRange: TSEG implied SMRAM: 0x88400000 - 0x88800000
   [-] ReportSmramRange: Exception occurred while accessing SMRR MSR : c0000096
   [+] FindSystemManagementServiceTable: SMM core found at 0x87f1b390 in RT Code
   [+] FindSystemManagementServiceTable: SMST found at 0x887fa710 in SMRAM
   [+] ExploitSmm: Patched SMST->SmmLocateProtocol in SMRAM
   [+] ExploitSmm: Placed SMM shell code
   [+] ExploitSmm: Triggered SMM exploit
   [+] DumpSmmExploitOuput: IA32_SMBASE             = 0x887cd000
   [+] DumpSmmExploitOuput: MSR_SMM_FEATURE_CONTROL = 0x1
   [+] DumpSmmExploitOuput: MSR_SMM_MCA_CAP         = 0xc00000000000000
   [+] DumpSmmExploitOuput: EPT pointer             = 0x10a72001e
   [+] DumpSmmExploitOuput: Patched Hv address      = 0x1004382f0
   [+] ExploitSmm: Successfully executed shell code in SMM. Failing DriverEntry to unload itself
   DriverEntry failed 0xc0000120 for driver \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\demo
   

Résolution

Le correctif consiste à éviter totalement d'utiliser le contenu contrôlé par l'utilisateur lorsqu'il pointe à l'intérieur de la SMRAM, comme indiqué ci-dessous.

{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if (!EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0))))
  {
    if (userControlled->Offset0_FunctionCode < 7 )
    {
      // ...
    }
    else
    {
      userControlled->Offset2 = 7;
    }
  }
  return EFI_SUCCESS;
}

Considérations

Absence de protection pour l'hyperviseur

Le correctif suit parfaitement les meilleures pratiques actuelles de l'industrie et empêche l'attaque par député confus qui conduit à la corruption de la SMRAM.

Notez toutefois qu'il ne prend pas en compte les régions mémoire de l'hyperviseur. Un attaquant connaissant l'adresse mémoire physique où l'hyperviseur est chargé ou qu'il utilise pourrait toujours demander au SMI d'écraser le code ou les données de l'hyperviseur et parvenir à corrompre l'hyperviseur.

Il s'agit d'un problème répandu, ancien, et même de niveau conceptuel.

Manque de défense en profondeur

Les problèmes signalés ont été résolus, mais certains aspects de la mise en œuvre d'une stratégie de défense en profondeur laissaient à désirer.

Par exemple, la table de pages SMM est mappée en identité avec des permissions complètes de lecture, d'écriture et d'exécution, et la fonctionnalité SMM_Code_Chk_En était indisponible. Cela rendait l'exploitation triviale. Je remarque également que le tampon de communication SMM n'est pas vérifié avec SmmIsBufferOutsideSmmValid() comme c'est le cas dans EDK2, bien que je n'aie pas trouvé de SMI exploitable.

Je pense que ces problèmes sont courants chez les OEM et dans de nombreuses versions de BIOS. Je signale que si vous utilisez d'anciens modèles d'un quelconque OEM, ce BIOS n'est probablement pas aussi sécurisé que vous pourriez le souhaiter, même avec ses dernières versions.

Améliorations

Ces problèmes ne disparaîtront pas très bientôt, mais je suis ravi de voir que l'industrie travaille sur une solution architecturale en réduisant les privilèges du SMM. Voici quelques-uns de ces travaux et articles que vous pouvez consulter :

• Platform Runtime Mechanism (PRM)
  • Présentation (Open-Source Firmware Conference 2020)
  • Spécification (uefi.org)
  • Implémentation (edk2-staging)
• Plongée en profondeur dans le System Management Mode : comment l'isolation SMM durcit la plateforme
• Configuration requise pour System Guard

Chronologie

Voici quelques points saillants.

• 2020-12-31 - J'ai signalé la vulnérabilité
• 2021-01-05 - ASUS a accusé réception du rapport
• 2021-01-18 - ASUS m'a envoyé la version corrigée du BIOS pour test
• 2021-01-20 - J'ai confirmé le correctif et répondu
• 2021-01-25 - ASUS a accusé réception de ma réponse
• 2021-03-21 - ASUS a rendu public le correctif, version 304
• 2021-03-29 - ASUS a publié une entrée d'avis de sécurité pour CVE-2021-26943

Enfin, un grand merci aux équipes d'ASUS pour avoir maintenu une communication étroite et transparente❤ Le processus global n'a pas été rapide mais plutôt sans frustration.