# Extensions de sécurité des CPU (x86, ARM) ## Rappel : Racine de confiance sur x86 (slide 4) - microprocessor/core dédiée sur lequel s’exécute un certain nombre de services - core de sécurité sont toujours actif – opération de maintenance sur la machine indépendamment de l’etat visible par l'utilisateur - boot guard s’exécute au début et restreint ce qui peut s’exécuter sur la machine - verification crypto vérifie le firmware - clef publique sert à prouver l’authenticité de l’UEFI - Boot Guard - Système de signature - Vérifier (cryptographiquement) que l’UEFI n’a pas été modifié - fTPM → Solution de TPM mais logicielle Depuis ~2008 toutes les machines disposent de Intel ME (tant qu’on a de la batterie ou branché, ce microprocesseur est allumé) *⇒ Ca on oublie parce que c’est pas facilement désactivable* ## **Extensions de sécurité des CPU (slide 7)** - Supervisor Mode Acess Protection - rend impossible en ring 0 d'**accéder** à des adresses users - géré par CR4 - On peut le désactiver pour pouvoir légitimement copier des donnés user - Supervisor Mode Execution Protection - En ring 0 on veut surtout pas **exécuter** de code dans l’espace utilisateur - géré par CR4 on en a parlé en [OS lin](https://notes.ar-lacroix.fr/s/MMFMtXfx8#) ``` An dernier ### **Memory Protection Extensions (slide 8)** *Pas trop utilisé d’après le prof* Le support est fait au niveau du compilo - protection contre les débordements de tampons (BOF) - jeu d’instructions supplémentaires : BNDCL… - nouveaux registres utilisés : BND… (registre de 128 bits) Les registres mentionnés permettent de stocker des bornes pour les buffer à vérifier. D’autre inst permettent de checker qu’une adresse reste comprise dans ces bornes. ``` ## **Contre-flow Enforcement Technology (slide 9)** Protection contre les attaque de type ROP/JOP - Shadow stack - Indirect Branch Tracking ### **CET : Shadow stack (slide 10)** = pile sauvegardant une copie du contrôle (addresses de retours notamment) Cette pile n’est pas en écriture. Utilisée lors du ret pour valider que ça n'a pas été altéré, si elle est modifiée le proc lève une exception #CP (Control Protection) ### **CET : Indirect Branch Tracking (slide 11)** Restreindre la liberté d’un attaquant sur le ROP en le forçant à rentrer au début des fonctions. Tout ce qui est appelable indirectement ne doit pouvoir se faire que sur un début de fonction *(cf OS lin je crois)* - Instrumentation par le compilateur : le compilateur doit placer des `ENDBR` au début de chaque fonction, après un branchement indirect le CPU passe dans un mode spécial et attend un `ENDBR` → Si on fait du ROP et qu’on saute au milieu d’une fonction, on ne va pas rencontrer cette instruction `ENDBR` et ça va chier dans la colle - L’instruction `ENDBR` est vue comme un `NOP` par les CPU ne supportant pas cette fonctionnalité, donc rétro-compatible ## **Software Guard Extension (SGX) (slide 12)** **Enclave** = une zone mémoire chiffrée et signée. Le CPU va déchiffrer à la volée le code. - solution de protection d’applications (ring 3) en intégrité et en confidentialité ### **INTEL SGX - Propriétés de sécurité recherchées (slide 13)** Le CPU est le seul composant où les données et le codes sont en clairs - Les app utilisant SGX comportent deux parties : - untrusted (tout le reste qu'on assume comme étant pas de confiance) - trusted (= enclave) - Seul le code l’enclave peut accéder aux data de l’enclave et uniquement sur le CPU (pas dans la mémoire ou dans les bus) - chaîne de sécu depuis le BIOS. **“Composants” en jeu :** - CPU - MEE (Memory encryption engine) - BIOS On va réserver des zones de DRAM pour les enclaves :  #### Ressources liées à ça : - [086.pdf (iacr.org)](https://eprint.iacr.org/2016/086.pdf) - [Blog d'un ancien TLS-SEC sur SGX](https://blog.quarkslab.com/overview-of-intel-sgx-part-1-sgx-internals.html) - [https://eprint.iacr.org/2016/086.pdf](https://eprint.iacr.org/2016/086.pdf) ## **Attaque sur les protections d’Intel (slide 18)** On peut contourner SMEP si on est motivé : - ROP dans le noyau pour désactiver ça au niveau de CR4 - plusieurs mapping (via pages virtuelles) pour en avoir une avec le flag qui nous arrange (et là boum) - ... (voir les slides) ## Protections sur ARM (copain d’Airbus) (slide 18) Chiffrement de la RAM pour protéger des VM parce qu’on peut pas créer des enclaves entre les VM. Très présent sur les tels. ``` l'an dernier ### G**estion des privilèges (slide 19)**  Sur ARM on n’a pas les ring, c’est Exceptions Levels : - 3 Niveaux : EL0,1,2,3 - supervisor call (équivalent à un syscall, passer du EL0 au EL1) - hypervisor call (protéger le noyau de lui-même, passer du EL1 au EL2) - secure monitor call (passer du EL1 / EL2 au EL3) - EL3 ⇒ Secure Monitor : niveau le plus privilégié - Transition secu → non secu : trust zone = zone exec secu appuyée par le matériel (registre CP15) Bit NS (”non-secure”) stocké dans le registre CP15 et accessible en écriture uniquement depuis le EL3 mais accessible en lecture depuis partout, même par les bus (la MMU peut savoir si un appel vient du mode secure ou non) ### **Gestion des privilèges (slide 20)** Y a plusieurs vecteurs d’exception genre depuis EL0 on tape dans le vecteur EL1 etc… Pour basculer de EL1 vers EL0 c’est le retour de l’exception (équivalent de iret) The cours be like : %2095c0b3acb1204cdca22404705452d2af/Untitled%203.png) des exceptions resultent toujours (ou la majorite des cas) en des elevations en privilege (de level). ### **Cas d’un smartphone android (slide 22)** TEE → Trust World sur android Quand on est root sur android on a pas tout donc il faut exploit d’autres vuln mais la surface d’attaque est limitée→ secure monitor, driver,… %2095c0b3acb1204cdca22404705452d2af/Untitled%204.png) Ex : quand on tape le PIN on a pas envie que le userland ait accès au code donc on se base sur cette ségrégation pour que seul le kernel ait accès à l’écran Mécanisme non écrit : le PAC (Pointeur Authentification Code ) → surtout utilisé sur IOS **Slide importante vu le temps passé dessus** ### **Gestions de la mémoire (23)** System Control Register → PAN Translation Control Register → granularité des pages Les attributs auxiliaires (AMAIR_ELx) sont laissés libres par ARM pour des implém customs. **Slide importante vu le temps passé dessus** ``` ## DMA/IOMMU and Co. ### IOMMU Inventé par IBM dans les années 80 pour protéger les accès DMA et introduit dans les processeurs x86 il y a une dizaine d'année. Appelés AMD-Vi, Intel VT-d. **Rappel DMA/IOMMU voir https://notes.ar-lacroix.fr/s/MMFMtXfx8#P%C3%A9riph%C3%A9riques** ### Attaques DMA - Code malveillant executant une requête DMA - Contrôleur permettant d'adresser le bus système - Exemple firewire : - utilisé par les ipod - pleins de failles notamment : c'est le périphérique qui peut initier le transfert PCIe → [PCI Express - Wikipedia](https://en.wikipedia.org/wiki/PCI_Express) ### Limites des IOMMU (Slide 31) Idée d'Attaque - usurper le source ID d’un périphérique ## MSI- Message Signaled Interrupts** (Slide 32)** Conversion d’un signal (requête d'écriture) PCIe avec une adresse particulière (0xfeeXXXXX) en une exception CPU. C’est le LAPIC qui fait cette traduction Le champ reserved du signal PCIe est important ### **MSI - Intérêt des MSI pour monter des attaques (34)** **Rappels accès mémoire périphérique (MMIO, PIO ...) : https://notes.ar-lacroix.fr/s/MMFMtXfx8#Plusieurs-modes-d%E2%80%99acc%C3%A8s** Infos utiles : - Les périphériques PCI disposent de registres pour gérer la configuration des MSI. - Un attaquant peut donc changer cette conf s’il a accès en I/O à ces registres. - le mode d'accès PCI utilise PIO (voir [rappels](https://notes.ar-lacroix.fr/s/MMFMtXfx8#Plusieurs-modes-d%E2%80%99acc%C3%A8s)) - La Réception de ping génère une interruption si on configure pour que MSI soit généré. 1ère possibilité d'attaque : injecter un syscall. ### **MSI - Injection de SIPI (36)** SIPI (startup inter-process interrupt) permet au BIOs d’activer tous les autres processeurs à part BSP (Boostrap Processor) qui est le premier à s'executer. Une SIPI est proche d’une MSI. Il “suffit” de modifier le reserved d’une MSI avec la value 111 pour faire exécuter du code par un proc ⇒ puisque ça lance un startup d’un proc. En supposant au préalable qu’on a écrit du code en mémoire grâce au PCI, le proc va gentiment exécuter le code.  ### **protections contre les Injection d'appel système** - Interrupt Remapping → chiant parce que ça modifie le format des MSI donc pas rétro-compatible - registre EOI doit être remis à 0 à la fin du traitement ### **Attaque injectin d'exception d'alignement** AC = exception qui stocke un code d'erreur sur la stack $\Rightarrow$ permet de confuser l'organisation de la pile. Normalement après un AC on dépile et on revient sauf que là on fait un AC sans error code donc tout est décalé  Attaque : - on met quelque chose dans RFLAGS:CS et non pas CS : RIP (cf au-dessus) - on injecte du code à cet endroit :::success une MSI permet d'envoyer une exception au CPU alors que nomalement il est le seul à pouvoir en lever. Et ça, c'est fort ::: ### Contre-mesure : Virtualisation des interruptuons Nouveau format qui rend les autres obsolètes. Permet de bloquer/traduire les interruptions matérielles (un peu comme de la DMA) ### **Accès DMA peer to peer et contre-mesures** Autres cibles que l'OS (sujet de ce cours): - Autre contrôleur - sur un routeur faisant du firewalling aller tapper dans un interface de l'autre côté permet de le bypass - utilise du DMA peer to peer ACS Source validation → En gros les extensions check que les IDs PCI sont cohérents (appartiennent à un contrôleur fils). ACS Upstream forwarding → permet de faire remonter une requête southbridge vers le northbridge ACS P2P Egress Control → Permet le blocage sélectif des communications P2P entre périphériques