Sécurité des mémoires mortes d’option sous macOS
Remarque : Les mémoires mortes d’option ne sont pas actuellement prises en charge sur les Mac avec puce Apple.
Sécurité des mémoires mortes d’option sur les Mac avec puce T2 Security d’Apple
Les appareils Thunderbolt et PCIe peuvent être équipés d’une « mémoire morte d’option » (OROM) connectée par câble à l’appareil. (Il ne s’agit habituellement pas d’une véritable mémoire morte, mais plutôt d’une puce réinscriptible sur laquelle est stocké le programme interne.) Sur les appareils UEFI, ce programme interne est généralement un pilote UEFI qui est lu par le programme interne UEFI, puis exécuté. Le code exécuté est censé initialiser et configurer le matériel à partir duquel il est récupéré afin que ce matériel puisse être utilisable par le reste du programme interne. Cette fonctionnalité est requise pour que le matériel tiers spécialisé puisse se charger et fonctionner au début du démarrage, par exemple pour démarrer à partir des matrices de disques RAID externes.
Cependant, puisque les OROM sont généralement réinscriptibles, si un assaillant écrase l’OROM d’un périphérique légitime, son code s’exécutera tôt au cours du processus de démarrage et pourrait modifier l’environnement d’exécution et violer l’intégrité de logiciels chargés par la suite. De même, si l’assaillant introduit son propre dispositif malveillant dans le système, il pourra également exécuter un code malveillant.
Sous macOS 10.12.3, le comportement des ordinateurs Mac vendus après 2011 a été modifié pour ne pas exécuter les OROM par défaut au moment du démarrage du Mac, à moins que l’utilisateur appuie sur une certaine combinaison de touches. Cette combinaison de touches assurait une protection contre les OROM malveillantes introduites involontairement dans la séquence de démarrage de macOS. Le comportement par défaut de l’utilitaire de mot de passe de programme interne a également été modifié pour que les OROM ne puissent pas s’exécuter lorsque l’utilisateur réglait un mot de passe de programme interne, même si la combinaison de touches était entrée. Cette procédure empêchait un assaillant physiquement présent d’introduire une OROM malveillante. Pour les utilisateurs qui doivent quand même exécuter des OROM lorsque la protection par mot de passe de programme interne est activée, les réglages par défaut peuvent être modifiés à l’aide de l’outil de ligne de commande firmwarepasswd sous macOS.
Sécurité des OROM par mise en bac à sable
Sous macOS 10.15, le programme interne UEFI a été mis à jour et comporte maintenant un mécanisme de mise en bac à sable et de retrait des privilèges des OROM. Le programme interne UEFI, qui exécute typiquement tout le code, y compris les OROM, au niveau de privilège maximal (« anneau 0 ») du processeur central, dispose d’un seul espace mémoire virtuel partagé pour l’ensemble du code et des données. L’anneau 0 est le niveau de privilège auquel le noyau macOS s’exécute, tandis l’anneau 3 est le niveau de privilège inférieur auquel l’app s’exécute. Le bac à sable des OROM retire les privilèges des OROM en ayant recours, comme le fait le noyau, à la séparation de mémoire virtuelle, puis en exécutant les OROM dans l’anneau 3.
Le bac à sable restreint encore davantage les deux interfaces que les OROM peuvent appeler (tout comme le filtrage des appels système dans les noyaux) et le type d’appareil comme lequel une OROM peut s’enregistrer (similaire à l’approbation des apps). L’avantage de cette conception est que les OROM malveillantes ne peuvent plus écrire directement sur la mémoire de l’anneau 0. Elles sont plutôt limitées à une interface de bac à sable très étroite et bien définie. Cette interface limitée réduit considérablement la surface d’attaque et force les assaillants à s’échapper du bac à sable avant d’élever leurs privilèges.