Contre-mesures envisageables

Afin de maîtriser les transferts de données directs entre contrôleurs d’entrées-sorties, nous pouvons nous appuyer sur différents mécanismes matériels existants.

Il est possible d’utiliser des contre-mesures matérielles implémentant le principe d’I/O MMU pour limiter les capacités d’interaction de pair-à-pair entre contrôleurs d’entrées-sorties, en particulier, ceux effectuant des transferts vers des adresses de l’espace mémoire. Dans les chipsets actuels, les composants implémentant une I/O MMU sont généralement placés dans le northbridge, en coupure entre le bloc formé par les contrôleurs d’entrées-sorties et la mé-moire centrale. L’agencement de ces composants dans l’architecture matérielle fait en sorte qu’ils voient transiter toute requête à destination de la mémoire centrale. De ce fait, ils la pro-tègent efficacement de tout accès arbitraire depuis un contrôleur d’entrées-sorties malveillant. En ce qui concerne les accès pair-à-pair, tout échange d’un contrôleur d’entrées-sorties situé dans le northbridge vers un contrôleur quelconque, qu’il soit dans le northbridge ou dans le

sou-28Nous rappelons que cette option permet d’utiliser certains périphériques USB (un clavier, une souris, un périphé-rique de stockage) au démarrage de la machine, bien avant que les contrôleurs USB ne soient initialisés par le système d’exploitation. Dans cette configuration, le BIOS (ou plus précisément la routine de traitement de la SMI) présente les claviers ou les souris USB au système d’exploitation comme étant des périphériques PS/2.

thbridge, transite obligatoirement par l’I/O MMU. Ainsi, ces échanges peuvent être contrôlés. Il en va de même pour la situation inverse, c’est-à-dire que toute communication à destina-tion d’un composant du northbridge est également maîtrisée. En revanche, lorsque les échanges n’impliquent que des composants situés dans le southbridge, l’I/O MMU n’est d’aucun secours. En effet, comme ces échanges s’effectuent en interne dans le southbridge, ceux-ci ne transitent à aucun moment dans l’I/O MMU. Pour cette raison, les requêtes ne peuvent pas être contrô-lées. Il est assez simple de vérifier cela sur les modèles de southbridge actuels en mettant en place un transfert pair-à-pair d’un contrôleur PCI vers d’autres contrôleurs du southbridge. Afin de contrôler entièrement les communications au sein du chipset, il serait envisageable d’avoir plusieurs I/O MMU (par exemple, une dans le northbridge et une dans le southbridge) placées au plus près des contrôleurs d’entrées-sorties et non au plus près de la mémoire centrale. Ce-pendant, cette solution rend encore plus complexe l’architecture matérielle résultante car il est nécessaire que les I/O MMUs se fassent mutuellement confiance : si une première I/O MMU a déjà effectué un contrôle d’accès sur une requête, la seconde I/O MMU peut ne pas vérifier une seconde fois le même accès. Dès lors qu’une des I/O MMUs est corrompue, la sécurité du système peut être remise en question.

Une autre manière de se protéger serait, par exemple, de rediriger systématiquement toutes les communications internes au southbridge vers le northbridge pour que celles-ci soient vérifiées par l’I/O MMU. Bien que cette solution puisse dégrader les performances, c’est vers cette lo-gique qu’évolueront les prochaines générations de chipsets grâce à l’extension Access Control Services définie dans le standard PCI Express. La mise en œuvre de ces extensions au sein du southbridge permet de définir des comportements différents vis-à-vis des communications entre contrôleurs d’entrées-sorties. Par exemple, la mise en place de l’ACS Upstream Forwarding au sein du southbridge implique de rediriger vers le northbridge toutes les requêtes internes au sou-thbridge. Ces requêtes peuvent être contrôlées dès lors qu’une I/O MMU est activée au sein du northbridge, puis être ré-aiguillées par la suite au southbridge. Il est également possible de bloquer systématiquement toute communication entre contrôleurs d’entrées-sorties connectés au southbridge en activant l’ACS P2P Egress Control.

3.4 Conclusion

La motivation principale qui nous a conduits à l’élaboration d’un modèle d’attaques est d’étudier les différentes manières pour un attaquant de mettre en défaut la sécurité d’un sys-tème informatique. Dans ce chapitre, nous avons instancié notre modèle d’attaques pour une architecture de système informatique particulière, l’architecture PC, sur laquelle s’appuie la majorité des systèmes informatiques d’aujourd’hui. Afin de mieux cerner les attaques par entrées-sorties qui nous intéressent particulièrement, nous avons commencé par rappeler quelques considérations techniques sur cette architecture matérielle. À partir de là, nous avons étudié un sous-ensemble de ces attaques : les attaques impliquant les contrôleurs d’entrées-sorties et qui exploitent leur capacité à gérer eux-mêmes leurs transferts de données. Nous avons alors fait apparaître la faiblesse structurelle à l’origine de ces attaques dans les architectures PC, à savoir le manque de contrôle d’accès sur les entrées-sorties. Dans le but de mieux nous rendre compte de celle-ci, nous nous sommes mis dans la peau d’un attaquant. Nous avons décrit la mise en œuvre de quelques attaques et nous avons présenté plusieurs contre-mesures à chacune d’elles. Jusqu’à présent, nous avons suivi une approche traditionnelle d’analyse d’un système in-formatique consistant à rechercher et identifier une vulnérabilité, développer une preuve de concept d’exploitation de la vulnérabilité pour finalement proposer des contre-mesures à

celle-3.4. Conclusion

ci. Cette approche s’est avérée fructueuse. En effet, elle nous a permis d’identifier plusieurs vulnérabilités qui sont susceptibles d’être exploitées sur les systèmes PC récents pour effectuer des attaques par entrées-sorties. Il convient, cependant, de nuancer ce bilan, compte tenu des difficultés liées à la mise en œuvre d’une approche d’analyse de vulnérabilités traditionnelle, quel que soit le système cible. Il s’agit, tout d’abord, d’une approche extrêmement chrono-phage. La conséquence immédiate à cela est que toute analyse ne peut généralement couvrir qu’une infirme partie du système cible. Par ailleurs, les résultats obtenus par cette approche varient généralement en fonction de l’expérience et de l’intuition de l’analyste. Afin de cou-vrir plus rapidement davantage de bogues potentiels (et éventuellement, davantage de vul-nérabilités potentielles) dans le matériel, il paraît essentiel d’adopter une démarche plus sys-tématique d’analyse de vulnérabilités. Cela fait l’objet du chapitre suivant. À cet effet, nous avons développé un contrôleur spécifique capable de générer tout type de trame sur les bus d’entrées-sorties. Entre autres, ce contrôleur va nous permettre d’obtenir les mêmes pouvoirs qu’un attaquant installant une porte dérobée dans le contrôleur qu’il conçoit ou dans lequel il a découvert une vulnérabilité le lui permettant.