Documente Academic
Documente Profesional
Documente Cultură
En vue de lobtention du
DOCTORAT DE LUNIVERSITE DE TOULOUSE
Delivre par :
Institut National des Sciences Appliquees de Toulouse (INSA de Toulouse)
Discipline ou specialite :
Domaine STIC : Reseaux, ecommunications,
Tel `
Systemes et Architecture
JURY
Rapporteurs : Olivier Festor INRIA Lorraine - LORIA
Jean-Louis Lanet Universite de Limoges
Examinateurs : Loc Duflot ANSSI
Mohamed Kaaniche LAAS-CNRS
eric
Fred Raynal QuarksLAB
Directeurs de Th`ese : Yves Deswarte LAAS-CNRS
Vincent Nicomette INSA de Toulouse
E cole doctorale :
E cole Doctorale Mathematique
Informatique Tel ecommmunications
de Toulouse (EDMITT)
Unite de recherche :
`
Laboratoire dAnalyse et dArchitecture des Systemes (LAAS-CNRS)
Directeurs de Th`ese :
Yves Deswarte et Vincent Nicomette
Remerciements
Les travaux prsents dans ce mmoire ont t effectus au sein du Laboratoire dAnalyse
et dArchitecture des Systmes du Centre National de la Recherche Scientifique (LAAS-CNRS).
Je remercie Messieurs Raja Chatila, Jean-Louis Sanchez et Jean Arlat, qui ont successivement
assur la direction du LAAS-CNRS depuis mon entre, pour mavoir accueilli au sein de ce
laboratoire. Je remercie galement Madame Karama Kanoun et Monsieur Mohamed Kaniche,
Directeurs de Recherche CNRS, responsables successifs de lquipe de recherche Tolrance aux
fautes et Sret de Fonctionnement informatique (TSF), pour mavoir permis de raliser ces
travaux dans cette quipe et pour avoir fourni un cadre propice au travail et aux changes qui
sont indispensables pour effectuer une thse dans les meilleures conditions.
Je remercie ensuite mes directeurs de thse, Monsieur Yves Deswarte, Directeur de Re-
cherche CNRS, et Monsieur Vincent Nicomette, Professeur des Universits lInstitut National
des Sciences Appliques (INSA) de Toulouse, pour mavoir guid durant ces trois annes de
thse. Ces travaux nauraient pas pu aboutir sans leur concours, leurs prcieux conseils, leur
sens de lcoute, leur soutien constant et leur disponibilit malgr un emploi du temps trs
(trs) charg. Au del de leurs qualits humaines, je tiens galement souligner leurs com-
ptences scientifiques et leur grande culture en scurit informatique dont jai pu bnficier.
Travailler avec eux durant ces trois annes fut trs apprciable, une exprience extrmement
enrichissante, mais surtout une grande chance. Merci eux pour la confiance quils mont tou-
jours tmoigne et, dans les quelques moments de doute, pour leur aide qui a contribu au bon
droulement des travaux prsents dans ce mmoire.
Jadresse galement mes sincres remerciements aux membres du jury qui ont accept de
juger mon travail. Je leur suis trs reconnaissant pour lintrt quils ont port mes travaux :
Yves Deswarte, Directeur de Recherche au LAAS-CNRS, Toulouse ;
Loc Duflot, Ingnieur de Recherche lANSSI, Paris ;
Olivier Festor, Directeur de Recherche lINRIA Lorraine, Nancy ;
Mohamed Kaniche, Directeur de Recherche au LAAS-CNRS, Toulouse ;
Jean-Louis Lanet, Professeur lUniversit de Limoges ;
Vincent Nicomette, Professeur lINSA de Toulouse ;
Frdric Raynal, Ingnieur de Recherche et Fondateur de QuarksLAB, Paris.
Je suis ravi et honor que Messieurs Olivier Festor et Jean-Louis Lanet aient accept dtre
les rapporteurs de cette thse, je les en remercie profondment. Les judicieux conseils quils
mont prodigus ont contribu amliorer la qualit du manuscrit que vous avez entre les
mains. Des remerciements particuliers vont Monsieur Mohamed Kaniche pour mavoir fait
lhonneur de prsider le jury en dpit de ses nombreuses obligations. Merci galement Mon-
sieur Adrian Perrig pour les discussions que nous avons eues sur plusieurs travaux qui sont
dcrits dans ce manuscrit. Cela aurait t un rel honneur de lavoir dans ce jury, mais il na
malheureusement pas pu se librer en raison de son emploi du temps extrmement charg.
Les remerciements suivants sadressent ric Lacombe qui, alors que jtais en projet de
fin dtudes, ma initi aux mandres du noyau Linux et a trac la voie aux travaux qui sont
prsents dans ce manuscript. Il ma prsent dautres facettes de la scurit informatique,
initi la programmation bas niveau et ma encourag poursuivre cette voie alors que je
venais du domaine des rseaux. Il ma galement permis de rencontrer et de cotoyer des gens
extrmement talentueux. Pour tout cela, je lui suis particulirement reconnaissant.
Je remercie galement tous les membres de lquipe de recherche TSF, permanents, docto-
rants, post-doctorants et stagiaires avec lesquels jai partag ces annes de travail. Merci tous
les membres de lquipe pour leur sympathie et leur soutien. Une mention particulire Yves
i
Crouzet pour les nombreux prts de matriels durant ma thse : puisse la Crou-CrouTech tou-
jours senrichir de petites bricoles toujours utiles et qui sont une mine dor pour les /a.kK/ ;
Graldine Vache-Marconato pour les nombreuses pripties (techniques et non techniques)
extraordinaires qui ont ponctu ma vie de doctorant ; et ric Alata pour mavoir appris
persverer davantage face un problme (trs) difficile et pour mavoir continuellement en-
courag terminer le Challenge SSTIC avec lui. Enfin, jai partag toute cette thse avec ceux
qui ont t mes collgues de bureau (Anthony, Maxime) et ceux qui le sont encore (Miruna,
Miguel et Rim), qui ont toujours t un support pour moi. En particulier, je dois beaucoup
Miruna qui a accept la pnible tche de relire mes articles ainsi que mes chapitres de thse
pour chasser toutes les coquilles qui restaient. Elle a normment contribu la qualit de ce
manuscrit.
Je noublie bien sr pas de remercier lensemble des services techniques et administratifs du
LAAS-CNRS, qui contribuent activement la vie du laboratoire. Je tiens remercier particu-
lirement Matthieu Herrb, Ingnieur de Recherche, pour sa disponibilit permanente pour des
runions durant lesquelles il nous a fait profiter de son savoir technique incommensurable, de
son exprience en programmation bas-niveau. Matthieu, sache que tu as t une relle source
dinspiration et de motivation pour moi.
Mes remerciements sadressent galement lensemble des personnes qui mont tendu
leurs mains au cours ma thse et mme aprs cette aventure tumultueuse. Pour commencer,
un grand Merci au comit dorganisation et au comit de programme de SSTIC pour mavoir
laiss prsenter mes travaux trois annes de suite ce symposium francophone de qualit sur
la scurit informatique. Merci, ensuite, lensemble des membres de lANSSI avec qui jai pu
converser et avec qui jai eu la chance de travailler. Jai normment apprci les changes au
niveau scientifique et humain. Je souhaite que la synergie qui sest cre perdure au del des
trois annes qui viennent de scouler et que nous tirions de nombreux enseignements de nos
comptences et de nos expriences respectives. Merci galement Ludovic M et Carlos Agui-
lar Melchor pour mavoir ouvert les portes du monde acadmique aprs ma thse, puis Fabien
Perigaud, Florent Marceau, Arnauld Mascret et Frdric Raynal, pour les portes du monde
de lindustrie. Merci tous pour la confiance que vous mavez accorde, et je renouvelle ma
volont davoir lopportunit de collaborer avec chacun de vous dans lavenir.
Je remercie galement Vincent Nicomette, Slim Abdellatif, ric Alata, Daniela Dragomi-
rescu, Christophe Chassot et lensemble du corps enseignant du dpartement DGEI de lINSA
de Toulouse, qui mont fait confiance et permis de faire de lenseignement durant la prpara-
tion de cette thse. Ces heures passes prparer ou animer des cours mont permis de dterrer
des enseignements enfouis dans mes (bons) souvenirs dlve ingnieur.
Je ne peux pas ne pas mentionner tous mes amis qui mont soutenu, conseill, aid et dis-
trait tout au long du priple qui ma amen l jen suis aujourdhui : Adrien, Alioune, Anja,
Arnaud, Denis, Erwan, Estelle, Farid, Guillaume, Houssen, Julien, Karim, Karine, Laetitia, Lau-
rence, Laurie, Lidao, Livantsoa, Malik, Nicolas, Princy, Priscilia, Rmy, Shreya, Sophie, Stephen,
Timothe et tous ceux que joublie forcment. Merci tous pour leur soutien, leur humour et
tous ces moments inoubliables passs ensemble.
Enfin, mes penses vont bien entendu lensemble de ma famille : mes parents, mes frres,
mes oncles et mes tantes, mes cousins et mes cousines. Je leur dois mon envie daller toujours
plus loin dans les activits que jentreprends. Merci eux pour leur soutien inconditionnel dans
toutes les preuves qui mont amen jusquici. Je ne peux conclure sans remercier Jieyu, avec
qui jai dbut cette aventure quest la thse de doctorat, pour avoir t toujours mes cts et
pour mavoir soutenu en permanence.
ii
Pass on what you have learned, Luke. There is. . . another. . . Sky. . . walker.
Master Yoda, Star Wars : Episode VI Return of the Jedi, 1983
An invasion of armies can be resisted, but not an idea whose time has come.
Victor Hugo, Histoire dun crime, 1852
iii
iv
Table des matires
Introduction gnrale 1
1 Contexte et problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Prsentation de nos travaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
v
Table des matires
vi
Conclusion gnrale 95
1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
2 Travaux futurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
2.1 Formalisation mathmatique du modle dattaques propos . . . . . . . . 97
2.2 tude des attaques par entres-sorties pour dautres systmes . . . . . . . 97
2.3 Dtection et prvention des attaques par entres-sorties . . . . . . . . . . 98
Annexe B Preuve de concept dattaque par accs pair--pair sur une carte graphique 105
B.1 Architecture dune carte graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
B.2 Scnario dattaque considr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
B.3 Rsultats obtenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Bibliographie 117
vii
Table des matires
viii
Table des figures
ix
Table des figures
x
Liste des tableaux
xi
Liste des tableaux
xii
Introduction gnrale
1 Contexte et problmatique
Aujourdhui, les systmes informatiques occupent une place prdominante dans les en-
treprises, dans les administrations et dans le quotidien des particuliers. Ce phnomne a t
catalys, entre autres, par lessor de lInternet qui sduit chaque jour de plus en plus dinter-
nautes par les nombreux avantages et la diversit des services rendus accessibles. Ils peuvent
ainsi bnficier moindre cot de moyens de communication rapides, partager des ressources
de traitement et de stockage de grandes capacits (Cloud Computing), faciliter les changes com-
merciaux et financiers (e-Commerce, e-Banking), fournir et utiliser de nombreux services en ligne
(e-Administration, e-Health, e-Learning, etc.), participer des communauts virtuelles et des r-
seaux sociaux, se divertir (e-Gaming, e-Television, etc.) et, plus gnralement, partager et accder
linformation [Deswarte et Gambs 12]. Notre dpendance croissante aux systmes informa-
tiques dans divers aspects de la vie quotidienne et leur omniprsence soulvent invitablement
des questions quant leur scurit et la scurit des informations qui leurs sont confies.
En dpit des efforts consquents qui ont t investis depuis un certain nombre dannes
pour tenter dendiguer les problmes de scurit, force est de constater que le nombre de vul-
nrabilits dans les systmes informatiques et, de surcrot, les activits malveillantes qui es-
saient et qui russissent les exploiter, continuent rgulirement se multiplier. Les donnes
statistiques fournies par Kaspersky Lab [Namestnikov 12], spcialis dans la scurit des sys-
tmes dinformation, tendent confirmer ce phnomne. Notamment, il dnombrait pas moins
de 946 393 693 attaques russies au travers de lInternet en 2011 contre seulement 580 371 937
en 2010, reprsentant ainsi une progression denviron 39%. Cet chec est justifi, en partie, par
la complexit toujours croissante des systmes informatiques actuels. En effet, pour rduire
les cots de dveloppement, ces systmes utilisent de plus en plus de composants sur tagre
(ou COTS pour Commercial Off-The-Shelf), mme pour des applications plus ou moins critiques.
Ces composants peuvent tre des matriels (microprocesseurs, chipsets 1 , priphriques, etc.),
des programmes de base (systmes dexploitation, outils de dveloppement ou de configu-
ration, etc.), des programmes gnriques (systmes de gestion de base de donnes, serveurs
Web, etc.) ou ddis des fonctions plus spcifiques (pare-feux, dtection dintrusions, super-
vision, etc.). Les composants gnriques, de par la multiplicit de leurs utilisations possibles,
sont souvent beaucoup plus complexes que ce qui est vraiment utile pour un systme particu-
lier. Cette complexit les fragilise vis--vis de la scurit. En effet, il est pratiquement impossible
de les vrifier parfaitement, cest--dire de garantir, dune part, labsence de bogues et, dautre
part, labsence de fonctions caches. Par consquent, des attaquants (ou pirates informatiques)
peuvent profiter de cette situation pour russir pntrer dans ces systmes et utiliser les res-
1
Le chipset est un ensemble de puces lectroniques charg dinterconnecter les processeurs dautres composants
matriels tels que les mmoires, les cartes graphiques, les cartes rseau, les contrleurs de disque, etc.
1
Introduction gnrale
2
2. Prsentation de nos travaux
par la suite Trojan.Mebromi 3 , est capable de reprogrammer les BIOS du constructeur OEM
(Original Equipment Manufacturer) Award Software afin dy adjoindre une ROM dextension
malveillante. Celle-ci a pour fonction dassurer, dune part, sa persistance et, dautre part, de
camoufler ses activits malveillantes vis--vis de toutes solutions logicielles antivirales. Cest
dailleurs une caractristique importante des attaques par entres-sorties : puisquen gnral,
elles nutilisent, pour leur mise en uvre, ni le processeur ni les mmoires qui lui sont acces-
sibles, elles sont extrmement difficiles dtecter par des logiciels de scurit excuts par les
processeurs (anti-virus, anti-spyware, anti-rootkit, etc.).
En dpit des nombreuses tudes sur le sujet, nous constatons que cette classe dattaques
est encore mconnue ce jour et certaines interrogations restent sans rponse. Quelles sont
les actions malveillantes quun attaquant peut esprer effectuer dans un systme informa-
tique sil parvient, par exemple, implanter une porte drobe ou un cheval de Troie dans
un composant matriel ? Une telle implantation peut tre ralise dlibrment par le fabri-
cant ou alors son insu lors de la conception du composant matriel (en altrant le com-
pilateur qui produit le masque de la puce), lors de sa fabrication (en altrant le masque de
la puce) ou en vie oprationnelle (en altrant son firmware). Ce sont des menaces qui, aujour-
dhui, sont dautant plus plausibles que des quipements de rseau peuvent tre conus par
des pays hostiles pour intgrer des fonctions caches pour prendre le contrle de rseaux ad-
verses. Rcemment, la commission de renseignement de lU.S. House of Representatives a pu-
bli un rapport [Rogers et Ruppersberger 12] qui montre linquitude grandissante du gouver-
nement amricain sur les portes drobes qui pourraient tre prsents dans les quipements
fabriqus par des pays hostiles. Cette inquitude a t partage par de nombreux pays dont
la France [Bockel 12]. Vis--vis de telles menaces, jusqu quel point les contre-mesures mat-
rielles que lon peut mettre en uvre pour renforcer la scurit des systmes informatiques
rcents sont-elles efficaces ? Quels choix dimplmentation (pour les plates-formes matrielles)
pourraient pallier les insuffisances des contre-mesures actuelles et rduire les risques lis
lexploitation dun tel vecteur dattaque ? Cest ces questions que tentent de rpondre nos
travaux.
Nous commenons ce manuscrit par un premier chapitre rappelant la terminologie et les
concepts de base associs la scurit des systmes informatiques. Ceci nous permet alors de
prsenter les attaques qui mettent en dfaut la scurit de ces systmes et de discuter des faons
diffrentes de les classer que nous retrouvons dans la littrature. Les classifications existantes
ne mettent cependant pas suffisamment laccent sur les caractristiques des attaques que nous
considrons pour nos travaux. Aussi, nous nous proposons de les prciser en dcomposant
les attaques en squences dactions lmentaires dont certaines sont malveillantes. Lobjectif
poursuivi dans cette caractrisation est didentifier lensemble des attaques lmentaires sur
lesquelles sont bases les attaques relles, afin de mettre en vidence ensuite quelques contre-
mesures que lon peut mettre en uvre pour sen protger.
Le deuxime chapitre dtaille notre dmarche pour tablir un modle dattaques gnral
pour les systmes informatiques. partir dune reprsentation fonctionnelle dun systme in-
formatique, nous construisons un graphe de flux de donnes entre les diffrents composants
du systme. En appliquant ensuite ce graphe un ensemble de rgles dduites des attaques
lmentaires identifies dans le chapitre prcdent, nous dduisons les squences dattaques
qui sont possibles dans un systme informatique. Parmi celles-ci, nous retrouvons celles qui
nous intressent pour nos travaux : les attaques par entres-sorties.
Dans un troisime chapitre, nous instancions le modle dattaques prcdemment tabli
3
Une analyse approfondie du fonctionnement de ce maliciel a t publie dans [Giuliani 11].
3
Introduction gnrale
pour un systme informatique typique. Avec le point de vue de lattaquant, nous mettons en
uvre notre modle au travers de quelques exemples dattaques par entres-sorties pour des
systmes informatiques organiss autour de larchitecture PC. Ces exemples prsentent, entre
autres, diffrentes faons dexploiter le mcanisme de bus mastering prsent dans la majorit des
contrleurs dentres-sorties sur tagre. Il sagit dune fonctionnalit matrielle lgitime leur
permettant de prendre temporairement le rle de matre sur les bus dentres-sorties afin def-
fectuer des transferts de donnes avec la mmoire centrale (accs direct la mmoire) ou avec
dautres contrleurs (accs pair--pair), dchargeant ainsi le processeur principal des trans-
ferts dentres-sorties. Ces attaques nous permettent alors dintroduire les contre-mesures ma-
trielles qui ont t proposes (et pour certaines implmentes dans le chipsets rcents), puis de
discuter de certaines insuffisances que nous avons identifies au sein de celles-ci.
Finalement, dans notre dernier chapitre, nous tudions de manire plus dtaille les at-
taques identifies dans notre modle. Dans cette approche, nous explorons lide dappliquer
aux composants matriels les techniques de recherche de vulnrabilits gnralement utilises
pour les composants logiciels. Nous nous sommes plus particulirement intresss aux tech-
niques de fuzzing appliques au dnominateur commun tous les composants matriels,
savoir les bus dentres-sorties. Afin de pallier les difficults lies lutilisation dun contrleur
dentres-sorties sur tagre pour injecter des fautes sur les bus dentres-sorties, nous avons
mis au point notre propre contrleur dentres-sorties en utilisant les technologies de logique
programmable. Ce dmonstrateur, que nous avons nomm IronHide, a t conu dans lop-
tique dtre entirement programmable et de pouvoir gnrer des requtes quelconques, des
requtes valides mais aussi et surtout des requtes invalides, sur les bus dentres-sorties.
Nous concluons ce manuscrit par une synthse de nos contributions et prsentons quelques
perspectives nos travaux. Parmi ces perspectives, nous projetons de raffiner davantage notre
modle dattaques. Nous discutons galement dautres cas dutilisation que nous avons envisa-
gs pour le contrleur dentres-sorties IronHide, la fois comme un outil danalyse dattaques
par entres-sorties mais galement comme un moyen de protection contre ces mmes attaques.
4
Chapitre 1
Les enjeux de la scurit des systmes informatiques sont primordiaux, tant donn les
pertes humaines, conomiques et financires importantes que peut engendrer la compromis-
sion de ces systmes. Comprendre et caractriser les attaques informatiques nous parat alors
essentiel afin den dduire un modle sur lequel il soit possible de sappuyer, dune part, pour
tudier ces attaques et ventuellement en identifier dautres qui sont encore inconnues, et
dautre part, pour concevoir puis mettre en place des mcanismes visant protger le systme
contre ces attaques. Les travaux dcrits dans ce manuscrit se concentrent plus particulirement
sur ce premier objectif. Dans ce chapitre, nous essayons didentifier les lments du systme
informatique sur lesquels reposent une attaque.
Dans notre dmarche, nous repartons de la terminologie et des concepts de base associs
la sret de fonctionnement et la scurit des systmes, les deux concepts tant troitement
lis (section 1.1). Cette introduction permet, entre autres, de prciser les trois proprits confi-
dentialit, intgrit et disponibilit sur lesquelles repose la scurit dun systme. Nous nous
intressons ensuite aux actions qui cherchent mettre en dfaut ces proprits pour un systme
particulier : le systme informatique. La caractrisation de ces attaques nous a permis dobtenir,
en section 1.2 , une classification des actions malveillantes selon diffrents niveaux dabstrac-
tion, sur laquelle reposent les chapitres suivants. Finalement, en section 1.3, nous portons une
attention particulire aux mthodes ainsi quaux techniques visant prvenir lintroduction de
vulnrabilits et les liminer aussi bien lors du dveloppement du systme informatique que
lors de son fonctionnement en vie oprationnelle.
5
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
La sret de fonctionnement dun systme est la proprit qui permet ses utilisateurs de pla-
cer une confiance justifie dans le service que le systme leur dlivre [Aviienis et al. 04, Laprie 04].
Cette proprit englobe trois notions diffrentes (cf. figure 1.1) : ses attributs, les proprits
complmentaires qui la caractrisent ; ses entraves, les circonstances indsirables mais non-
inattendues qui sont causes ou rsultats de la non-sret de fonctionnement ; ses moyens, les
mthodes et techniques qui cherchent rendre un systme capable daccomplir correctement
sa fonction et donner confiance dans cette aptitude.
6
1.1. Scurit des systmes informatiques
Disponibilit
Fiabilit
Attributs
Scurit-innocuit
Scurit-immunit
Fautes
Sret de
Entraves Erreurs
fonctionnement
Dfaillances
Prvention de fautes
Tolrance aux fautes
Moyens
limination des fautes
Prvision des fautes
par rapport la capacit du systme tre prt dlivrer le service, la sret de fonction-
nement est perue comme la disponibilit (en anglais, availability),
par rapport la continuit de service, la sret de fonctionnement est perue comme la
fiabilit (en anglais, reliability),
par rapport lvitement de consquences catastrophiques sur lenvironnement, la sret de
fonctionnement est perue comme la scurit-innocuit (en anglais, safety),
par rapport la prservation de la confidentialit, de lintgrit et de la disponibilit des infor-
mations, la sret de fonctionnement est perue comme la scurit-immunit (en anglais,
security).
7
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
faute
^
erreurs
systme 1 systme 2 systme 3 utilisateur
dfaillance
tme par un concepteur malveillant, ou en phase oprationnelle par linstallation dun compo-
sant logiciel ou matriel contenant un cheval de Troie ou par une intrusion. La dfinition dune
intrusion est troitement lie aux notions dattaque et de vulnrabilit. Une attaque est une
faute dinteraction malveillante visant violer une ou plusieurs proprits de scurit. Cest
une faute externe cre avec lintention de nuire. Une vulnrabilit est une faute accidentelle ou
intentionnelle (avec ou sans volont de nuire) dans la spcification des besoins, la spcification
fonctionnelle, la conception ou la configuration du systme, ou dans la faon selon laquelle il
est utilis. La vulnrabilit peut tre exploite pour crer une intrusion. Une intrusion est une
faute malveillante interne, mais dorigine externe, rsultant dune attaque qui a russi ex-
ploiter une vulnrabilit. Elle est susceptible de produire des erreurs pouvant provoquer une
dfaillance vis--vis de la scurit, cest--dire une violation de la politique de scurit du sys-
tme.
8
1.1. Scurit des systmes informatiques
1.1.3.1 Confidentialit
La confidentialit est la proprit quune information ne soit pas rvle des utilisateurs non
autoriss la connatre. Cela signifie que le systme informatique doit empcher les utilisateurs
de lire une information confidentielle sils ny sont pas autoriss, et empcher les utilisateurs
autoriss lire une information de la divulguer dautres utilisateurs non autoriss. Cette
seconde condition est souvent nglige car plus difficile assurer.
Un incident survenu au Massachusetts Institute of Technology en 1965 illustre une atteinte
typique contre la confidentialit. Lors de son discours pour le prix Alan Turing, F. J. Cor-
bat [Corbat 91] raconta que cet incident a provoqu laffichage de la liste de tous les utili-
sateurs et de leurs mots de passe en clair sur tous les terminaux du systme temps partag
du campus. Cette msaventure tait la consquence dune faute de conception et dune erreur
doprateur : le systme tait conu pour navoir quun seul oprateur, et donc un seul tam-
pon avait t mis sa disposition pour mettre jour des fichiers. Ce jour-l, deux oprateurs
mettaient jour en mme temps deux fichiers, dune part, le fichier de la liste des utilisateurs
(contenant galement leurs mots de passe en clair) pour y ajouter un nouvel utilisateur et,
dautre part, le fichier du message de bienvenue qui saffiche sur les terminaux en dbut de
session. Quand ce dernier fichier a t crit, le tampon unique contenait la liste des utilisateurs
qui a donc remplac le message de bienvenue.
4
Ce sens est gnralement choisi par les spcialistes de laudit de scurit lorsquils doivent valuer les risques lis
linformatique pour une entreprise.
9
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
1.1.3.2 Intgrit
Lintgrit est la proprit quune information ne soit pas altre. Cela signifie que le sys-
tme informatique doit empcher une modification indue de linformation, cest--dire une
modification par des utilisateurs non autoriss ou une modification incorrecte par des utilisa-
teurs autoriss, sassurer quaucun utilisateur ne puisse empcher la modification lgitime de
linformation, faire en sorte que linformation soit cre et, enfin, vrifier quelle est correcte. Il
convient de prciser que le terme modification doit tre entendu ici au sens large, comprenant
la fois la cration dune nouvelle information, la mise jour dune information existante, et
la destruction dune information.
Un virus informatique [Cohen 86, Filiol 03] est un exemple intressant datteinte contre lin-
tgrit car une infection par ce type de parasites informatiques implique ncessairement une
perte dintgrit dans le systme. Un virus est un segment de programme qui, lorsquil sex-
cute, se reproduit en sadjoignant un autre programme. Lanalogie avec les virus biologiques
tient leur comportement : un virus biologique ne peut se reproduire par lui-mme ; pour se
reproduire, il modifie le code gntique des cellules quil infecte pour que les cellules ainsi
modifies produisent des copies du virus ; de la mme faon, un virus informatique ne peut
tre activ (et donc se reproduire) que par lexcution dun programme porteur du virus. La
propagation du virus constitue alors une attaque contre lintgrit des programmes, lexcu-
tion du virus pouvant, par ailleurs, avoir dautres effets qui peuvent tre des attaques contre la
confidentialit, la disponibilit et lintgrit des donnes.
1.1.3.3 Disponibilit
La disponibilit est la proprit quune information soit accessible lorsquun utilisateur au-
toris en a besoin. Cela signifie que le systme informatique doit fournir laccs linformation
pour que les utilisateurs autoriss puissent la lire ou la modifier, et faire en sorte quaucun uti-
lisateur ne puisse empcher les utilisateurs autoriss daccder linformation. Pour reprendre
lexemple de lincident survenu au Massachusetts Institute of Technology, si, par hasard, linverse
stait pass, savoir la copie du message de bienvenue dans le fichier de la liste des utilisa-
teurs, plus personne naurait pu se connecter au systme, et cet t une atteinte grave la
disponibilit. Il convient de noter que la disponibilit implique lintgrit, puisquil ne servirait
rien de rendre accessible une information fausse. La disponibilit implique galement des
contraintes plus ou moins prcises sur le temps de rponse du service fourni par le systme
informatique. Une atteinte contre la disponibilit est souvent appele dni de service.
La scurit peut parfois reprsenter dautres caractristiques, telles que lintimit (pour tra-
duire le terme anglo-saxon privacy), lauthenticit, lauditabilit, la prennit, lexclusivit, etc. Ces
proprits de scurit peuvent tre exprimes par les proprits de disponibilit, dintgrit et
de confidentialit appliques des donnes et des mta-donnes.
Les proprits de scurit que nous venons de rappeler sappliquent la notion gnrale
de systme. Dans la suite de ce manuscrit, nous appliquons ces proprits aux systmes infor-
matiques que nous dfinissons comme suit. Un systme informatique est la composition de deux
systmes, lun matriel et lautre logiciel, organiss dans le but de remplir une fonction ou une
10
1.2. Classification des attaques sur les systmes informatiques
11
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
un systme externe qui en dpend, etc.). De la dfinition que nous avons tablie pour un sys-
tme informatique, nous conjecturons que ces attaques lmentaires peuvent intervenir plu-
sieurs niveaux dabstraction du systme :
soit sur les systmes logiciels, plus prcisment sur leur tat ou leur structure ;
soit sur ltat ou sur la structure des systmes matriels, lesquels impactent les systmes
logiciels qui en dpendent ;
soit sur les canaux de communication par lesquels il interagit avec dautres systmes ;
soit sur son environnement, par la mise en uvre dattaques par des canaux auxiliaires.
Partant de cette hypothse, nous avons ensuite identifi les vecteurs dattaque possibles
pour chaque niveau dabstraction. La classification obtenue est reprsente sur la figure 1.3. Il
est opportun de remarquer, ds prsent, quune mme technique dattaque peut tre utilise
pour nuire diffrents niveaux dabstraction du systme informatique. Dans ce cas, cette tech-
nique peut tre incluse dans plusieurs classes distinctes dans la mesure o elle porte sur des
informations de nature diffrente. Par exemple, la majorit des vecteurs dattaque considrs
dans cette classification peuvent tre mises en uvre par de linjection de fautes. Bien videm-
ment, il peut tre envisag daffiner la classification que nous proposons afin de prciser toutes
les techniques dattaques qui sont susceptibles dtre utilises pour chaque niveau dabstrac-
tion, mais une telle granularit ne ferait quaugmenter la complexit du modle propos au
chapitre 2 sans rellement y apporter de bnfice.
Ce vecteur dattaque se fonde sur le fait que laccs plusieurs fonctionnalits logicielles
lgitimes, potentiellement dangereuses pour la scurit du systme informatique, ne sont pas
suffisamment restreintes par la politique de scurit mise en uvre par le systme dexploi-
tation. Ces fonctionnalits logicielles peuvent alors servir des objectifs malveillants et por-
ter ventuellement atteinte la scurit de composants du systme situs dautres niveaux
dabstraction. Cette partie prsente succinctement quelques unes dentres elles. Bien que les
exemples que nous nonons concernent majoritairement les systmes dexploitation de type
Unix, nous prcisons que ces fonctionnalits logicielles (et donc, des vecteurs dattaque simi-
laires) existent dans dautres types de systmes dexploitation (Windows, BSD, etc.).
Dans les systmes dexploitation de type Unix, lappel systme ptrace() 6 fait partie des
nombreuses fonctionnalits logicielles lgitimes que les attaquants dtournent pour perptrer
des attaques. Un programme peut, au travers de cet appel systme, accder (en lecture et en
6
Le nom de cet appel systme est issu de la contraction de process trace (littralement, trace dun processus).
12
1.2. Classification des attaques sur les systmes informatiques
Niveaux dabstrac-
Objet de lattaque Vecteurs dattaque
tion du systme
criture) lintgralit de la mmoire (les registres du processeur inclus) dun autre proces-
sus, cest--dire un autre programme en cours dexcution. Le fonctionnement de nombreux
outils, tels que le debogueur gdb, les outils de trace de programmes strace et ltrace ainsi
que plusieurs outils danalyse structurelle de code reposent sur cet appel systme. Malheureu-
sement, il nest pas ncessaire pour un attaquant dacqurir des privilges particuliers pour
lutiliser : les permissions requises sont identiques celles ncessaires lenvoi dun signal
un autre processus. Il peut alors aisment mettre en uvre cette technique contre un autre
processus 7 et oprer des actions malveillantes diverses (injection de code, modification du
contexte dexcution, etc.). [Bareil 06] dtaille, plusieurs exemples et codes-sources lappui,
quelques unes de ces actions malveillantes. Dautres fonctionnalits logicielles, inhrentes
7
Lutilisation de cet appel systme peut chouer sur certains processus. Cest le cas, en particulier, des processus issus
de programmes excuts avec les bits suid ou sgid positionns. Pour les systmes dexploitation Linux, dautres
restrictions peuvent sajouter lorsque les patchs grsecurity [Spengler 12] ont t appliqus son noyau.
13
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
lditeur de liens, peuvent galement tre dtournes de leur utilisation lgitime et impacter,
par l-mme, la scurit dautres programmes. Nous pensons, en particulier, au mcanisme de
chargement de bibliothques dynamiques de fonctions dont le comportement peut tre modi-
fi par la dfinition de variables denvironnement bien prcises. Les variables denvironnement
LD_LIBRARY_PATH et LD_PRELOAD prcisent, par exemple, lditeur de liens respective-
ment les emplacements du systme o chercher les bibliothques dynamiques de fonctions et
celles qui doivent tre charges en priorit avant toutes les autres. Ces fonctionnalits logicielles
sont particulirement utiles lorsquil sagit de dvelopper et tester un systme. Cependant,
pour des raisons de scurit videntes, il est fortement recommand de rendre ces fonction-
nalits inoprantes dans tous les systmes en production. Il suffirait alors pour un attaquant
quune des bibliothques dynamiques de fonctions charges par ces variables denvironne-
ment soit vulnrable ou quil puisse les modifier de faon charger ses propres bibliothques
de fonctions pour porter atteinte la scurit du systme informatique. Ces techniques dat-
taques sont discutes dans le dtail dans [halflife 97] et sont mises en uvre dans le rootkit
rcent Jynx-Kit [ErrProne 12].
Le mcanisme de chargement de modules dextension prsent dans certains systmes lo-
giciels peut galement tre dtourn des fins dattaques. Un module dextension (en an-
glais, plug-in) dsigne un composant logiciel quil est possible de charger dans un systme
logiciel de faon tendre lensemble des services disponibles. Il sadjoint alors ce systme
en modifiant sa structure et son tat au travers dinterfaces logicielles bien dfinies. Un atta-
quant peut alors compltement modifier le comportement du systme logiciel ds lors que ces
interfaces logicielles sont trop permissives. Un tel mcanisme est implment dans la majorit
des noyaux de systmes dexploitation actuels afin de permettre le chargement de composants
logiciels provenant de tiers tels que les pilotes de priphriques, les modules implmentant
des fonctionnalits complmentaires, etc. Des personnes malintentionnes dtournent naturel-
lement cette fonctionnalit logicielle afin dattaquer le noyau de systme dexploitation et, par
l-mme, lensemble des programmes qui en dpendent pour leur excution. Dans les systmes
dexploitation Linux, de nombreux rootkits, tels que [Creed 99, truff 03, TESO 04, styx 12], sin-
srent par ce vecteur dattaque. La majorit de ces maliciels reposent sur des techniques dat-
taques publies dans [Pragmatic et THC 99].
Une dernire fonctionnalit logicielle pouvant tre dtourne pour impacter la scurit
des systmes matriels mrite dtre mentionne. Les noyaux de systme dexploitation (pour
tre plus prcis, les diffrents sous-systmes logiciels qui pilotent chaque composant matriel)
mettent souvent disposition des programmes des interfaces logicielles de faon faciliter les
interactions entre les programmes et le matriel. Ces interfaces logicielles, que lon nomme g-
nralement des priphriques virtuels par abus de langage, permettent aux programmes de
sabstraire des spcificits de chaque composant matriel et rduisent dautant la complexit de
ces programmes. Les attaquants peuvent sen servir comme dun vecteur daccs (en lecture,
et parfois en criture) au matriel. Les possibilits dattaques dpendent alors des fonction-
nalits implmentes dans ces priphriques virtuels. Dans les systmes dexploitation Linux,
les priphriques virtuels /dev/kmem 8 et /dev/mem 9 , lesquels offrent respectivement une
abstraction de la mmoire virtuelle du noyau du systme dexploitation et de la mmoire phy-
sique, sont particulirement usits par les maliciels. Les techniques dattaques qui les mettent
en uvre sont discutes dans [Cesare 99, crazylord 02, Lineberry 09]. Heureusement, laccs
aux priphriques virtuels requiert des privilges dadministrateur, tout comme le chargement
8
Il est possible de dsactiver ce priphrique virtuel depuis les versions de noyaux Linux 2.6.27 [van de Ven 08].
9
Il est question de dsactiver ce priphrique virtuel dans les prochaines versions du noyau Linux [ter Huurne 12].
14
1.2. Classification des attaques sur les systmes informatiques
15
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
16
1.2. Classification des attaques sur les systmes informatiques
lintgrit ou la confidentialit. tant donn que ces accs sont autoriss et que leur mise en
uvre est relativement bien documente dans les spcifications, il peut alors savrer difficile
de distinguer un accs malveillant dun accs lgitime.
Un autre cas quil est important de considrer est celui des fonctionnalits matrielles non-
documentes. Depuis de nombreuses annes, on remarque, par exemple, que certaines instruc-
tions du processeur, qui ne semblent pas dfinies, ne provoquent pas dexceptions matrielles
lors de leur excution [Collins 12b]. Cest le cas en particulier de lopcode 0xd6 dans les pro-
cesseurs Intel x86 qui, pendant longtemps a t considr comme une instruction nop (une
absence dopration). En ralit, il correspondait une opration qui consiste mettre 0
le registre AL du processeur lorsque le bit de retenue (en anglais, carry) du processeur est
1 [Collins 12c]. Celui-ci na t document qu partir de la 6e gnration de Pentium, soit
partir de lanne 2004. Lexistence de ces fonctionnalits matrielles non-documentes est pr-
occupante et fait peser un risque important sur la scurit du systme. En effet, on voit sans
peine lavantage que pourrait obtenir un attaquant bien inform alors que les utilisateurs nen
souponnent mme pas lexistence.
De la mme faon que les systmes logiciels, les systmes matriels peuvent contenir des
fonctionnalits matrielles vulnrables. Toutefois, celles-ci sont moins courantes que les vuln-
rabilits logicielles et, dans la majorit des cas, ne sont pas exploitables. Pour se convaincre
de lexistence de telles vulnrabilits matrielles, il suffit de remarquer que les principaux
constructeurs de processeurs compatibles x86 publient, de faon rgulire, les bogues mat-
riels dans leurs composants. Ces bogues, pour lesquels une liste est disponible [Collins 12a],
sont relativement nombreux et certains ne seront sans doute jamais corrigs. En particulier, le
bogue matriel dcouvert dans les processeurs Pentium en dcembre 1997 [Collins 97d] au-
rait pu tre utilis pour perptrer des attaques contre la disponibilit. En effet, lorsquun pro-
cesseur Pentium excutait la squence dinstructions lock cmpxchg8b eax (correspondant
la squence doctets 0xF00FC7C8), celui-ci se bloquait aussitt. Linstruction cmpxchg8b
eax ntant pas valide, lexcution de celle-ci dclenchait une exception matrielle. Cette ins-
truction prfixe par linstruction lock formait galement une autre instruction invalide et
provoquait aussi une exception matrielle. cause dune inversion de priorit dans le trai-
tement de ces deux exceptions matrielles, le processeur entrait dans un tat dinterblocage.
Une personne malintentionne pouvait profiter de ce bogue matriel pour provoquer des d-
nis de service simplement en excutant un programme contenant cette squence dinstruc-
tions. Il nest pas clair que ce bogue matriel ait t corrig sur les processeurs actuels. La
plupart des systmes dexploitation masquent cependant ce problme par une configuration
particulire du processeur. Il est intressant de remarquer que tous les bogues matriels ne
conduisent pas ncessairement un dni de service. Dans certains cas, une escalade de pri-
vilges [Wojtczuk et Rutkowska 11b, Gruskovnjak 12] est possible lorsque lattaque est mene
habilement.
17
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
nes comme non-excutables dans le but de rendre plus difficile lexploitation des vulnrabili-
ts logicielles. Pour faire en sorte que ces zones de donnes soient nouveau excutables, une
attaque simple peut tre envisage. Elle consiste positionner les attributs des pages contenant
ces zones de donnes une valeur approprie. Ces attributs des pages configurent le contrle
daccs effectu par lunit de gestion mmoire (Memory Management Unit, ou MMU) dans le
processeur. En occurrence, pour cet exemple prcis, lattribut NX (pour Never-eXecute) de cha-
cune de ces pages doit tre mis zro. Dans la majorit des cas, un attaquant va altrer la confi-
guration matrielle de manire valide. Toutefois, il arrive parfois quun attaquant exprimente
des modifications invalides de faon perturber des fonctionnalits matrielles, rvler des
vulnrabilits matrielles [Rutkowska et Wojtczuk 08, Wojtczuk et Rutkowska 11b] ou influer
sur (voire exploiter) un systme logiciel au moyen des valeurs contenues dans la configuration
matrielle [Wojtczuk et al. 09]. Il peut tre intressant de positionner, par exemple, les champs
rservs pour un usage futur, qui sont gnralement mis zro, des valeurs alatoires.
Ce vecteur dattaque est probablement le plus simple mettre en uvre. Il ncessite que
lattaquant obtienne un accs en mission sur le canal de communication. Une fois cet accs
acquis, il peut chercher dtruire les messages changs entre les systmes qui interagissent et
perturber ainsi les communications, voire provoquer une atteinte contre la disponibilit. Une
manire simple (et efficace) pour atteindre cet objectif revient ne pas respecter les rgles dac-
cs au mdium et de le parasiter en continu de faon empcher les systmes de communiquer.
Cette technique dattaque sapparente au brouillage (en anglais, jamming). Lorsque les messages
changs transitent par un composant sous le contrle de lattaquant (par exemple, une passe-
relle compromise), une autre faon de dtruire les messages consiste les bloquer au niveau de
ce composant. Dans ce cas, nous parlons plutt dinterruption de messages.
Ce vecteur dattaque consiste modifier les messages changs entre les systmes qui com-
muniquent. Sa mise en uvre ncessite, par consquent, un accs en coute et en mission sur
le canal de communication. La modification des messages est opre soit directement sur les
18
1.2. Classification des attaques sur les systmes informatiques
canaux de communication soit laide dun systme intermdiaire, sous le contrle de latta-
quant, par lequel transitent les changes. Les objectifs de lattaquant guident gnralement la
nature des modifications apportes. Une modification incohrente va impacter, dans la plupart
des cas, la disponibilit et va conduire un dni de service moins quun mcanisme de tol-
rance aux fautes efficace contre ce type dincohrence ne soit mis en uvre. En revanche, une
modification cohrente peut conduire des attaques diffrentes. Une attaque courante est le
dguisement (en anglais, masquerade) qui consiste tromper les mcanismes dauthentification
pour se faire passer pour un utilisateur autoris, de faon obtenir des droits daccs illgi-
times et ainsi compromettre la confidentialit, lintgrit ou la disponibilit. Un cas particulier
de dguisement consiste pour un attaquant forger de fausses adresses dorigine pour les
messages quil met. Dans ce cas, nous parlons alors plus particulirement de spoofing (littra-
lement, parodie) dadresse. Ce dguisement est, par exemple, trs facile raliser sur le rseau
Internet, puisquil ny a pas dauthentification sur les adresses IP.
Ce vecteur dattaque consiste effectuer un accs, sans modification, aux messages qui
sont gnrs, transmis ou stocks sur les systmes matriels et logiciels vulnrables. Il cible
plus particulirement les proprits de confidentialit. Les attaques par captation de messages
sont trs souvent difficiles dtecter. En effet, tant entirement passives, elles ne produisent
pas deffets observables sur les canaux de communication. Il existe de nombreuses variantes de
captation de messages (plus ou moins) passives, souvent baptises de noms imags : le sniffing
(action de renifler), le snooping (action de fouiner), leavesdropping (action dcouter aux portes),
wire-tapping (branchement sur une liaison filaire, installation dune bretelle ). Les techniques
de captation de messages se sont largement dveloppes avec la connexion de nombreux r-
seaux locaux sur lInternet. Une fois quun intrus a pris le contrle dune machine dun rseau
local, il peut installer un sniffer, qui est un logiciel capable de configurer la connexion rseau
de cette machine (par exemple, le contrleur Ethernet ou le contrleur de rseau sans fil) en
mode dcoute (en anglais, promiscuous mode) puis analyser les paquets qui circulent sur le r-
seau, en particulier pour rcuprer les noms dutilisateurs et les mots de passe, parfois transmis
en clair lors des phases de connexion dutilisateurs. Il convient de remarquer que les informa-
tions (utiles) dans les messages ne sont pas toujours directement accessibles. Elles peuvent, par
exemple, tre dissimules dans un ou plusieurs messages laide de techniques de stganogra-
phie.
19
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
faon masquer, ces systmes, dautres activits malveillantes (par exemple, linstallation
dune porte drobe).
Il convient de remarquer quil est possible de dfinir des techniques dattaques plus com-
plexes partir des quatre vecteurs dattaque que nous venons de prsenter. titre dexemple,
une attaque de type man-in-the-middle (littralement, lhomme au milieu), laquelle consiste
intercepter une communication entre deux systmes puis falsifier les changes afin de se faire
passer pour lune des parties, peut tre dfinie par la combinaison dune captation et plusieurs
insertions de messages. Les premires insertions permettent lattaquant de se faire passer
pour lune des parties et dautres insertions sont ncessaires pour relayer les messages capts.
Attaque par analyse temporelle. Ds lors quun attaquant connat lalgorithme implment
dans un systme, les variations du temps dexcution dun traitement peuvent lui fournir de
prcieux renseignements sur les paramtres qui sont impliqus. Nous parlons alors dattaques
par analyse temporelle (en anglais, timing attack). Une telle attaque a t montre contre le pro-
tocole Secure Shell (SSH) par [Song et al. 01] lors de la 10e dition de lUnix Symposium Security.
En appliquant une analyse temporelle sur les paquets correspondant aux frappes de clavier, ils
ont montr quil tait possible dinfrer une quantit dinformations suffisante sur le contenu
dune communication chiffre et localiser celles correspondant la saisie dun mot de passe.
Ils ont galement constat quune simple analyse de trafic sur les paquets rseau rvlait la
longueur des donnes changes (et donc la longueur des noms dutilisateurs et des mots de
passe associs). En recoupant ces informations, Song et al. ont t capables de rduire de moiti
leffort ncessaire pour retrouver le mot de passe dun utilisateur.
20
1.2. Classification des attaques sur les systmes informatiques
21
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
Au prime abord, cette technique dattaque peut sembler anecdotique et dpasse avec les tech-
nologies actuelles. Elle ne doit cependant pas tre nglige. En 2004, [Shamir et Tromer 04] ont
dmontr quil est possible de saider des variations de bruits ultrasoniques manant de com-
posants lectroniques dans le processeur ou dans la carte-mre pour identifier, laide dune
analyse temporelle, les oprations ou les accs la mmoire centrale effectus par le processeur.
Un attaquant peut ne pas se contenter danalyser les canaux de fuite et utiliser ces mmes
canaux pour perturber le fonctionnement de ces systmes et ainsi porter atteinte leur scurit
(par exemple, reconstitution dun secret, validation dune fausse signature, etc.). Nous parlons
alors dinjection de fautes par les canaux auxiliaires. La plupart des injections de fautes sont
faites de faon plus ou moins alatoire. Lobjectif poursuivi est, en premier lieu, dessayer de
ne gnrer quune modification ponctuelle et de comparer les excutions du systme sans in-
jection de fautes et avec injection de fautes. Les premires fautes injectes dans les systmes
informatiques (dans les annes 1970) taient accidentelles 13 : les particules radioactives alpha
produites par des lments prsents dans les matriaux demballage causaient des fautes dans
les puces. Ces particules craient une charge dans les parties de la puce qui taient critiques
provoquant ainsi des inversions de bits (en anglais, bit-flips). Mme si ces lments ntaient
prsents quen petite quantit, leur concentration tait suffisante pour influer sur le comporte-
ment de la puce [May et Woods 79]. Aujourdhui, il existe de nombreuses faons de perturber
le fonctionnement dun systme informatique en agissant sur son environnement. Nous pr-
sentons dans la suite plusieurs de ces techniques.
Modification de la tension lectrique. Les circuits lectroniques sont tous conus pour fonc-
tionner pour une tension dalimentation constante et bien dfinie. Des variations soudaines
de cette tension (en anglais, voltage spikes) peuvent perturber son fonctionnement. Dans les sys-
tmes informatiques, ce vecteur dattaque est utilis pour induire des erreurs dans les mmoires
ou pour modifier les chemins dexcution du code quil excute (par exemple, modification
dun compteur de boucle, des condition de sauts, etc.). La littrature fait tat de nombreuses
attaques utilisant cette technique sur des cartes puces [Boneh et al. 97b, Biham et Shamir 97,
Boneh et al. 01a, Aumller et al. 03, Yen et al. 03].
22
1.2. Classification des attaques sur les systmes informatiques
violables. En aot 2007, des hackers ont remarqu sur la Xbox 360 que lenvoi dune impulsion
de remise zro un processeur sous-cadenc ne le rinitialisait pas et changeait la faon dont
le code tait interprt. Lexploitation habile de ce comportement du processeur au moment o
les condensats sont compars lors de la vrification de la chane de confiance avait permis aux
hackers dexcuter du code arbitraire et, en particulier, de charger une version antrieure du
noyau de systme dexploitation qui tait vulnrable et pour laquelle des attaques avaient dj
t dveloppes. En janvier 2010, une attaque utilisant quasiment le mme mode opratoire
a t mene sur la Playstation 3 [EurAsia 10] par George Francis Hotz, connu sous le pseudo-
nyme GeoHot. Pour cette attaque, GeoHot avait programm une puce FPGA pour envoyer une
impulsion de 40 ns, la pression dun bouton, sur une ligne du contrleur de bus mmoire de
sa Playstation 3. Cette impulsion avait pour but dempcher le processeur dcrire en mmoire
(en mmoire cache pour tre plus prcis), et donc de donner une vision fausse de la mmoire
lhyperviseur de la Playstation 3 : celui-ci croyait alors quune zone de mmoire tait dsal-
loue alors que lattaquant y avait encore accs en lecture et en criture, car la configuration de
lunit de gestion mmoire navait pas pu tre modifie. En faisant en sorte que lhyperviseur
utilise cette zone de mmoire pour lune de ses structures internes, il a pu dtourner son flot
dexcution et y installer deux appels systmes pour permettre du code moins privilgi de
lire et dcrire une adresse mmoire quelconque.
Injection de faute par rayonnement. Rcemment, [Skorobogatov et Anderson 03] ont observ
quclairer un transistor pouvait le rendre conducteur, induisant alors une faute. Ainsi, en ap-
pliquant une source de lumire intense (produite laide du flash dun appareil photo puis
concentre laide dun microscope), ils ont russi modifier les valeurs de bits choisis dans
une mmoire de type SRAM. Il convient de noter quil est souvent ncessaire que la puce soit
au pralable dcapsule afin que le rayon lumineux atteigne la zone dintrt. Un tel vecteur
dattaque est particulirement intressant pour changer les bits relatifs une instruction de
saut afin de faire prendre au processeur la mauvaise branche (et valider par exemple un calcul
faux). Les rayonnements lumineux ne sont pas les seuls qui peuvent tre utiliss pour injecter
des fautes. Il est galement possible dutiliser les rayonnements de particules et les rayonne-
ments lectromagntiques.
Nous avons prsent, dans cette section, une classification possible des attaques impactant
la scurit des systmes informatiques. Cette classification hirarchique est issue dun travail de
caractrisation de ces attaques selon trois axes : le niveau dabstraction du systme o se situe
lattaque, lobjet de lattaque ce niveau dabstraction et enfin le vecteur dattaque que peut
utiliser un attaquant sur cet objet. Afin de rvler rapidement les fautes dans leurs systmes,
nous constatons, aujourdhui, que de plus en plus dentreprises, conscientes de limportance de
23
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
la scurit informatique, intgrent des mthodes et des techniques dlimination des fautes
leur cycle de dveloppement. La section qui suit dresse un tat de lart de ces mthodes et de ces
techniques qui sadaptent aussi bien aux composants logiciels quaux composants matriels.
Analyse statique
Statique Preuve mathmatique
Analyse de comportement
Vrification
Excution symbolique
Dynamique
Test
24
1.3. Mthodes et techniques pour llimination des fautes
25
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
exhaustive le graphe en sassurant quune proprit est vrifie pour chacun de ses tats et
retourne un contre-exemple si la proprit a t viole dans au moins un de ses tats.
1.3.5 Test
Le test est certainement la technique de vrification la plus largement rpandue [Roper 92].
Il consiste excuter un programme en lui fournissant des entres values, les entres de test,
et vrifier la conformit des sorties par rapport au comportement attendu. Sa mise en uvre
ncessite de rsoudre deux problmes : le problme de la slection dentres de test, et le pro-
blme de loracle [Weyuker 82], autrement dit comment dcider de lexactitude des rsultats
observs. Sauf cas trivial, le test exhaustif est gnralement impossible et on est amen slec-
tionner de manire pertinente un (petit) sous-ensemble du domaine dentre. Cette slection
peut seffectuer laide de critres de test lis un modle de la structure du systme. Nous
parlons alors de test structurel. Elle peut galement seffectuer laide de critres de test lis
un modle des fonctions que doit raliser le systme. On parle alors plutt de test fonctionnel.
Quel que soit le critre de slection, la gnration des entres peut tre dterministe ou pro-
babiliste. Dans le premier cas qui dfinit le test dterministe, les entres sont dtermines par un
choix slectif de manire satisfaire le critre de test retenu. Dans le deuxime cas qui dfinit le
test statistique ou alatoire, les entres sont gnres de manire alatoire selon une distribution
probabiliste sur le domaine dentre, la distribution et le nombre des donnes de test tant d-
termins partir du critre retenu [Waeselynck 93]. Ces deux types de gnration des entres de
test, dterministe et alatoire, sont complmentaires [Duran et Ntafos 84, Thevenod-Fosse 91],
et devraient tre utiliss toutes les tapes de test. Il est important de rappeler le rle d-
terminant du choix de la distribution des probabilits sur le domaine dentre, dont dpend
fortement lefficacit du test statistique : la distribution doit tre choisie en fonction du critre
de test pour permettre une bonne couverture, structurelle ou fonctionnelle, du systme.
En ce qui concerne le problme de loracle, un dpouillement automatis des rsultats de
test est toujours souhaitable, et devient indispensable lorsquun grand nombre dentres ont
t slectionnes. Les solutions les plus satisfaisantes sont bases sur lexistence dune spcifi-
cation formelle du programme sous test. La spcification est alors utilise pour dterminer les
rsultats attendus, soit lors de la slection des entres de test, soit a posteriori. Dautres solutions
doracle partiel peuvent tre dtermines au cas par cas, en ralisant des contrles de vrai-
semblance sur les rsultats de test (contrle de cohrence entre diffrentes donnes, contrle
dappartenance une plage de valeurs, etc.).
26
1.4. Conclusion
Dans cette section, nous avons prsent des exemples de mthodes issues du domaine de
la sret de fonctionnement, mais elles peuvent aussi sappliquer la scurit informatique en
les adaptant ventuellement dautres proprits (par exemple, la confidentialit). Il convient
de remarquer quaucune de ces techniques ne garantit une limination exhaustive des fautes.
Aussi parat-il essentiel de combiner ces diffrentes techniques afin den rvler un maximum.
1.4 Conclusion
Ce chapitre a introduit une partie des connaissances ncessaires la comprhension de nos
travaux. Nous avons commenc par rappeler les concepts de base et la terminologie associe
la sret de fonctionnement des systmes. Nous avons ensuite situ, dans ce contexte, le
sujet principal de nos travaux, savoir la scurit des systmes informatiques et prcis les
trois proprits fondamentales confidentialit, intgrit et disponibilit qui la dfinissent.
partir de l, nous nous sommes concentrs sur les actions qui cherchent mettre en dfaut
ces proprits. La caractrisation de ces attaques a abouti une classification de ces actions
malveillantes selon trois axes complmentaires : le niveau dabstraction du systme auquel
seffectue lattaque, lobjet de lattaque ce niveau dabstraction et le vecteur dattaque utilis
sur cet objet. Remarquons que cette classification peut tre adapte tout type de systme
informatique. Elle ncessite cependant, afin de lever toute ambigut, de dfinir prcisment
la frontire entre le systme considr et son environnement. Finalement, puisque ces attaques
exploitent des fautes de conception ou de configuration introduites de manire intentionnelle
ou accidentelle, nous avons prsent les mthodes et les techniques qui visent liminer ces
fautes, aussi bien lors du dveloppement du systme informatique que lors de son service en
vie oprationnelle.
Dans le prochain chapitre, nous proposons un modle gnral dattaques sur les systmes
informatiques. Celui-ci sappuie, entre autres, sur la classification des actions malveillantes que
nous venons de prsenter. Lobjectif que nous avons poursuivi lors de llaboration de ce mo-
dle dattaques a t didentifier de faon exhaustive, puis dtudier, les attaques impactant
la scurit des systmes informatiques. Une attention particulire est ensuite prte, dans les
chapitres 3 et 4, aux attaques qui reposent sur lutilisation des mcanismes dentres-sorties
auxquels nous nous intressons dans les travaux dcrits dans ce manuscrit.
27
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
28
Chapitre 2
Llaboration dun modle dattaques est essentielle pour tudier de manire mthodique
les attaques impactant les systmes informatiques. Celui que nous avons tabli pour notre
tude sinspire fortement des graphes dattaque [Sheyner 04] et couvre des scnarios dattaque
qui impliquent ventuellement diffrents niveaux dabstraction dun systme informatique.
Notre dmarche repose sur le fait quune attaque quelconque ciblant un systme informatique
peut tre dcompose en une squence dactions lmentaires dont certaines dentres elles
les attaques lmentaires ont lintention de nuire aux proprits de scurit de ce systme
ou dun systme ayant une quelconque relation avec lui. Naturellement, cette approche nous a
amens, dune part, identifier lensemble des actions lmentaires possibles dans un systme
informatique et, dautre part, dterminer les enchanements de celles-ci qui donnent lieu
des attaques. Ce travail est lobjet de ce chapitre.
Nous commenons, en section 2.1, par introduire quelques lments sur linfrastructure
matrielle dun systme informatique. En particulier, nous caractrisons fonctionnellement les
composants matriels qui la constituent et nous rappelons succinctement les architectures de
communication au travers desquelles ils interagissent. Ces lments nous permettent alors
davoir une vision macroscopique des interactions entre les composants matriels. Nous d-
taillons ensuite, en section 2.2, la logique que nous avons suivie pour laborer notre modle
dattaques. Dans celle-ci, nous considrons les composants matriels comme des systmes
part entire qui interagissent avec dautres composants matriels, donc dautres systmes et
nous modlisons leur structure interne sous la forme dun graphe de flots de donnes. En re-
portant les vecteurs dattaque que nous avons prcdemment identifis (cf. section 1.2) sur ce
modle, nous dterminons lensemble des actions lmentaires (et des attaques lmentaires)
au sein dun composant matriel. La combinaison du graphe dactions lmentaires associ
chaque composant matriel pris isolment et des interactions possibles entre ces diffrents com-
posants nous permet alors de dduire de manire aussi exhaustive que possible lensemble des
scnarios dattaque dans un systme informatique. Nous illustrons le modle obtenu, en sec-
tion 2.3, par plusieurs exemples rels dattaque. Finalement, la section 2.4 discute de quelques
limites de notre modle dattaques et propose quelques pistes damlioration.
29
Chapitre 2. laboration dun modle dattaques
sente section, nous nous concentrons spcifiquement sur le systme matriel et, en particulier,
sur son infrastructure. Celle-ci est constitue de plusieurs composants matriels htrognes
tels que des processeurs, des mmoires, des contrleurs dentres-sorties, des priphriques,
etc. qui interagissent au travers dune architecture de communication dans le but daccomplir
des tches spcifiques. Cette section traite de faon gnrale de diffrents aspects de linfra-
structure matrielle dun systme informatique. Nous commenons par rappeler la termino-
logie associe aux bus informatiques. Ensuite, nous nous intressons aux aspects fonctionnels
des composants matriels et nous dcrivons ceux que nous retrouvons typiquement dans un
systme informatique.
30
2.1. Infrastructure matrielle dun systme informatique
Mmoire Mmoire
Processeur
interne interne
Dcodeur Arbitre
Port matre Port esclave Port esclave
Port matre Port matre Port matre Port esclave Port matre & esclave
Mmoire
Priphrique
externe
plusieurs critres parmi lesquels les plus rcurrents sont le cot, la complexit, la puissance et
les performances. Diffrentes topologies de bus existent dans un systme informatique : le bus
partag, le bus en toile, le bus en anneau, etc. Celles-ci peuvent tre combines pour former
larchitecture de communication dont le rle est dacheminer correctement et de manire fiable
les flots de donnes partir des composants sources aux composants destinataires, tout en
garantissant, ventuellement, une certaine qualit de service (latence, bande passante, etc.).
Les composants matriels peuvent tre dcrits selon diffrents points de vue. Les ing-
nieurs lectroniciens les dcrivent par exemple comme une combinaison de composants lec-
troniques (puces, transistors, rsistances, condensateurs, etc.) interconnects par des fils. Les
ingnieurs logiciel les peroivent plutt comme des entits qui accomplissent une ou plusieurs
fonctions et avec lesquelles il est possible dinteragir par des commandes. Jusqu prsent, nous
nous sommes attachs dcrire les multiples rles (arbitre, dcodeur, matre ou esclave) quils
peuvent endosser sur les bus auxquels ils sont connects. La prochaine sous-section (2.1.2)
complte cette vision des composants matriels en considrant leurs aspects fonctionnels.
31
Chapitre 2. laboration dun modle dattaques
Mmoires
Intrieur
Extrieur
Contrleur Contrleur
Priphriques
de priphriques externe
Contrleur
Priphriques Priphriques
de priphriques
2.1.2.1 Processeur
Le processeur est un lment essentiel dans un systme informatique. En effet, il constitue
lunit centrale de traitement (en anglais, central processing unit) du systme. Les traitements
oprs par ce composant matriel sont dcrits par une squence dinstructions quil rcupre
de la mmoire centrale, dcode afin de dterminer leur type et leurs oprandes, puis excute.
Ces oprations sont effectues de manire cyclique jusqu ce que le traitement se termine. Un
systme informatique peut contenir un ou plusieurs processeurs. Ils accdent la mmoire
centrale au travers du rpartiteur auquel ils sont relis par un bus systme. Ils se comportent
gnralement en composants matres sur ces bus.
2.1.2.2 Rpartiteur
Le rpartiteur dsigne un composant matriel qui interconnecte les bus systmes avec les
bus locaux. Ainsi, il se comporte la fois en composant matre et en composant esclave sur les
bus. Dans son rle desclave, il dcode les transferts de donnes initis par le processeur ou
par les contrleurs dentres-sorties et, dans son rle de matre, les relaie leurs destinataires.
Il est charg daiguiller correctement ces accs dans larchitecture de communication et il dfi-
nit, par l-mme, les diffrents espaces dadressage qui permettent aux composants matriels
dinteragir entre eux.
32
2.1. Infrastructure matrielle dun systme informatique
systmes et les bus mmoires. En effet, il est charg de traduire des requtes de lecture ou
dcriture en mmoire en provenance dun processeur ou des contrleurs dentres-sorties vers
le protocole de bus (par exemple, SDRAM, DDR SDRAM, etc.) implment par les barettes de
mmoire utilises dans le systme informatique. Ainsi, le contrleur de mmoire joue la fois
le rle desclave sur les bus systmes qui le relient au rpartiteur et le rle de matre sur le bus
mmoire qui le connecte aux barettes de mmoire, agissant alors en esclaves.
Les contrleurs dentres-sorties dsignent de faon gnrale tous les composants matriels
de type pont. Leur dnomination tient de leurs fonctions : ils contrlent diffrents bus sur les-
quels transitent les entres-sorties, cest--dire les changes entre le processeur et des systmes
externes tels que des priphriques ou dautres systmes informatiques. Nous distinguons plu-
sieurs types de bus :
les bus locaux (ou bus dentres-sorties) relient les contrleurs dentres-sorties au r-
partiteur. Cette connexion au rpartiteur est souvent directe. Il arrive, cependant, que
celle-ci soit indirecte et se fasse au travers dun autre contrleur dentres-sorties ;
les bus dextensions sont chargs de connecter le systme informatique des systmes
matriels externes, en particulier des priphriques.
Les contrleurs dentres-sorties se distinguent principalement par les fonctions spcifiques
quils remplissent au sein du systme informatique. Par exemple, lorsque leur rle consiste
connecter les bus locaux (respectivement, les priphriques aux bus locaux), nous parlons sp-
cifiquement de contrleurs de bus locaux (respectivement de contrleurs de priphriques) ;
lorsque celui-ci est utilis pour communiquer avec un autre systme informatique au travers
du rseau, nous parlons alors de contrleur rseau ; etc. Ils sont gnralement internes au sys-
tme informatique. Dans ce cas, ils sont directement intgrs la carte-mre par son fabricant
ou ajouts au systme informatique par des connecteurs ddis. linstar des contrleurs em-
barqus dans les cartes PCMCIA, Express Card ou Thunderbolt, dautres contrleurs dentres-
sorties sont externes au systme informatique.
2.1.2.5 Priphriques
La littrature dsigne les priphriques comme des systmes matriels auxiliaires (tels que
les claviers, les souris, les imprimantes, les webcams, etc.) quil est possible de connecter au sys-
tme informatique dans le but dtendre ses fonctionnalits. Malheureusement, cette dfinition
nest pas suffisamment prcise. En effet, les cartes dextensions telles que les cartes rseau, les
cartes graphiques peuvent tre considres comme des priphriques au mme titre que les
imprimantes, les scanners, les webcams, etc. Pour les dissocier, nous allons considrer dans la
suite de ce manuscrit que la connexion dun priphrique un systme informatique se fait
ncessairement au travers dun bus dextension issu dun contrleur de priphrique. Nous
distinguons gnralement deux catgories de priphriques : ceux qui sont internes et ceux qui
sont externes au systme informatique. Les priphriques tels que les claviers, les souris et les
imprimantes sont dits externes car ils se situent, en gnral, lextrieur du systme informa-
tique. loppos, les priphriques tels que les disques dur internes ou les lecteurs de disques
internes sont dits internes car ils sont situs lintrieur de lordinateur (serveur, ordinateur
de bureau, ordinateur portable, etc.). La plupart des priphriques se comportent en compo-
sants esclaves et rpondent aux commandes inities par les contrleurs de priphriques. Ce-
pendant, certains priphriques peuvent se comporter la fois en composants matres et en
33
Chapitre 2. laboration dun modle dattaques
composants esclaves sur leurs bus. Cest le cas notamment des priphriques qui se connectent
aux bus USB On-The-Go (OTG) et aux bus FireWire.
2.2 Modle dattaques bas sur les interactions entre les composants
Cette section prsente le modle dattaques que nous avons tabli pour identifier les at-
taques ciblant les systmes informatiques. La construction de ce modle repose principalement
sur lide quune attaque peut tre dcompose en une squence dactions lmentaires parmi
lesquelles certaines sont lgitimes et lintention dautres est de nuire aux proprits de scurit
14
Intel AMT dsigne une technologie dadministration distance de plates-formes. Utilise avec des applications
dadministration et de scurisation des systmes informatiques, cette technologie facilite la maintenance (cest--
dire, la dtection, la rparation et la protection) des ressources informatiques en rseau.
34
2.2. Modle dattaques bas sur les interactions entre les composants
de ce systme ou dun systme ayant une quelconque relation avec lui. Ainsi, une attaque peut
tre formalise comme suit.
Soit les ensembles suivants :
A lensemble des attaques dans un systme informatique,
E lensemble des actions lmentaires,
L lensemble des actions lmentaires lgitimes et
M lensemble des attaques lmentaires.
Lensemble des actions lmentaires E est form de lensemble des actions lmentaires
lgitimes auquel est adjoint lensemble des attaques lmentaires (E = L [ M). Pour simplifier
notre formalisme, nous allons considrer que ces deux ensembles sont disjoints (L \ M = ;).
En ralit, il peut parfois tre difficile de diffrencier les actions lmentaires lgitimes des
attaques lmentaires. En effet, en fonction des hypothses effectues sur le systme tudi
et du contexte dans lequel une attaque est mene, elle peut tre perue comme appartenant
lun des deux ensembles. Bien quil sagisse dune attaque en confidentialit, laccs une
ressource laquelle un utilisateur ne devrait pas avoir accs, dans la mesure o il y a un dfaut
dans la politique de scurit et que celle-ci permet laccs, pourrait tre peru comme un accs
lgitime par exemple. La simplification que nous avons faite au sujet des ensembles L (actions
lmentaires lgitimes) et M (attaques lmentaires) est, par consquent, une hypothse forte
mais acceptons, pour des raisons de clart, quelle soit valide.
Lors dune attaque, plusieurs actions lmentaires sont excutes en squence. Une action
lmentaire antrieure prpare la mise en uvre dune autre action lmentaire qui lui est
postrieure. Pour exprimer cette notion de squence et dinterdpendance entre actions l-
mentaires, nous introduisons la relation de prcdence note :
Soit e1 ; e2 2E deux actions lmentaires,
e1 e2 signifie que laction lmentaire e1 doit ncessairement avoir eu lieu et
que celle-ci ait, suite son droulement, satisfait les conditions pour
la mise en uvre de laction lmentaire e2 qui pourra se drouler
son tour.
Si e1 e2 , alors e1 et e2 peuvent constituer une squence dactions lmentaires note e1 e2 .
Par ailleurs, si e1 e2 et si e2 e3 alors e1 , e2 et e3 peuvent tre concatnes pour former une
seule squence dactions lmentaires note e1 e2 e3 . Une squence dactions lmentaires
est considre comme une attaque lorsquelle contient au moins une attaque lmentaire. Len-
semble des attaques A peut alors tre dfini par la relation suivante :
A = fe1 e2 : : : e 2 E + : 8i 2 [1; n
i 1]; ei e +1 et 9j 2 [1; n]; e 2 Mg
i j
Cette formalisation mathmatique du concept dattaque peut tre applique pour diff-
rents niveaux dabstraction dun systme informatique. Seuls le modle et le squencement
des actions lmentaires doivent alors tre adapts de faon pouvoir reprsenter les attaques
auxquelles nous nous intressons. Ces deux lments sont traits dans les sous-sections 2.2.1
et 2.2.2. Nous dcrivons, pour commencer, le modle des actions (et des attaques) lmentaires
que nous avons tabli pour notre tude.
35
Chapitre 2. laboration dun modle dattaques
ractristiques. Nous avons affirm, lors de notre travail de caractrisation des attaques l-
mentaires (cf. section 1.2), que celles-ci peuvent agir diffrents niveaux dabstraction du sys-
tme informatique. Aussi est-il important, dans notre modle, de couvrir ces diffrents niveaux
dabstraction. Par ailleurs, une attaque peut impliquer plusieurs systmes. Dans le cadre de
nos travaux, un type de systme nous intresse en particulier : les composants matriels et,
plus spcifiquement, les contrleurs dentres-sorties. Ainsi, notre modle dattaques doit ga-
lement prendre en compte les attaques entre les diffrents composants matriels et doit pouvoir
les reprsenter.
Afin de concilier ces caractristiques au sein de notre modle dattaques, nous proposons,
dans un premier temps, dtablir un modle gnrique de composant matriel sur lequel nous
pouvons nous appuyer pour identifier les actions lmentaires ainsi que les attaques lmen-
taires spcifiques tout composant matriel.
Un composant matriel peut tre modlis comme un systme part entire au sein duquel
plusieurs sous-systmes, organiss en couches, interagissent. Nous discernons trois principaux
sous-systmes communication, configuration et logique auxquels sassocie optionnellement
un sous-systme logiciel lorsque le composant matriel dispose dune partie programmable, un
firmware par exemple. Le sous-systme de communication appartient la couche la plus basse.
Il se charge des communications avec les autres composants matriels en offrant aux autres
sous-systmes du composant une abstraction du mdium de communication, autrement dit les
bus. Les communications sont inities (dans le cadre dune mission) et traites (dans le cadre
dune rception) par le sous-systme logique qui implmente les principaux services fournis
par le composant matriel. Ces services peuvent ventuellement tre tendues par dautres
services implments par le sous-systme logiciel. Les accs ces services depuis un autre
composant matriel se font au moyen du sous-systme de configuration. Les flots dinforma-
tions entre ces sous-systmes sont dcrits sur la figure 2.3. Les arcs reliant les sous-systmes
reprsentent les actions lmentaires.
Lgende:
Logiciel
Frontire du composant matriel
Communication
Grce au travail de caractrisation des attaques lmentaires que nous avons prsent au
chapitre 1 (cf. section 1.2), il est immdiat didentifier lensemble des attaques lmentaires sur
notre modle gnrique de composant matriel. Ces attaques lmentaires sont illustres sur la
figure 2.4. Cette reprsentation sous la forme dun graphe orient rend compte de la causalit
entre les actions lmentaires ncessaires leur enchanement. Dans ce formalisme graphique,
36
2.2. Modle dattaques bas sur les interactions entre les composants
un arc reprsente une action lmentaire qui peut tre ralise par un sous-systme source sur
un sous-systme cible. Les attaques lmentaires sont reprsentes par des arcs tiquets dun
numro indiquant le type dattaque. Pour ce formalisme, nous avons dlibrment choisi de
ne pas reprsenter, par exemple, les vecteurs dattaques. La granularit de reprsentation que
nous avons choisie est amplement suffisante pour les besoins de notre tude.
Il est opportun de remarquer que nous avons simplifi la reprsentation de certaines classes
dattaques, en particulier les attaques ciblant les canaux auxiliaires. En toute rigueur, il serait
ncessaire de tracer un arc depuis le dispositif externe vers chaque sous-systme du compo-
sant matriel ainsi que vers chaque mdium de communication au travers desquels ils com-
muniquent (galement reprsents par les arcs). Pour allger cette reprsentation, nous avons
trac un unique arc depuis le dispositif externe vers la frontire du systme cible.
5 Lgende:
5
Logiciel
Action lmentaire
1 Attaques sur les canaux auxiliaires
3 5 4
4 2 Attaques sur les canaux de communication
3 Attaques sur la configuration matrielle
Configuration 3
Logique 4 Attaques sur la logique du matriel
4
5 Attaques sur les fonctionnalits logicielles
2
1
Communication
Dispositif externe
Le modle dattaques lmentaires que nous venons dtablir sapplique tout composant
matriel. Il suffit alors dinstancier ce modle pour chacun des composants matriels du sys-
tme informatique tudi afin didentifier les actions lmentaires lgitimes et les attaques l-
mentaires qui leur sont spcifiques. Bien videmment, cette instanciation est fonction des hy-
pothses dattaques considres pour chaque composant matriel. Par ailleurs, nous pouvons
combiner ces instances construites individuellement en considrant les flots dinformations
possibles entre les composants matriels pour obtenir lensemble des actions lmentaires lgi-
times et des attaques lmentaires pour le systme informatique considr.
37
Chapitre 2. laboration dun modle dattaques
taille du graphe en fusionnant les sommets (et les arcs associs) qui napportent pas dinfor-
mations significatives aux attaques. Aussi, pour rduire la taille du graphe et rduire en cons-
quence le temps ncessaire aux calculs de lensemble des chemins possibles, nous proposons,
dans un premier temps, de fusionner les sommets appartenant une mme classe dquiva-
lence, cest--dire les sommets qui sont fortement connexes et dont les chemins pour aller dun
sommet un autre sont composs uniquement dactions lmentaires lgitimes (et donc darcs
non-tiquets). Nous rappelons quen thorie des graphes [Gross et Yellen 03], un couple de
sommets (u; v ) sont fortement connexes lorsquil existe un chemin de u v . Afin de garder la
structure gnrale du graphe et de ne pas perdre dinformations significatives, il est important
dappliquer ces rductions localement chaque composant matriel. En effet, en les appliquant
lensemble des sommets du graphe, nous pouvons tre confronts parfois une situation o
des sous-systmes de composants diffrents sont fusionns. Il devient alors difficile didentifier
prcisment les sources et les destinations des attaques.
Afin dacclrer les calculs de lensemble des chemins du graphe, il est galement possible
de calculer au pralable lensemble des chemins possibles au sein de chaque composant ma-
triel pris isolment. Nous pouvons ensuite considrer les interactions qui existent entre les
composants matriels. En ayant pr-calcul les chemins internes chaque composant, il est
possible de calculer rapidement lensemble des chemins correspondant des squences dat-
taques couvrant lensemble des composants du systme informatique considr.
Rpartiteur Contrleur de
Processeur
mmoire
Contrleurs
Priphriques Mmoires
d'entres-sorties
Pour identifier lensemble des attaques lmentaires dans le systme informatique, nous
38
2.2. Modle dattaques bas sur les interactions entre les composants
avons formul les hypothses dattaque suivantes pour chacun des composants matriels.
Le processeur. tant donn le rle actif jou par le processeur dans un systme informatique,
il peut tre utilis pour initier des attaques ciblant dautres composants matriels. Tou-
tefois, les sous-systmes qui le composent peuvent galement faire lobjet dattaques.
Les composants logiciels qui sexcutent au dessus de ce processeur sont potentiel-
lement vulnrables. De par leur complexit, ils sont rarement exempts de vulnra-
bilits qui sont souvent exploites par les attaquants. Nous allons reprsenter ces
attaques lmentaires par des arcs tiquets de au sein du processeur.
Le sous-systme logique dans le processeur est susceptible de contenir des bogues
ou des fonctionnalits caches qui peuvent tre mises profit par les attaquants pour
perptrer des attaques. Plusieurs exemples de ces bogues matriels ont t prsen-
ts au chapitre 1. Nous allons reprsenter les attaques lmentaires ciblant le sous-
systme logique par des arcs tiquets de au sein du processeur.
Le sous-systme logique et le sous-systme logiciel reposent, pour leur fonctionne-
ment, sur le sous-systme de configuration. Il est sans doute possible dimpacter in-
directement le fonctionnement de ces deux sous-systmes par une configuration in-
approprie du processeur. Nous allons reprsenter les attaques lmentaires ciblant
le sous-systme de configuration par des arcs tiquets de au sein du processeur.
Le rpartiteur. Ce composant matriel a un rle passif dans le systme informatique. Ainsi,
nous considrons que ses sous-systmes peuvent tre les cibles dattaques.
Le sous-systme logique du rpartiteur peut contenir des vulnrabilits matrielles.
Notamment, ceci a t dmontr par la preuve de concept dattaque publie dans
[Rutkowska et Wojtczuk 08]. Pour cela, les auteurs exploitent une fonctionnalit de
traduction dadresses (prcisment, la fonctionnalit de memory reclaiming) au sein
du chipset (que nous assimilons dans notre modle au rpartiteur) de faon contour-
ner tous les mcanismes de contrle daccs la mmoire centrale y compris ceux
mis en place par les units de gestion de la mmoire dans les processeurs pour isoler
les processus entre eux et ceux mis en place par le rpartiteur lui-mme pour prot-
ger les sous-systmes logiciels dans le gestionnaire de la plate-forme. Il semble que la
vulnrabilit soit due initialement une erreur de configuration du rpartiteur car les
fabricants de BIOS ont publi, peu de temps aprs la divulgation de la vulnrabilit
matrielle, un correctif logiciel empchant son exploitation. Nous allons reprsenter
ces attaques lmentaires par des arcs tiquets de au sein du rpartiteur.
Afin dactiver, de dsactiver ou de perturber les services fournis par le rpartiteur,
un attaquant peut modifier de manire inapproprie la configuration du rpartiteur
dentres-sorties. Nous allons reprsenter ces attaques lmentaires par des arcs ti-
quets de au sein du rpartiteur.
Le contrleur de mmoire et les mmoires associes. Ces deux composants matriels combi-
ns forment la mmoire centrale. tant donn le rle crucial jou par la mmoire centrale
dans le fonctionnement dun systme informatique, les sous-systmes de ces compo-
sants peuvent tre les cibles dattaques.
De nombreux composants matriels, notamment le processeur et certains contr-
leurs dentres-sorties, reposent sur des structures de contrle stockes dans la m-
moire centrale pour leur fonctionnement. Toute modification inapproprie de ces
structures peut potentiellement perturber le fonctionnement de ces composants ma-
triels. Nous assimilons ces modifications inappropries des attaques lmentaires
39
Chapitre 2. laboration dun modle dattaques
sur le sous-systme logique des mmoires. Nous allons reprsenter ces attaques l-
mentaires par des arcs tiquets de au sein des mmoires.
Le contrleur de mmoire peut tre reconfigur de faon activer, dsactiver ou
perturber certaines fonctions. Une attaque lmentaire qui peut tre envisage sur
ce composant consiste, par exemple, dsactiver les accs une mmoire. Nous
allons reprsenter ces attaques lmentaires par des arcs tiquets de au sein du
contrleur de mmoire.
Les contrleurs dentres-sorties internes. Ces composants peuvent initier des attaques ou,
au contraire, en tre la cible.
Les contrleurs dentres-sorties qui contiennent un sous-systme logiciel prsentent
potentiellement des vulnrabilits logicielles qui permettent de reprogrammer leurs
fonctions. Des publications rcentes ont prsent des attaques qui reprogramment
un contrleur de clavier [Gazet 11] afin dexploiter une vulnrabilit dans la routine
de traitement des System Management Interrupts (SMI) excute par le processeur
lorsquil est dans le mode System Management (SMM) ou qui modifient distance le
comportement dune carte rseau [Duflot et al. 10] afin de mener des attaques de type
Direct Memory Access (DMA). Nous reprsentons les attaques lmentaires associes
par des arcs tiquets de dans les contrleurs dentres-sorties.
Certains contrleurs dentres-sorties ont la facult de grer eux-mmes leurs trans-
ferts de donnes. Un attaquant peut chercher modifier la configuration de ces
contrleurs dentres-sorties afin de dtourner ces transferts des fins malveillantes
(par exemple, pour modifier le contenu de la mmoire centrale). Nous allons repr-
senter les attaques lmentaires utiliss dans ces scnarios dattaque par des arcs
tiquets de au sein des contrleurs dentres-sorties.
Les contrleurs dentres-sorties externes et les priphriques De la mme faon que pour
les contrleurs dentres-sorties internes, les contrleurs dentres-sorties externes ainsi
que les priphriques peuvent initier des attaques ou en tre les cibles.
tant donn quils sont externes au systme informatique, il est possible deffectuer
des attaques lmentaires tous les niveaux dabstraction de ces composants. Grce
aux micro-contrleurs de plus en plus puissants et aux technologies de logique pro-
grammable, nous pensons en effet quun attaquant peut crer son propre composant
matriel et modeler les parties du composant matriel sa convenance pour perp-
trer des attaques.
Les hypothses dattaque que nous avons formules ont t tablies de faon empirique
et subjective, partir dattaques rfrences dans la littrature et partir dattaques lmen-
taires que nous avons considres plausibles. videmment, pour couvrir davantage dattaques
partir de notre instance de modle, il pourrait tre souhaitable dlargir notre spectre dat-
taques lmentaires. Cependant, lenrichissement dun tel modle impacte obligatoirement sa
lisibilit. Afin de garder une instance de modle suffisamment intelligible et qui permette de
reprsenter les attaques auxquelles nous nous intressons, nous avons dlibrment restreint
le spectre des attaques lmentaires possibles. Par ailleurs, pour simplifier la reprsentation
de notre modle, nous introduisons la notion darc tiquet epsilon (). Les arcs de ce type
reprsentent des oprations effectues de faon transparente par la plate-forme matrielle ou
une suite dactions lmentaires lgitimes susceptibles dtre utilises dans une attaque et que
nous souhaitons mettre en relief pour des raisons de lisibilit. Le mcanisme qui contribue
la cohrence des mmoires caches dans le rpartiteur illustre typiquement ces oprations auto-
matiques. Pour maintenir jour les mmoires caches dans le processeur, le rpartiteur coute
40
2.3. Illustration du modle par plusieurs exemples rels dattaque
continuellement les accs qui transitent sur les bus systmes et compare les adresses des trans-
ferts de donnes avec celles contenues dans les mmoires caches. Lorsquune mmoire cache
requiert la donne transfre, le rpartiteur peut automatiquement mettre jour, et cela de fa-
on transparente, le contenu de cette mmoire. Lajout de ces arcs nous permet alors daffiner
notre modle dattaques en prcisant des interactions complmentaires entre composants ma-
triels issus de notre connaissance de la plate-forme matrielle. Larc tiquet epsilon () reliant
le contrleur dentres-sorties et les mmoires met en exergue, quant lui, les communica-
tions impliques la mise en uvre du mcanisme daccs direct la mmoire. Compte tenu des
hypothses que nous avons formules et des simplifications que nous avons opres, nous ob-
tenons le modle dattaques lmentaires reprsent sur la figure 2.6. Puisque nous navons pas
considres les attaques de type dans notre modle de menaces, il est logique que celles-ci
napparaissent pas sur cette figure.
41
Processeur Rpartiteur Contrleur de mmoire
5
5
Logiciel
3 5 4
4
Configuration 3
Logique Configuration 3
Logique Configuration 3
Logique
4
Communication Communication Communication
2 2
Chapitre 2. laboration dun modle dattaques
42
Processeur Rpartiteur Contrleur de mmoire
5
5
Logiciel
3
2 2
2
4
Configuration Logique 3
Configuration Logique Configuration Logique
Logiciel Logiciel
Attaque par usurpation d'identit Attaque par modification d'une ROM Attaque par modification de la routine
de priphriques USB flashable d'extension PCI de traitement de la SMI
43
2.3. Illustration du modle par plusieurs exemples rels dattaque
mire paire est utilise pour lalimentation du priphrique USB et une autre paire est d-
die la transmission en srie des informations selon une signalisation diffrentielle. Un atta-
quant disposant un tant soit peu de connaissances en lectronique pourrait, sans trop de peine,
construire son propre priphrique USB [Crenshaw 10, Pisani et al. 10, Kennedy 10] ou modi-
fier un priphrique USB existant de faon effectuer des attaques cibles : enregistrement de
frappes au clavier, infection par un maliciel, exploitation dune vulnrabilit particulire du
systme dexploitation, etc. Le dveloppement de ces priphriques malveillants est aujour-
dhui, entre autres, facilit par lexistence de priphriques USB programmables via des micro-
contrleurs toujours plus miniaturiss. En particulier, il est possible de programmer ce type
de priphrique pour agir comme un clavier USB malveillant qui enverrait, par exemple, des
frappes pr-dfinies par lattaquant. Ces frappes pourraient, par exemple, ajouter automatique-
ment un utilisateur au systme ou tlcharger un logiciel malveillant depuis le rseau Internet
avant de lexcuter. Afin de ne pas rvler ses activits et de ne pas veiller les soupons des
utilisateurs, lattaquant ne programme gnralement pas lenvoi de ces frappes la connexion
du priphrique mais attend des vnements particuliers. En connectant un capteur de lumino-
sit au priphrique USB programmable, cet vnement pourrait tre, par exemple, une chute
brutale de la luminosit ambiante que le micro-contrleur dans le priphrique malveillant in-
terprterait comme lextinction dune lampe lorsquon quitte une pice claire. Finalement,
pour convaincre lutilisateur de connecter ce priphrique programmable, il est important de
lencapsuler dans un boitier de priphrique en apparence inoffensif tel quun priphrique de
stockage.
Ainsi, les attaques par usurpation didentit de priphriques USB se droulent gnrale-
ment en plusieurs tapes. Lattaque dbute ds quun utilisateur connecte le priphrique USB
malveillant au systme informatique cibl. Pour les besoins de notre exemple, nous consid-
rons que lidentit dun clavier est ici usurpe. Ce priphrique USB malveillant insre alors
sur les bus USB (transition ) des trames correspondant des frappes au clavier pr-dfinies
par lattaquant. Ces trames sont reues par le contrleur de priphriques USB qui les trans-
fre automatiquement la mmoire centrale (transition ). Celles-ci attendent dtre traites
par un sous-systme logiciel (le systme dexploitation par exemple) excut par le processeur
principal (transition suivie dune transition ).
Un tel scnario dattaque a t mis en uvre par Netragard lors dune opration daudit de
scurit chez lun de ses clients [Desautels 11]. Lobjectif de cet audit tait alors dobtenir laccs
au parc informatique de son client sans faire usage des moyens dattaques habituels tels que
lingnierie sociale par prise de contact direct avec la victime (par exemple, se faire passer pour
ladminstrateur du parc informatique au tlphone), les attaques rseau, les exploitations de
vulnrabilits non-publies (en anglais, zero-day), etc. Leur dmarche a alors consist modi-
fier une souris USB de marque Logitech de faon pouvoir y embarquer un micro-contrleur
mulant un clavier USB. Afin que cette souris se comporte comme une souris standard, les
pen-testers de Netragard ont galement embarqu un concentrateur USB dans la souris modi-
fie auquel taient connects les composants lectroniques de la souris et le clavier malveillant.
Du point de vue fonctionnel, le priphrique se comporte alors comme une souris classique.
Celui-ci renferme cependant galement un clavier malveillant. Une fois mis au point, ils ont
us dingnierie sociale pour infiltrer le priphrique malveillant chez le client. Pour cela, ils
ont soigneusement emball la souris dans son boitier dorigine et lont envoye un employ
de lentreprise cliente en lui laissant croire que ctait un cadeau promotionnel. Ne sachant pas
que la souris contenait un clavier malveillant et la croyant inoffensive, lemploy la connecte
sans hsitation son poste. Une minute aprs la connexion du priphrique, le clavier mal-
veillant commence envoyer des frappes pour tlcharger une porte drobe depuis lInternet
44
2.3. Illustration du modle par plusieurs exemples rels dattaque
et linstaller sur le poste victime. Cette porte drobe est ensuite utilise par lattaquant pour
accder au parc informatique de lentreprise cliente.
Lorsquun ordinateur est mis sous tension, une procdure appele Power-On Self Test (POST)
est charge dinitialiser la plate-forme matrielle. Au cours de cette procdure, le BIOS est
copi dans la mmoire centrale depuis la ROM sur laquelle il tait stocke. Cette image du
BIOS est alors excute par le processeur, entre autres, pour dtecter les diffrents contrleurs
dentres-sorties connects au systme informatique et prparer leur initialisation. tant donn
que chaque modle de contrleur dentres-sorties dispose dune procdure dinitialisation qui
lui est spcifique, les constructeurs implmentent gnralement cette procdure dans une m-
moire ROM additionnelle embarque dans le contrleur dentres-sorties. Cest le cas, en par-
ticulier, des contrleurs dentres-sorties de type PCI ou PCI Express qui stockent cette proc-
dure dans leurs ROM ventuellement sous la forme dun code qui est excut par le BIOS. Ce
code est alors directement crit en langage assembleur pour les systmes informatiques com-
patibles x86 ou dans un langage interprt par le BIOS (par exemple, OpenBoot) dans dautres
types de systmes informatiques. Ce code est galement responsable de lauto-test de la carte
et de lajout de routines dinterruption qui permettent au BIOS dinteragir avec des fonctions
spcifiques au contrleur dentres-sorties.
La plupart des ROM dextension dans les contrleurs dentres-sorties sont aujourdhui
reprogrammables. La procdure pour modifier leur contenu dpend de la technologie utilise
pour les mmoires. Les mmoires EPROM, par exemple, ncessitent en premier lieu que la puce
soit efface par une exposition prolonge des rayonnements ultra-violets avant de pouvoir
tre reprogramme. tant donne que chaque puce doit individuellement tre retire de sa
carte pour tre reprogramme, la mise jour des mmoires EPROM est lourde mettre en
place. Cest la raison pour laquelle de plus en plus de contrleurs dentres-sorties utilisent des
mmoires EEPROM qui, contrairement aux mmoires EPROM, peuvent tre reprogrammes
lectriquement sans que la puce ne soit retire de la carte. Dans ces circonstances, des outils sont
mis disposition par les constructeurs de contrleurs PCI ou PCI Express pour reprogrammer
la ROM dextension du contrleur dentres-sorties depuis le systme dexploitation. Il suffit
donc que lutilisateur dispose des privilges dun administrateur du systme pour dialoguer
directement avec le contrleur dentres-sorties et reprogrammer sa ROM dextension pour y
insrer du code malveillant. Ce code malveillant sera alors excut par le BIOS linitialisation
de la plate-forme et chaque fois quune routine dinterruption du BIOS est appele.
Typiquement, lors dune attaque, lattaquant commence par reprogrammer la ROM dex-
tension utilise par le contrleur dentres-sorties PCI ou PCI Express. En fonction du type
de mmoire, cette reprogrammation est effectue depuis le processeur principal via des appli-
cations ddies (transition ) ou ncessite un dispositif externe (transition ). Lors de lini-
tialisation du systme, le code malveillant insr dans la ROM dextension est recopie auto-
matiquement par le BIOS en mmoire centrale (transition ). Le processeur excute ce code
malveillant qui peut alors altrer dautres lments du sous-systme logiciel, en particulier le
systme dexploitation (transition suivie de transitions ). Le principe de cette attaque a t
publi dans [Heasman 07].
45
Chapitre 2. laboration dun modle dattaques
46
2.4. Limites du modle dattaques
pour lattaquant, qu dclencher une SMI (transition ) afin que le processeur bascule en mode
SMM et excute la routine de traitement de la SMI. Le processeur rcupre alors cette routine
de traitement de la SMI partir du cache et excute le code malveillant fourni par lattaquant
(transition ).
47
Chapitre 2. laboration dun modle dattaques
2.5 Conclusion
Dans ce chapitre, nous avons expliqu la dmarche que nous avons adopte pour laborer
un modle dattaques sur lequel il est possible de sappuyer pour tudier les malveillances dans
un systme informatique. Le modle que nous avons obtenu couvre des scnarios dattaques
qui impliquent ventuellement diffrents niveaux dabstraction dun systme informatique.
Dans notre dmarche, nous avons considr les composants matriels comme des systmes
part entire qui interagissent avec dautres composants matriels, donc dautres systmes, au
travers dune architecture de communication. Naturellement, nous avons modlis ensuite leur
structure interne sous la forme dun graphe de flots de donnes et nous avons dduit, partir
des vecteurs dattaques que nous avons identifis au chapitre 1 (cf. section 1.2), lensemble des
actions lmentaires (et des attaques lmentaires) possibles au sein de ceux-ci. En combinant
cette vision microscopique avec les interactions entre les diffrents composants matriels, nous
avons pu dduire de manire exhaustive lensemble des scnarios dattaques qui sont possibles
dans un systme informatique. Nous avons appliqu cette dmarche un modle de systme
informatique proche de ceux auxquels nos travaux sintressent, savoir les systmes informa-
tiques compatibles PC. Enfin, afin de mieux apprhender le modle dattaques que nous avons
obtenu, nous lavons illustr par plusieurs exemples concrets dattaques.
Au cours de llaboration de notre modle dattaque, nous avons privilgi une approche
de construction du graphe dattaque qui est manuelle. Cette approche est fastidieuse et poten-
tiellement source derreurs. Pour ces raisons, nous avons envisag de travailler sur un outil
qui puisse gnrer automatiquement le modle dattaques dun systme informatique en se
basant sur un moteur dinfrence crit en Prolog [Deransart et al. 96]. Il sera alors possible de
linstancier pour le modle de systme informatique que nous avons considr afin de com-
plter ventuellement le modle dattaques que nous avons tabli en incluant des scnarios
dattaques que nous avons omis dans notre analyse manuelle.
Dans les deux chapitres qui suivent, nous allons mettre en uvre plusieurs attaques issues
de notre graphe dattaque sur des systmes informatiques compatibles PC. Nous allons nous
concentrer en particulier sur les attaques par entres-sorties sur lesquelles relativement peu de
travaux existent dans la littrature. Ces attaques nous permettent alors dintroduire les contre-
mesures matrielles possibles pour sen protger et de discuter de certaines de leurs limites que
nous avons identifies.
48
Chapitre 3
Dans le chapitre prcdent, nous avons tabli un modle dattaques qui peut sappliquer
tout systme informatique. Dans le prsent chapitre, nous appliquons ce modle une architec-
ture matrielle particulire, celle des PC, ce qui nous permettra, dune part, dtudier concr-
tement les diffrentes manires de mettre en dfaut sa scurit et, dautre part, denvisager
plusieurs contre-mesures celles-ci. Larchitecture PC, cre en 1981 par la socit International
Business Machines (IBM), sest impose dans la majorit des systmes informatiques grce aux
principes qui ont guid sa conception : elle est standardise et ouverte, relativement simple
(du moins, elle ltait ses dbuts), bien documente et conue pour quiper spcifiquement
des systmes informatiques sur tagre appels ordinateurs personnels (en anglais, Personal
Computers). Aujourdhui, le fabricant mondial de semi-conducteurs Intel, acteur majeur 15 sur le
march des processeurs et des chipsets, continue faire voluer cette architecture. Nous parlons
alors plus spcifiquement darchitecture matrielle Intel-PC ou, plus simplement, darchitec-
ture Intel-PC. Elle constitue, de nos jours, une des rfrences pour les systmes informatiques
dits compatibles PC. Cest pour cette raison que ce chapitre se concentre spcifiquement sur
celle-ci.
Lapproche que nous prsentons dans ce chapitre pour tudier les attaques issues de notre
modle sapparente lapproche traditionnelle, base sur une analyse de vulnrabilits plutt
empirique : rechercher puis identifier une vulnrabilit, dvelopper une preuve de concept qui
permette de lexploiter et enfin proposer des contre-mesures. Dans le prochain chapitre, nous
proposerons une autre approche, plus systmatique, de recherche des vulnrabilits.
Nous nous intressons, en particulier, aux attaques par entres-sorties, principalement parce
quelles sont trs difficiles dtecter et contrer par logiciel, dans la mesure o elles ne mettent
en jeu ni les processeurs principaux ni mme, au moins dans certains cas, la mmoire centrale.
Pour bien comprendre comment il est possible de mener des attaques par entres-sorties sur
une architecture PC, nous commenons par prsenter, en section 3.1, quelques considrations
techniques sur cette architecture matrielle. Nous rappelons, en particulier, les diffrents es-
paces dadressage et les modes dentre-sortie qui sont supports. partir de l, nous nous
intressons spcifiquement la capacit quont les contrleurs dentres-sorties grer eux-
mmes leurs transferts. Ce mode de communication ntant pas sans risque sur la scurit
15
Une analyse [Trefis 12] publie dans le magazine conomique Forbes [Trefis Team 12] estime, en effet, quIntel a
occup en 2011 prs de 84.3%, 73.8% et 94.5% de parts de march respectivement des ordinateurs portables, des
ordinateurs de bureau et des serveurs. Cette domination se maintient depuis prs de vingt ans.
49
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
du systme informatique, nous pointons la faiblesse structurelle lorigine des attaques par
entres-sorties dans les architectures PC, savoir le manque de contrle daccs sur les entres-
sorties. Nous nous mettons ensuite dans la peau dun attaquant et nous dcrivons plusieurs
attaques de ce type que nous avons identifies laide de notre modle dattaques. Cela fait
lobjet des sections 3.2 et 3.3. Pour chacune delles, nous prsentons plusieurs contre-mesures
logicielles mais aussi et surtout matrielles possibles et nous discutons de leurs limita-
tions respectives. Les rflexions autour desquelles sarticulent ce chapitre ont t prsentes
la journe Scurit des Systmes Logiciels & Sret des Logiciels (3SL) [Lone Sang et al. 11a] et
au sminaire SysSec [Lone Sang et al. 11c] en 2011.
50
3.1. Aperu de larchitecture Intel-PC
Processeur
Cur Cur Cur Cur
bus PCI
bus PCI Express Unit de gestion mmoire
autres bus
bus FSB
bus DMI
Southbridge
Disque Contrleur de disque Direct Media Interface
Haut-parleurs Contrleur audio
RJ45 Contrleur Ethernet Pont PCI Express-PCI Carte FireWire
51
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
fier leurs offres. Pour cette raison, la puce utilise pour le northbridge donne souvent son nom
au chipset. Ainsi, le chipset Q45 reprsent sur la figure 3.1 correspond la puce de northbridge
82Q45.
Les sous-sections suivantes se concentrent sur la manire dont ces composants matriels
interagissent. Nous dcrivons les espaces dadressage dfinis dans larchitecture PC (3.1.2) et
nous rappelons les principaux modes dentre-sortie dans les systmes informatiques (3.1.3).
Espace mmoire
4Go/16Eo Mmoire centrale Espace de
Zones MMIO
Mmoire ou registre configuration
rserves aux
contrleurs de contrleurs PCI et PCIe
PCI/PCIe 16Mo/256Mo
Limite de
la RAM
AGP Video
Espace
Mmoire d'entre-sortie
tendue
1Mo 64Ko
Boot ROM Ports d'E/S
rservs aux
ROMs d'extension contrleurs
Mmoire Vido PCI/PCIe
640Ko
Port de donnes
256 octets
0xCFC-0xCFF
256 octets
Mmoire Port d'adresse 0xCF8-0xCFB
conventionnelle 256 octets
1Ko
Legacy I/O 256 octets
52
3.1. Aperu de larchitecture Intel-PC
peuvent ncessiter dy projeter des registres ou de portions de leur mmoire interne (RAM,
ROM, EEPROM, etc.) afin, dune part, de faciliter les transferts dentres-sorties avec ces com-
posants et, dautre part, de les acclrer. Le chipset rserve alors ces contrleurs dentres-
sorties des fragments de cet espace dadressage et le contrleur de mmoire dans le northbridge,
dans son rle de rpartiteur, rend les accs ces zones dentres-sorties transparents depuis les
processeurs en les aiguillant vers les contrleurs dentres-sorties concerns : les processeurs
y accdent comme ils accderaient la mmoire centrale. Il sagit du mcanisme de Memory
Mapped I/O (MMIO). Afin dviter tout conflit avec la mmoire centrale 17 , ces zones dentres-
sorties sont gnralement positionnes par le gestionnaire de la plate-forme matrielle plus
prcisment, le Basic Input/Output System (BIOS) dans les adresses hautes de lespace m-
moire, au-del des plages rserves la mmoire centrale.
53
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
ter manuellement, chaque composant matriel, les ressources ncessaires leur bon fonction-
nement (par exemple, les plages dadresses, les lignes dinterruption, etc.) et de rsoudre les
conflits qui pouvaient en rsulter. Lespace de configuration des contrleurs PCI et PCI Express
a t introduit spcifiquement pour rsoudre ce problme. Il sagit dun espace dadressage
dans lequel sont projets les registres de configuration des contrleurs PCI et PCI Express.
Leur configuration, qui tait auparavant manuelle, est maintenant laisse au BIOS linitiali-
sation du systme. Cet espace de configuration peut stendre jusqu 16 mgaoctets pour les
architectures avec des bus PCI et jusqu 256 mgaoctets pour celles qui contiennent des bus
PCI Express.
Laccs cet espace dadressage ncessite une adresse particulire forme par la concatna-
tion, dune part, de lidentifiant de bus associ un contrleur dentres-sorties et, dautre part,
de lindex du registre auquel on accde dans ce contrleur. Cet identifiant de bus est ncessaire
au chipset, entre autres, pour reprer physiquement le contrleur sur les bus dentres-sorties et
pour aiguiller laccs de configuration correctement vers celui-ci. Il se compose de trois parties :
un numro de bus, qui est initialis par le BIOS au dmarrage du systme et qui prcise
le bus dentres-sorties auquel le contrleur est physiquement connect ;
un numro de composant (pour le terme anglo-saxon device), qui localise le contrleur
dans un composant matriel (carte dextension, circuit intgr, etc.) de ce bus ;
et un numro de fonction, qui identifie le contrleur dentres-sorties dans ce compo-
sant. Il existe aujourdhui des cartes dextension qui embarquent plusieurs contrleurs
et qui fournissent des services diffrents. titre dexemple, une carte dextension combo
eSATA-USB embarque la fois un contrleur de bus USB et un contrleur de bus eSATA.
Le numro de fonction joue, en quelque sorte, le rle de multiplexeur et permet dinter-
roger lun ou lautre des deux contrleurs.
Dans la littrature, cet identifiant est communment appel identifiant BDF (en rfrence
aux numros de bus, de device et de function) dun contrleur dentres-sorties. Chaque contr-
leur dentres-sorties prend connaissance de lidentifiant BDF qui lui est associ par les requtes
dentres-sorties qui lui parviennent, lesquelles transportent gnralement cette information.
La figure 3.3 prsente lagencement de lespace de configuration dun contrleur PCI. Les
64 premiers octets de cet espace sont organiss de manire standard et les octets restants sont
la discrtion du fabricant du contrleur. Il convient de remarquer que lorganisation de ces
64 octets est identique pour un contrleur PCI Express, ce qui contribue la compatibilit lo-
gicielle entre les deux protocoles de bus. Les systmes dexploitation sappuient sur ces octets
pour identifier et charger les pilotes (en anglais, device drivers) de contrleur dentres-sorties
adquats. Les deux premiers registres, Vendor ID et Device ID, sont essentiels au fonc-
tionnement de ce processus. Ils indiquent respectivement le matricule attribu au fabricant du
contrleur dentres-sorties et le matricule du contrleur dentres-sorties lui-mme. Ces deux
matricules combins identifient de manire unique un modle de contrleur dentres-sorties.
prsent, prtons une attention particulire aux registres Base Address Registers (BAR)
qui contribuent la mise en uvre des mcanismes de MMIO et de PMIO. Cet ensemble de six
registres permettent daffecter dynamiquement les ressources dans lespace dentre-sortie ou
dans lespace mmoire ncessaires aux contrleurs PCI ou PCI Express. la mise sous tension
du systme informatique, chacun de ces registres indique au BIOS lespace dadressage dans
lequel il souhaite projeter des registres, et la taille de mmoire ou de ports contigus quil n-
cessite. Une fois que les bus ont t cartographis et que tous les contrleurs ont t interrogs,
le BIOS calcule un agencement possible des diffrents espaces dadressage. Il attribue alors
chaque contrleur les ressources souhaites et les informe des plages dadresses qui leur ont
t attribues en crivant dans ces mmes registres.
54
3.1. Aperu de larchitecture Intel-PC
0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xA 0xB 0xC 0xD 0xE 0xF
Vendor Device Command Status Rev. Cache Lat. HDR
Register Register Class Code BIST
ID ID ID Line Timer Type
Base Address Register 0 Base Address Register 1 Base Address Register 2 Base Address Register 3
Base Address Register 4 Base Address Register 5 CardBus CIS Pointer Subsystem Subsystem
Vendor ID Device ID
Expansion ROM IRQ IRQ Min Max
Rserv
Base Address Line Pin Gnt. Lat.
Primary Bus Secondary Subordinate Secondary
Number Bus Number Bus Number Lat. Timer
Notons que de nombreux ouvrages ne considrent que deux espaces dadressage : lespace
mmoire et lespace dentre-sortie. Lespace de configuration des contrleurs PCI et PCI Ex-
press est prsent comme un sous-espace des deux autres espaces dadressage. Cette vision
des espaces dadressage est historique. En effet, rappelons que lespace de configuration des
contrleurs PCI et PCI Express a t introduit pour permettre une configuration automatique
des composants matriels. Pour maintenir une compatibilit ascendante entre les processeurs,
il a t dcid de ne pas dfinir dinstructions ddies aux accs cet espace dadressage. Les
accs celui-ci, depuis les processeurs, se font aujourdhui soit par un mcanisme de fentrage
utilisant deux ports dentres-sorties localiss aux adresses 0xCFC-0xCFF (registre de don-
nes) et 0xCF8-0xCFB (registre dadresse), soit par un fragment de lespace mmoire rserv
cet effet. Ces accs, tout comme les accs une zone quelconque de lespace mmoire ou
de lespace dentre-sortie, sont traits par le rpartiteur dans le northbridge. Celui-ci se charge
dmettre sur les bus dentres-sorties les requtes dentres-sorties appropries. La vision pro-
pose dans ces ouvrages sied, par consquent, celle des processeurs mais ne correspond pas
celle des bus dentres-sorties dans laquelle nous distinguons rellement trois espaces dadres-
sage.
Nous identifions jusqu trois modes dentre-sortie dans tout systme informatique : le
mode des entres-sorties programmes, le mode bus-mastering I/O et les interruptions. Cette
sous-section prsente succinctement leurs principales caractristiques.
55
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
3.1.3.3 Interruption
Ce mode dentre-sortie nest pas en soi un mcanisme de transfert de donnes. Nanmoins,
il est intressant de lvoquer car il permet aux processeurs de rpondre des vnements
extrieurs de faon optimale. Une requte dinterruption peut tre mise par un contrleur
dentres-sorties, par exemple, lorsquune donne est disponible dans un priphrique. Lors-
quune telle requte est reue, le processeur concern sinterrompt et sauvegarde le contexte
dexcution de la tche qui vient dtre interrompue dans une pile. Il excute ensuite une
routine particulire charge de traiter cette requte dinterruption. Finalement, il restaure le
contexte dexcution de la tche interrompue pour reprendre son fil dexcution l o il stait
arrt.
Certaines attaques sont susceptibles de dtourner ces modes dentre-sortie des fins mal-
veillantes. Nous parlons alors dattaques par entres-sorties. Quelques exemples de ce type
18
Il est essentiel de ne pas confondre ce mode dentre-sortie avec le mcanisme dentres-sorties Port I/O.
19
Il convient de remarquer que les transferts de donnes avec les priphriques ou dautres composants matriels
(par exemple, les mmoires RAM, les mmoires flash, etc.) se font ncessairement au travers dun contrleur
dentres-sorties qui aura alors mis disposition des mcanismes qui facilitent ces changes.
56
3.2. Contrle des accs directs la mmoire centrale
dattaques apparaissent dans la littrature. Ainsi, la preuve de concept dattaque publie dans
[Wojtczuk et al. 09] dtourne les entres-sorties programmes dans le but de modifier la valeur
dun registre (le registre MCHBAR du chipset) sur lequel repose lexcution dun programme pri-
vilgi (le code SINIT ncessaire la mise en uvre de la technologie Intel TXT). Lexploit a
alors consist positionner ce registre une valeur bien particulire dans le but de modifier
le flot dexcution de ce programme privilgi. Dans [Duflot 07, Rutkowska et Wojtczuk 08],
les auteurs prsentent galement un autre type dattaque bas sur les entres-sorties program-
mes. Avec les seuls privilges dentres-sorties, ils excutent un code malveillant charg de
paramtrer plusieurs mcanismes de traduction dadresses (louverture graphique AGP et le
memory reclaiming) mis disposition par le chipset. Ils les configurent alors de faon rediriger
les accs une rgion de mmoire arbitraire, ne ncessitant pas de privilges particuliers, vers
des rgions de mmoire privilgies dont laccs est contrl par le systme dexploitation par
exemple. Puisque ces mcanismes de traduction dadresses sont transparents pour le systme
dexploitation (et pour les units de gestion de la mmoire dans les processeurs), tout se passe
comme si laccs se faisait vers une rgion de mmoire arbitraire, alors quil seffectue en ralit
vers une rgion de mmoire privilgie. Ce subterfuge leur a permis dacqurir davantage de
privilges dans le systme, notamment ceux du noyau de systme dexploitation.
La suite de ce chapitre se focalise plus particulirement sur les attaques qui exploitent le
mode dentre-sortie bus-mastering I/O. Dans ce mode dentre-sortie, certains transferts de
donnes sont laisss aux contrleurs dentres-sorties de faon dcharger les processeurs de
ces oprations, et ceux-ci peuvent alors se concentrer sur dautres traitements. Lorsquune telle
responsabilit est laisse aux contrleurs dentres-sorties, il parat essentiel, pour la scurit
du systme informatique, de sassurer que ces transferts se droulent correctement et que des
transferts frauduleux ne sont pas susceptibles dtre mis en place linsu dun utilisateur. Or,
jusqu trs rcemment, ni les processeurs, ni le chipset ntaient en mesure doprer ces v-
rifications. Ce manque de contrle daccs sur les bus dentres-sorties fait lobjet des deux
prochaines sections. Nous prsentons plusieurs attaques quil est possible de mener avec des
contrleurs dentres-sorties sur tagre et nous discutons de contre-mesures envisageables
chacune delles. Dans un souci de concision et de clart, nous allons considrer principale-
ment les attaques qui ciblent lespace mmoire. Les concepts sur lesquels elles reposent tant
gnriques, ils pourront tre transposs sans peine dautres espaces dadressage. Ainsi, la
section 3.2 est ddie spcifiquement aux attaques par entres-sorties qui ciblent la mmoire
centrale. Le cas des attaques par entres-sorties qui ciblent la mmoire interne dautres contr-
leurs dentres-sorties sera trait dans la section 3.3.
La plupart des attaques par entres-sorties rfrences dans la littrature ciblent la mmoire
centrale. La prsente section commence par rappeler le principe des accs directs la mmoire
centrale et dtaille le fonctionnement des attaques qui en abusent. Nous prsentons ensuite
plusieurs contre-mesures matrielles qui ont t proposes et nous dtaillons lune dentre elles
pour les architectures PC rcentes. Avec un exemple dattaque lappui, nous montrons que
cette contre-mesure, elle seule, nest pas suffisante pour contrler lensemble des entres-
sorties et nous prconisons lutilisation dune autre contre-mesure qui lui est complmentaire.
57
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
58
3.2. Contrle des accs directs la mmoire centrale
excuts par le contrleur de priphriques USB la dtection dun vnement sur lun de ses
bus (la r-initialisation dun bus USB, le branchement dun priphrique USB, etc.).
Les contrleurs rseau peuvent, de la mme faon, tre dtourns des fins dattaques.
Pour atteindre des bandes passantes de lordre du gigabit sur les liens rseau, ceux-ci reposent,
en particulier, sur le mcanisme daccs direct la mmoire pour changer des trames Ethernet
(reues ou mettre) avec la mmoire centrale. Les attaques typiques impliquant ces contr-
leurs ncessitent de reconfigurer leurs transferts de donnes de faon modifier une rgion de
mmoire avec des donnes reues par le rseau ou, au contraire, exfiltrer des donnes sto-
ckes dans la mmoire centrale vers le rseau. En fonction du contrleur rseau quil utilise, un
attaquant peut rencontrer quelques difficults dordre technique. Un transfert de donnes dans
un contrleur rseau correspond soit la trame qui vient dtre reue depuis le rseau et que
le contrleur rseau copie dans la mmoire centrale, soit une trame qui a t construite par
le systme dexploitation et que le contrleur rseau va lire en mmoire centrale puis mettre
sur le rseau. Lorsquun attaquant dtourne lun de ces transferts pour modifier la mmoire
centrale par exemple, il doit sassurer que les donnes quil souhaite y inscrire correspondent
une trame valide, notamment pour que celle-ci puisse tre commute correctement au travers
du rseau jusquau contrleur rseau sur lequel repose lattaque. Un problme analogue existe
lorsquun attaquant sen sert pour exfiltrer des donnes vers le rseau : les donnes lues en
mmoire doivent galement correspondre une trame valide afin que celle-ci puisse tre com-
mute au travers du rseau jusqu lattaquant. Ces contraintes techniques rendent difficile
lexploitation de ces transferts depuis un contrleur rseau car lattaquant na pas une matrise
sur lintgralit des donnes.
Dans [Wojtczuk et Rutkowska 11b], les auteurs proposent une solution intressante ce
problme. Elle consiste dtourner le mcanisme de scatter-gather embarqu dans les contr-
leurs rseau rcents dans le but de diviser les transferts de donnes en transferts plus petits.
Lattaquant peut alors sarranger, en configurant ce mcanisme, pour que les octets sur lesquels
il na aucune matrise (par exemple, les enttes de la trame Ethernet et du paquet IP) soient lus
depuis (ou copis vers) une rgion de mmoire arbitraire, et que les octets restants sur lesquels
il a une matrise complte soient lus depuis (ou copis vers) la rgion souhaite de la mmoire
centrale. Dans leur preuve de concept, ils mettent en uvre cette solution pour modifier leur
guise les rgions de la mmoire centrale, depuis un contrleur rseau Intel e1000e. Ce mo-
dle de contrleur rseau est aujourdhui prsent dans la majorit des chipsets Intel. Lattaque a
consist envoyer des paquets rseau ping malveillants : les octets correspondant aux en-ttes
des trames Ethernet, des paquets IP et des paquets ping sont copis par le contrleur rseau
dans les tampons de rception du systme dexploitation (afin de le leurrer et le laisser croire
en la rception de paquets rseau normaux) alors que les octets restants sont copis dans une
rgion souhaite de la mmoire centrale et crasent par exemple des structures de contrle du
systme dexploitation.
59
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
standards de bus tels que le FireWire 22 et certaines variantes de lUSB, motivs par des exi-
gences de performances de plus en plus leves, autorisent les priphriques se comporter
la fois en tant que matre et en tant quesclave. Ceux-ci sont susceptibles dtre utiliss des fins
dattaques. M. Dornseif a t pionnier dans ce domaine. Il a prsent, loccasion des conf-
rences PacSec [Dornseif 04] et CanSecWest [Becher et al. 05], plusieurs preuves de concept dat-
taques consistant relier par un cble FireWire, un systme BSD, Linux ou Mac OS un iPod
sur lequel avait t install un systme dexploitation Linux modifi. Lexploit a consist utili-
ser cet iPod pour lire ou modifier lintgralit de la mmoire centrale du systme auquel il tait
connect. Ses travaux ont t complts par [Boileau 06], qui a propos une technique consis-
tant usurper lidentit dun autre priphrique FireWire, pour galement faire fonctionner ces
attaques sur les systmes Windows. Ces travaux en ont inspir dautres : [Martin 07] prsente
plusieurs techniques de compromission de systmes Linux alors que [Aumaitre 08] sest foca-
lis sur les systmes Windows. Des variantes de lUSB, en particulier lUSB On-The-Go (OTG),
fournissent des fonctionnalits similaires au FireWire. [Maynor 05] montre ainsi quun tl-
phone portable peut tre modifi de faon injecter du code en mmoire centrale. Il semble-
rait galement que les priphriques USB 3 puissent commander les contrleurs de priph-
riques auxquels ils sont connects. Cependant, notre connaissance, aucune tude na encore
confirm cette assertion.
60
3.2. Contrle des accs directs la mmoire centrale
frer automatiquement les trames rseau reues qui respectent un certain motif vers la m-
moire centrale. Il a suffit quil envoie des trames rseau forges dune manire spcifique pour
initier lattaque. La modification dun firmware peut galement se faire en cours dexcution,
par exemple, par lexploitation dune vulnrabilit au sein de celui-ci. Rcemment, lquipe de
L. Duflot [Duflot et al. 10] a dmontr la faisabilit dune telle attaque sur plusieurs cartes r-
seau Broadcom NetXtreme. Lun des firmware excut par ce modle de cartes rseau, charg
dimplmenter la fonctionnalit dadministration ASF (Alert Standard Format), contenait une
vulnrabilit de type dbordement de tampon. Ils ont ainsi pu prendre le contrle dun des
processeurs embarqus dans la carte rseau et ils lui ont fait excuter du code arbitraire en lui
envoyant de trames rseau malformes. Cette technique peut aussi tre utilise pour insrer
une porte drobe [Delugr 10].
Les attaques DMA prcites exploitent le manque de contrle daccs dans les architec-
tures PC. Nous rappelons quil est extrmement difficile de dtecter de manire logicielle ces
attaques, dans la mesure o leur mise en uvre ne ncessite pas lintervention des processeurs
principaux. Comme nous allons le montrer dans les sous-sections 3.2.2 et 3.2.3, il est possible
de sen protger au moyen de contre-mesures matrielles. Nanmoins, les contre-mesures ma-
trielles elles-mmes prsentent des insuffisances, et dautres attaques par entres-sorties res-
tent possibles. Ainsi, nous prsentons en sous-section 3.2.4, un exploit consistant injecter des
trames rseau par des accs DMA initis depuis un priphrique FireWire, et ceci en prsence
de mcanismes matriels visant contrler ces accs. Il nous est alors possible de mener tout
type dattaque rseau (par exemple, de lARP spoofing) sans quelles puissent tre dtectes
puisquelles ne laissent aucune trace sur les rseaux.
61
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
appel de fonction. chaque retour de fonction, la valeur de ladresse de retour stocke dans
la pile est compare sa copie. Il est ainsi possible de vrifier que les chemins dexcution du
firmware nont pas t modifis, par exemple suite une attaque par dbordement de tampon.
Dans [Li et al. 11], les auteurs proposent une autre approche dite de remote firmware attes-
tation qui permet, tout instant, de dterminer si un contrleur a t compromis. Il est alors
ncessaire de modifier le firmware excut par le contrleur de faon implmenter le protocole
propos. Dans ce protocole, une entit verifier dans le systme dexploitation lance un dfi au
firmware excut par le contrleur dentres-sorties. Si la rponse au dfi est celle attendue par
lentit verifier, le contrleur est sain. Autrement, il est sans doute compromis et, par prcau-
tion, il peut tre envisag de le dsactiver. Dans un premier temps, un nonce est envoy par le
systme dexploitation au contrleur dentres-sorties. Il est essentiel que celui-ci soit alatoire
pour viter des attaques par rejeu. Ce nonce est utilis par le contrleur dentres-sorties comme
graine pour un gnrateur de nombres pseudo-alatoires. Le contrleur calcule alors la somme
de contrle de sa mmoire, et renvoie le rsultat du calcul au verifier. Ayant une copie de la
mmoire du contrleur dentres-sorties, lentit verifier est en mesure de vrifier la rponse au
dfi et de dterminer si le contrleur a t compromis.
Une dernire solution, propose par J. Rutkowska [Rutkowska 07], concerne de faon gn-
rique toutes les attaques par accs direct la mmoire. Elle consiste reconfigurer le chipset
de faon ce que le northbridge redirige automatiquement tous les accs depuis les contr-
leurs dentres-sorties aux rgions de mmoire que lon souhaite protger vers un autre em-
placement, par exemple vers un autre bus dentres-sorties o un contrleur va ventuelle-
ment pouvoir traiter laccs. cet effet, elle fait se chevaucher une portion des adresses de
la mmoire centrale que lon souhaite protger par les adresses utilises par les contrleurs
dentres-sorties. Cela cre un conflit, qui a un comportement diffrent en fonction de lentit
(processeur ou contrleur) qui effectue laccs. Lorsque les accs vers cette zone sont effec-
tus par un contrleur dentres-sorties, au lieu dtre aiguills vers la mmoire centrale, ils
sont aiguills vers un autre bus dentres-sorties pour tre traits par un contrleur configur
cet effet. En revanche, ils sont bien redirigs vers la mmoire centrale lorsquil sagit dun
accs depuis les processeurs. Une tentative daccs ces rgions de mmoire protges depuis
un contrleur dentres-sorties peut provoquer, par exemple, un blocage complet du systme
lorsque laccs est volontairement aiguill par le chipset vers un emplacement invalide, typi-
quement un bus dentres-sorties o aucun contrleur nest configur pour traiter cet accs.
Cette solution nest malheureusement efficace que pour des rgions de mmoire contigus et
sadapte difficilement aux rgions de mmoire fragmentes.
Les solutions voques prcdemment sadressent de faon vidente des attaques bien
particulires et ne corrigent pas un problme dordre structurel : les accs vers la mmoire
centrale ne sont pas suffisamment contrls. Mme si les travaux publis dans [Rutkowska 07]
semblent ouvrir la voie vers une solution gnrique, il serait prfrable deffectuer le contrle
daccs au niveau de larchitecture matrielle, en particulier par le chipset. Cest en tout cas la
solution qui est adopte dans les chipsets rcents avec lintgration dune Input/Output Memory
Management Unit (I/O MMU) qui est lobjet de la prochaine sous-section.
62
3.2. Contrle des accs directs la mmoire centrale
place des mcanismes de scatter-gather (mcanisme permettant de transfrer des donnes sur
des zones de mmoire non-contigus), ou de pallier certaines limites dadressabilit de la m-
moire physique 23 . Avec lavnement de la virtualisation, les I/O MMUs ont t tendues afin
dassurer galement des proprits disolation. Celles-ci sont indispensables, par exemple, pour
empcher quun attaquant utilise un contrleur dentres-sorties associ un domaine virtua-
lis 24 pour accder frauduleusement (par un accs direct la mmoire) un autre domaine.
Aujourdhui, AMD Virtualization Technology (Vi) et Intel Virtualization Technology for directed
I/O (VT-d) constituent les implmentations dI/O MMU les plus compltes pour les architec-
tures PC 25 . En plus de virtualiser la mmoire physique et de vrifier les accs des contrleurs
celle-ci, ces technologies ont rcemment intgr (depuis lapparition des chipsets SandyBridge)
des fonctions de virtualisation dinterruptions de type Message Signaled Interrupt (MSI).
Dans ce manuscrit, nous allons spcifiquement nous intresser la technologie Intel VT-
d, qui quipe la plupart des chipsets Intel actuels. Au niveau matriel, cette contre-mesure est
compose dunits appeles DMA-Remapping Hardware Units (DRHUs), chacune de ces units
tant charge de virtualiser la mmoire centrale pour un ensemble de contrleurs. Elles sont
toutes localises au sein du rpartiteur (plus prcisment, dans le Memory Controller Hub qui
joue le double rle de rpartiteur et de contrleur de mmoire), ce qui lui permet de bloquer
efficacement tout accs frauduleux la mmoire centrale.
Lactivation de ces units matrielles est laisse la discrtion du systme dexploitation.
Celui-ci les dtecte (et les active) au moyen de structures de contrle (la table ACPI DMA-
Remapping Reporting, ou DMAR pour tre plus prcis) mises en place en mmoire centrale par
le BIOS lors du dmarrage du systme (cf. figure 3.4). Une fois actives, les units matrielles
sont configures au moyen de tables de configuration similaires aux tables des pages utilises
par les units de gestion de la mmoire implantes dans les processeurs. La figure 3.5 rappelle
la logique de parcours de ces tables de configuration par une unit matrielle. De par la posi-
tion de lI/O MMU dans larchitecture matrielle, tout accs la mmoire centrale depuis un
contrleur dentres-sorties est obligatoirement intercept. Lunit matrielle correspondante
commence alors par identifier le contrleur qui la initi laide du champ Requester ID
contenu dans len-tte de la requte. Avec cette mta-donne, elle dtermine ensuite, par une
srie dindirections, o sont localises les tables des pages qui lui sont associes. Laccs est
bloqu par lunit matrielle partir du moment o le contrleur ne dispose pas des permis-
sions de lecture ou dcriture requises. Ce principe de fonctionnement des units matrielles
est similaire celui des units de gestion de la mmoire dans les processeurs qui implmentent
le mcanisme de pagination. Ainsi, par analogie avec ce mcanisme de pagination, les accs
la mmoire centrale seffectuent par une adresse DMA virtuelle qui est traduite en adresse
physique lors du transit dans lune de ces units matrielles.
23
De telles limites existent typiquement lorsque des contrleurs dentres-sorties 32 bits sont connects des systmes
utilisant plus de 4 gigaoctets de mmoire : les rgions de mmoire situes au del des 4 gigaoctets sont inaccessibles
pour ces contrleurs.
24
Trs schmatiquement, un domaine correspond un ensemble de rgions de mmoire ddi une entit. Dans le
cas prsent, lentit est un contrleur dentres-sorties.
25
Il est intressant de noter que des implmentations dI/O MMU existent sur dautres architectures. Citons,
titre dexemples, la technologie Calgary disponible dans les serveurs IBM System X, la DMA Address Relocation
Table (DART) des processeurs PowerPC ou les Peripheral Access Management Units (PAMU) des plate-formes QorIQ
Freescale (architecture Power).
63
DMA-Remapping
Remapping Hardware unit
Table ACPI DMAR Structures[] De nition (DRHD)
Signature: "DMAR" DRHD Type: DRHD
Length DRHD
Revision
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
64
3.2. Contrle des accs directs la mmoire centrale
De par sa position dans larchitecture matrielle, lI/O MMU apporte indniablement une
solution aux attaques par accs direct la mmoire centrale, en sassurant notamment quil
est impossible aux contrleurs deffectuer des transferts de donnes vers une adresse mmoire
non autorise. Cependant, il est important de vrifier que son implmentation est fiable et
quelle reste incontournable pour que cette solution soit efficace. En effet, il serait problma-
tique quun attaquant puisse la reconfigurer, la dsactiver ou contourner son contrle daccs.
Afin de nous en assurer, nous avons tudi en dtail son fonctionnement. Cette analyse a no-
tamment rvl plusieurs limitations quun attaquant peut utiliser pour contourner le contrle
daccs mis en uvre sur les bus dentres-sorties. Les rsultats de cette analyse ont t publis
en 2010 au Symposium sur la Scurit des Technologies de lInformation et des Communica-
tions (SSTIC) [Lone Sang et al. 10a] et lInternational Conference on Malicious and Unwanted
Software (MALWARE) [Lone Sang et al. 10b].
Contrle daccs configurable par du logiciel. Comme la plupart des composants de larchi-
tecture PC (GDT, IDT, etc.), la configuration dIntel VT-d repose sur des structures de contrle
stockes dans la mmoire centrale. Un jeu de tables de configuration plusieurs niveaux din-
direction est en effet utilis pour dfinir la politique de contrle daccs appliquer chaque
contrleur dentres-sorties. La protection de ces parties critiques contre dventuelles actions
malveillantes est la charge du noyau de systme dexploitation. Or, les systmes dexploita-
tion sont rarement exempts de failles de scurit. Lorsque ces failles sont exploitables, lint-
grit du noyau peut tre compromise, tout comme les structures quil protge. La modification
de ces structures peut permettre un attaquant, par exemple, de contourner certaines des pro-
tections du systme. Pour protger efficacement ces structures, il est ncessaire de sappuyer
sur des moyens de protection sexcutant un niveau plus privilgi que le noyau lui-mme.
[Lacombe et al. 09] proposent pour cela une approche base sur la prservation de contraintes
sappuyant sur les extensions de virtualisation matrielles pour empcher toute atteinte lin-
tgrit du noyau en mmoire, mais galement de certains lments de son support de contrle
(registres des processeurs, du chipset, etc.).
65
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
tables ACPI afin quelle reste cohrente. Une solution plus simple consisterait rendre inco-
hrente uniquement la table DMAR correspondant lI/O MMU de faon ce que le systme
dexploitation ne puisse pas activer correctement cette contre-mesure matrielle.
Utilisation de mta-donnes fournies par les contrleurs. Le fait dutiliser des mta-donnes
fournies par les contrleurs dentres-sorties pour dterminer la politique de scurit appli-
quer ce contrleur peut tre ventuellement utilis pour contourner le contrle daccs dIntel
VT-d. Puisquaucun contrle nest effectu sur le champ Requester ID, il est sans doute en-
visageable, pour un contrleur dentres-sorties, dacqurir les mmes droits daccs la m-
moire quun autre contrleur, par exemple, en usurpant son identit. Il suffit pour cela que le
contrleur malveillant remplace son identifiant BDF par celui dun autre contrleur dans le
champ source (Requester ID) des requtes quil met (cf. sous-section 3.2.4).
Par ailleurs, Intel VT-d prvoit lutilisation de device-IOTLBs implmentes au niveau des
contrleurs dentres-sorties. Les device-IOTLBs dsignent des mmoires caches mises en uvre
dans les contrleurs dentres-sorties. Ces mmoires caches servent stocker, au sein des contr-
leurs dentres-sorties, les traductions dadresses DMA virtuelles que le DRHU effectue fr-
quemment pour ceux-ci. Il permet aux contrleurs dentres-sorties deffectuer eux-mmes les
traductions dadresse pour leurs accs directs la mmoire. Pour informer lI/O MMU que
ladresse virtuelle a dj t traduite, le contrleur dentres-sorties renseigne un drapeau d-
di dans len-tte de la requte daccs direct la mmoire quil effectue. la rception dun tel
accs, lunit matrielle correspondante la relaie directement au contrleur auquel il est destin
(gnralement, le contrleur de mmoire) sans effectuer de vrification supplmentaire. Cette
fonctionnalit peut alors tre dtourne par des contrleurs dentres-sorties malveillants pour
contourner le contrle daccs mis en place au travers des tables de traduction dIntel VT-d.
Heureusement, cette fonctionnalit peut tre dsactive au niveau du chipset.
Quelques-unes des limitations que nous venons de prsenter ont t exploites pour des
attaques. Dans [Wojtczuk et Rutkowska 11b], les auteurs se sont notamment focaliss sur celles
qui peuvent tre mises en uvre par un rootkit sexcutant sur les processeurs. A contrario,
nous allons nous intresser, dans la suite, aux attaques qui sont inities depuis les contrleurs
dentres-sorties, en particulier au moyen des mta-donnes quils fournissent lI/O MMU.
66
3.2. Contrle des accs directs la mmoire centrale
manque, le pont PCI Express-PCI traduit les requtes PCI au format PCI Express en insrant
son identifiant BDF comme Requester ID avant de les relayer sur le bus PCI Express.
Du fait de ce mcanisme, tous les accs effectus par les contrleurs PCI appartenant un
mme bus sont vus sur les bus PCI Express comme effectus par le pont PCI Express-PCI.
Puisque les accs de ces contrleurs possdent le mme Requester ID, les DRHU les asso-
cient au mme domaine de protection et donc aux mmes rgions de la mmoire centrale. On
comprend ds lors que des problmes de scurit lis au partage de ressources (confidentia-
lit, intgrit, disponibilit) peuvent sen suivre : un contrleur malveillant peut tirer partie de
cette situation pour accder et altrer les rgions de la mmoire centrale utilises par un autre
contrleur dentres-sorties. Nous parlons alors dattaques par partage didentifiants.
Lexploitation dun tel vecteur dattaque nest cependant pas triviale et ncessite la rsolu-
tion dun certain nombre de contraintes, la premire tant que le systme sur lequel se droule
lattaque doit possder au moins un bus PCI. Il se trouve que beaucoup dordinateurs de bu-
reau disposent encore aujourdhui dau moins deux connecteurs dextension PCI 26 . Ces deux
connecteurs sont gnralement connects au mme bus. Dans la mesure o des contrleurs
sont branchs ces connecteurs, lattaque que nous venons de dcrire peut tre mise en uvre
sur cette population dordinateurs.
Lattaquant doit galement localiser prcisment les rgions de mmoire utilises par les
contrleurs dentres-sorties qui partagent la mme identit sur les bus PCI Express. Ce type
dattaque peut senvisager aisment dans une entreprise. En effet, il nest pas rare dans les
grandes entreprises que le parc informatique soit compos de machines identiques (cest--
dire, avec la mme configuration matrielle, avec un systme dexploitation identique, etc.).
Un employ malveillant pourrait alors mettre au point une attaque par partage didentifiants
sur sa propre machine. Les machines tant identiques, il pourra sans trop de peine la rejouer sur
dautres machines. Le scnario dattaque suivant reste plausible : pour attaquer ses collgues
(et en particulier son suprieur hirarchique), un employ malveillant peut par exemple pro-
grammer lattaque dans un priphrique malveillant (un iPod par exemple) puis prtendre que
celui-ci contient un document prsentant un intrt pour la personne cible (par exemple, un
rapport de runion, une musique, etc.) afin que celle-ci le connecte, dclenchant ainsi lattaque.
Afin dillustrer cette vulnrabilit, nous avons dvelopp une preuve de concept qui re-
prend le scnario dattaque ci-dessus et une vido de dmonstration de cette attaque est dis-
ponible [Lone Sang et al. 10]. Dans celle-ci, nous profitons du fait quune carte rseau et une
carte FireWire sont connectes au mme bus PCI. Nous utilisons alors la carte FireWire (pilote
par un iPod modifi pour initier des accs DMA) afin dinjecter des trames rseau au sein des
rgions de la mmoire centrale utilises par la carte rseau pour dlivrer ces trames au systme
dexploitation. Linjection de paquets ARP malveillants nous a alors permis de dtourner une
communication, en loccurrence un flux vido. Le lecteur curieux pourra trouver davantage de
dtails sur lattaque que nous avons dveloppe en annexe A.
67
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
aux diffrents contrleurs dentres-sorties serait faite de manire stricte. Nous prconisons
cette solution court terme. Une solution long terme consisterait passer de larchitecture
matrielle hybride actuelle vers une architecture uniforme nutilisant plus que du PCI Express.
Cela conduirait la suppression des ponts PCI Express-PCI et, par consquent, la suppression
de la fonctionnalit que nous avons exploite.
Le problme li au partage didentifiants sur les bus PCI soulve un autre problme plus
large et plus proccupant : les attaques qui consistent usurper de manire dlibre liden-
tit dun autre contrleur. La technologie Access Control Services a t dfinie pour rpondre
ce problme. Il sagit dune technologie de contrle daccs disponible uniquement sur cer-
tains contrleurs de bus PCI Express (son implmentation tant optionnelle). Il est possible de
mettre en uvre les ACS pour vrifier systmatiquement si lidentit du contrleur qui effectue
laccs est correcte et bloquer son accs ds lors quune usurpation didentit est dtecte. Il est
important de prciser que ce contrle daccs ne se focalise pas que sur les requtes daccs la
mmoire mais sapplique indiffremment tout type de transaction PCI Express (cest--dire,
tous les accs dentres-sorties). Ces fonctionnalits matrielles sont relativement rcentes et
commencent tre intgres aux nouveaux chipsets. ce jour, elles sont mises en uvre uni-
quement dans des composants situs dans le northbridge. Nous esprons que les prochaines
gnrations de chipsets proposeront leur mise en uvre au sein du southbridge afin de mieux
contrler les bus dentres-sorties. Le support de la technologie ACS par un contrleur se mani-
feste par la prsence dun groupe de registres projet dans son espace de configuration, nomm
ACS Extended Capability. Le systme dexploitation repose sur les registres ACS_CAPABILITY et
ACS_CONTROL respectivement pour lister lensemble des services implments par un contr-
leur et pour les activer. Le tableau 3.1 prsente lensemble des services prvus par le standard
PCI Express.
En faisant lhypothse que lensemble des contre-mesures matrielles que nous venons de
dcrire soient actives et mises en uvre par des systmes dexploitation fiables, il sera sans
doute difficile quun attaquant russisse encore mettre en place des attaques par accs direct
la mmoire centrale sans quelles ne soient dtectes et contres. En effet, tant situe au plus
prs de la mmoire centrale, lI/O MMU doit empcher en particulier que des accs frauduleux
cette mmoire ne soient possibles. Les extensions ACS la compltent en veillant ce quau-
68
3.3. Contrle des accs pair--pair
cun contrleur dentres-sorties ne puisse usurper lidentifiant dun autre contrleur dans le
but dobtenir les mmes privilges que celui-ci la mmoire centrale. Cependant, ces contre-
mesures ne sont pas directement efficaces contre les attaques par accs pair--pair prsentes
dans la prochaine section.
69
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
ment) porter sur lespace mmoire, sur lespace dentre-sortie ou sur lespace de configuration
de contrleur PCI et PCI Express. Les attaques qui abusent des accs pair--pair cherchent
exploiter directement les ressources fournies par le matriel, tout en contournant les ventuels
mcanismes de protection mis en place par le systme dexploitation. En pratique, seuls les ac-
cs pair--pair au travers de lespace mmoire sont actuellement exploits par des attaquants,
en raison de la lenteur des transferts quimpliquent les autres espaces dadressage. Du point
de vue des bus dentres-sorties, ceux-ci sont identiques en tout point aux accs directs la
mmoire centrale, et seules les adresses utilises pour chaque type daccs diffrent. Cest pour
cette raison quaujourdhui la plupart des attaques par accs pair--pair se focalisent sur les-
pace mmoire et sont linitiative soit des processeurs, soit des contrleurs dentres-sorties,
soit des priphriques.
M. Dornseif a probablement t lun des premiers dmontrer la faisabilit de telles at-
taques. Pour illustrer ses travaux publis dans [Dornseif 04], il a dvelopp une preuve de
concept dattaque par accs pair--pair au travers de lespace mmoire dans laquelle il modifie
le framebuffer dune carte graphique depuis un iPod connect via le bus FireWire. Des scna-
rios dattaque plus complets ont t dvelopps par A. Triulzi. La modification du firmware
dune carte rseau lui a permis de transfrer les trames respectant un certain motif dans la m-
moire interne de la carte graphique, o a t implant un serveur shell scuris [Triulzi 08a]. Il
a ensuite tendu ses travaux en montrant que cet accs distant peut tre utilis pour charger,
depuis la carte graphique, un nouveau firmware, tlcharg depuis lInternet, dans une autre
carte rseau [Triulzi 10b]. Ce firmware spcifique lui a permis daltrer le comportement de la
carte rseau de faon ce que certaines trames soient directement transfres vers une autre
carte rseau, contournant ainsi tout filtrage de paquets mis en uvre au sein du systme dex-
ploitation.
Les travaux de M. Dornseif et dA. Triulzi se sont a priori focaliss sur lancienne architec-
ture PC, dans laquelle le chipset est bas sur un bus systme PCI. tant physiquement un bus
partag, nous concevons que les accs pair--pair puissent se faire sur un bus PCI. Toutefois, les
bus dentres-sorties dans les architectures PC actuelles ne reposent plus sur le protocole PCI
mais implmentent le protocole PCI Express (cf. figure 3.1), qui est beaucoup plus performant.
Chaque contrleur dentres-sorties est alors reli par un lien ddi un pont PCI Express
qui se charge dmuler une topologie de bus partag. Dans cette configuration de bus, il nest
pas clair que les accs pair--pair soient possibles de la mme faon que pour les bus PCI. Il
peut tre envisag, par exemple, dappliquer une politique de filtrage au niveau de ce pont.
Dans le but davoir une meilleure connaissance de larchitecture PC actuelle et par l-mme
une meilleure matrise de la scurit du systme, nous avons men une tude pour identifier
quels sont les accs pair--pair possibles dans les chipsets rcents. Cela est lobjet de la prochaine
sous-section.
70
3.3. Contrle des accs pair--pair
avons effectu deux fois les tests avec le contrleur FireWire PCI. Dans le premier test, nous
avons laiss intacte la configuration du chipset. Pour le second, marqu par le signe y dans le
tableau, nous avons modifi volontairement la configuration du southbridge 27 . Il est sans doute
possible aussi pour un attaquant daltrer la configuration du pont PCI Express-PCI depuis un
contrleur dentres-sorties si celui-ci est capable de gnrer des requtes de configuration sur
les bus dentres-sorties.
Lanalyse de la table 4.3 nous permet didentifier les transactions pair--pair, et donc les
ventuelles attaques par accs pair--pair, quil est possible de mettre en place dans la majorit
des chipsets actuels. lexception du chipset Intel x58, nous constatons que les chipsets que nous
avons tudis dcrivent des comportements similaires. Au sein du northbridge, seules les re-
qutes dcriture entre contrleurs sont possibles. Pour aller plus loin dans notre analyse, nous
pouvons prciser quels canaux de communication il est possible dtablir. Les requtes dcri-
ture entre deux contrleurs PCI Express connects au northbridge semblent tre autorises. Il en
va de mme pour les requtes dcriture du contrleur DMI vers un contrleur PCI Express. En
revanche, la situation inverse nest pas possible : toute criture depuis le northbridge dans un
contrleur connect au southbridge est bloque. Ces diffrents accs pair--pair sont particuli-
rement intressants pour amliorer les performances des applications de calcul scientifique sur
cartes graphiques. Il est possible, par exemple, dexploiter ces fonctionnalits pour charger des
donnes, issues de contrleurs de disque ou de contrleurs rseau par exemple, directement
dans la mmoire de la carte graphique afin que cette dernire puisse les traiter, rduisant ainsi
la dure des transferts dentres-sorties. Soulignons, cependant, que les composants logiciels
actuels (par exemple, les pilotes, les bibliothques graphiques, etc.) ne sont pas conus pour
profiter de ces mcanismes et quil est probablement ncessaire dy effectuer des changements
consquents pour cela. Du point de vue dun attaquant, la restriction aux requtes dcriture
au sein du northbridge limite normment les possibilits dattaque. Lattaquant doit connatre
a priori la configuration du chipset afin de localiser les zones o crire. Par ailleurs, comme il ne
peut pas faire de lecture vers les contrleurs dentres-sorties, il na aucun retour direct sur la
russite ou lchec de son attaque.
Nos exprimentations sur diffrents modles de southbridge montrent que les rsultats sont
cohrents dun chipset lautre. Il est possible dtablir un canal de communication depuis
un contrleur dentres-sorties quelconque vers un contrleur du northbridge. Les requtes
autorises entre ces contrleurs sont ensuite dfinies par le northbridge. Les contrleurs PCI
peuvent galement communiquer directement entre eux puisquils sont connects au mme
bus dentres-sorties. Finalement, il est possible deffectuer, depuis ces mmes contrleurs, des
requtes de lecture et dcriture vers dautres contrleurs PCI Express ds lors que la confi-
guration initiale du pont PCI Express-PCI a t altre pour les permettre. Le southbridge est
alors plus enclin que le northbridge autoriser les accs pair--pair. Pour ces raisons, il est plus
intressant, du point de vue dun attaquant, dexploiter un contrleur connect au southbridge
pour effectuer des attaques par accs pair--pair.
La possibilit deffectuer des accs pair--pair au sein du chipset rsulte probablement dun
choix de conception, li aux diffrents cas dutilisation que nous pouvons imaginer. Cependant,
nous avons remarqu, au cours de nos exprimentations, que ces accs, bien que lgitimes, sont
dans certains cas trop permissifs et peuvent induire, par consquent, des problmes de scurit.
27
titre informatif, nous donnons la commande que nous avons utilise pour cela : setpci -s
<identifiant du pont> 0x4c.b=6. Cette commande modifie un des registres du pont PCI Express-PCI proje-
ts dans lespace de configuration de faon ce quil transmette aux autres contrleurs les requtes pair--pair issues
des contrleurs PCI. Le lecteur est invit se rfrer aux spcifications des chipsets pour obtenir plus dinformations
sur les modifications opres par cette commande.
71
Chipset Northbridge Southbridge Modle de machine
Machine 0 Intel Q35 MCH 82Q35 ICH9 DELL Optiplex 755 (Desktop)
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
Machine 1 Intel Q45 MCH 82Q45 ICH10 DELL Optiplex 960 (Desktop)
Machine 2 Intel 945GM GMCH 945GM ICH7-M MacBook Pro A1150 (Laptop)
Machine 3 Intel Q45 Mobile GMCH GM45 ICH9-M DELL Latitude E6400 (Laptop)
Machine 4 Intel x58 IOH x58 ICH10 Machine assemble (Desktop)
TABLE 3.2 Liste des chipsets expriments
XXXXX Machine 0, Machine 1 Machine 2, Machine 3 Machine 4
X
Source
XXX
Destination
XX
Northbridge
CG
Southbridge
CU CD CP CR CPe
Northbridge
CG
Southbridge
CU CD CP CR
Northbridge
CG
Southbridge
CU CD CP CR CPe
Northbridge FireWire PCIe W - - - - - W - - - - RW RW RW RW RW RW
FireWire PCIe W - - - - NA W - - NA - RW - - - - -
Southbridge FireWire PCI W - - RW - - W - - RW - RW - - RW - -
FireWire PCIy W RW RW RW - RW W RW RW RW - RW RW RW RW - RW
Lgende : CG pour contrleur graphique CU pour contrleurs USB CPe pour contrleur PCI Express
CD pour contrleurs de disques CP pour contrleur PCI CR pour contrleur rseau
R pour lecture russie W pour criture russie NA pour non-applicable (slots insuffisants)
XX pour contrleur intgr au chipset PCIy pour configuration du pont PCIe-PCI modifie (bit Peer Decode Enable activ)
TABLE 3.3 Rsultats exprimentaux
72
3.3. Contrle des accs pair--pair
En effet, le chipset vrifie uniquement quun composant est autoris communiquer avec un
autre composant. Aucune restriction nexiste quant au contenu auquel le contrleur malveillant
accde. Sur certains chipsets, nous avons pu, par exemple, provoquer lextinction du moniteur
en crivant, depuis un contrleur FireWire, dans les registres de la carte graphique.
Naturellement, nous avons implment plusieurs preuves de concept afin de montrer ce
qui est ralisable en pratique avec cette classe dattaque. Dans une premire preuve de concept,
nous avons exploit les accs pair--pair depuis un contrleur malveillant (par exemple, une
carte FireWire, une carte rseau) pour accder la mmoire vido dune carte graphique. Dans
le principe, cette attaque est similaire celle propose par M. Dornseif [Dornseif 04]. Toute-
fois, le fait que nous nous sommes restreints uniquement des oprations de lecture et que
nous avons droul notre attaque sur des chipsets intgrant davantage de moyens de protection
distingue notre preuve de concept de celle quil a prsente. Une vido prsentant la mise en
uvre de lattaque est disponible [Lone Sang et al. 11b] : nous attaquons une carte graphique
depuis un contrleur FireWire, pilot depuis un priphrique malveillant (ici, un ordinateur
portable). Par ce moyen, nous recopions le contenu de lcran de la machine cible et nous rus-
sissons rcuprer les identifiants ainsi que les mots de passe des utilisateurs affichs lcran.
Les dtails de notre preuve de concept sont fournis en annexe B.
Une autre preuve de concept que nous avons mise au point exploite la possibilit deffec-
tuer des accs pair--pair vers lespace dentre-sortie. Bien que celui-ci soit aujourdhui peu
usit, nous observons que des contrleurs (le contrleur de clavier, les contrleurs VGA, SATA,
USB, etc.) continuent y projeter certains de leurs registres. Le contrleur de clavier projette,
par exemple, des registres aux adresses 0x60 et 0x64 qui informent le systme dexploitation
des vnements du clavier ou de la souris. Nous avons exploit la possibilit de lire ces ports
dentres-sorties depuis un contrleur dentres-sorties pour implmenter un enregistreur de
frappe au clavier. Actuellement, nous sommes capables denregistrer les frappes de claviers de
type PS/2 et ventuellement des claviers de type USB lorsque loption USB Legacy Support 28
est active dans le BIOS. Le lecteur intress pourra consulter lannexe C pour plus de dtails
sur la mise en uvre de lattaque et une vido prsentant la mise en uvre de notre preuve de
concept est disponible [Lone Sang et al. 12a].
73
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
thbridge, transite obligatoirement par lI/O MMU. Ainsi, ces changes peuvent tre contrls.
Il en va de mme pour la situation inverse, cest--dire que toute communication destina-
tion dun composant du northbridge est galement matrise. En revanche, lorsque les changes
nimpliquent que des composants situs dans le southbridge, lI/O MMU nest daucun secours.
En effet, comme ces changes seffectuent en interne dans le southbridge, ceux-ci ne transitent
aucun moment dans lI/O MMU. Pour cette raison, les requtes ne peuvent pas tre contr-
les. Il est assez simple de vrifier cela sur les modles de southbridge actuels en mettant en
place un transfert pair--pair dun contrleur PCI vers dautres contrleurs du southbridge. Afin
de contrler entirement les communications au sein du chipset, il serait envisageable davoir
plusieurs I/O MMU (par exemple, une dans le northbridge et une dans le southbridge) places
au plus prs des contrleurs dentres-sorties et non au plus prs de la mmoire centrale. Ce-
pendant, cette solution rend encore plus complexe larchitecture matrielle rsultante car il est
ncessaire que les I/O MMUs se fassent mutuellement confiance : si une premire I/O MMU
a dj effectu un contrle daccs sur une requte, la seconde I/O MMU peut ne pas vrifier
une seconde fois le mme accs. Ds lors quune des I/O MMUs est corrompue, la scurit du
systme peut tre remise en question.
Une autre manire de se protger serait, par exemple, de rediriger systmatiquement toutes
les communications internes au southbridge vers le northbridge pour que celles-ci soient vrifies
par lI/O MMU. Bien que cette solution puisse dgrader les performances, cest vers cette lo-
gique quvolueront les prochaines gnrations de chipsets grce lextension Access Control
Services dfinie dans le standard PCI Express. La mise en uvre de ces extensions au sein du
southbridge permet de dfinir des comportements diffrents vis--vis des communications entre
contrleurs dentres-sorties. Par exemple, la mise en place de lACS Upstream Forwarding au
sein du southbridge implique de rediriger vers le northbridge toutes les requtes internes au sou-
thbridge. Ces requtes peuvent tre contrles ds lors quune I/O MMU est active au sein
du northbridge, puis tre r-aiguilles par la suite au southbridge. Il est galement possible de
bloquer systmatiquement toute communication entre contrleurs dentres-sorties connects
au southbridge en activant lACS P2P Egress Control.
3.4 Conclusion
La motivation principale qui nous a conduits llaboration dun modle dattaques est
dtudier les diffrentes manires pour un attaquant de mettre en dfaut la scurit dun sys-
tme informatique. Dans ce chapitre, nous avons instanci notre modle dattaques pour une
architecture de systme informatique particulire, larchitecture PC, sur laquelle sappuie la
majorit des systmes informatiques daujourdhui. Afin de mieux cerner les attaques par
entres-sorties qui nous intressent particulirement, nous avons commenc par rappeler quelques
considrations techniques sur cette architecture matrielle. partir de l, nous avons tudi un
sous-ensemble de ces attaques : les attaques impliquant les contrleurs dentres-sorties et qui
exploitent leur capacit grer eux-mmes leurs transferts de donnes. Nous avons alors fait
apparatre la faiblesse structurelle lorigine de ces attaques dans les architectures PC, savoir
le manque de contrle daccs sur les entres-sorties. Dans le but de mieux nous rendre compte
de celle-ci, nous nous sommes mis dans la peau dun attaquant. Nous avons dcrit la mise en
uvre de quelques attaques et nous avons prsent plusieurs contre-mesures chacune delles.
Jusqu prsent, nous avons suivi une approche traditionnelle danalyse dun systme in-
formatique consistant rechercher et identifier une vulnrabilit, dvelopper une preuve de
concept dexploitation de la vulnrabilit pour finalement proposer des contre-mesures celle-
74
3.4. Conclusion
ci. Cette approche sest avre fructueuse. En effet, elle nous a permis didentifier plusieurs
vulnrabilits qui sont susceptibles dtre exploites sur les systmes PC rcents pour effectuer
des attaques par entres-sorties. Il convient, cependant, de nuancer ce bilan, compte tenu des
difficults lies la mise en uvre dune approche danalyse de vulnrabilits traditionnelle,
quel que soit le systme cible. Il sagit, tout dabord, dune approche extrmement chrono-
phage. La consquence immdiate cela est que toute analyse ne peut gnralement couvrir
quune infirme partie du systme cible. Par ailleurs, les rsultats obtenus par cette approche
varient gnralement en fonction de lexprience et de lintuition de lanalyste. Afin de cou-
vrir plus rapidement davantage de bogues potentiels (et ventuellement, davantage de vul-
nrabilits potentielles) dans le matriel, il parat essentiel dadopter une dmarche plus sys-
tmatique danalyse de vulnrabilits. Cela fait lobjet du chapitre suivant. cet effet, nous
avons dvelopp un contrleur spcifique capable de gnrer tout type de trame sur les bus
dentres-sorties. Entre autres, ce contrleur va nous permettre dobtenir les mmes pouvoirs
quun attaquant installant une porte drobe dans le contrleur quil conoit ou dans lequel il
a dcouvert une vulnrabilit le lui permettant.
75
Chapitre 3. Mise en uvre dattaques par entres-sorties sur une architecture PC
76
Chapitre 4
Dans le chapitre prcdent, nous avons suivi la dmarche classique en analyse de vuln-
rabilits consistant dcouvir une vulnrabilit, implmenter une preuve de concept, puis
proposer des contre-mesures. Ce chapitre dcrit une autre approche, complmentaire lap-
proche empirique adopte jusquici, qui devrait permettre de dcouvrir les vulnrabilits de
faon systmatique. Elle sinspire des techniques de recherche de vulnrabilits dans les com-
posants logiciels et consiste injecter des fautes directement sur les bus dentres-sorties. Nous
couvrons ainsi un spectre plus large de vulnrabilits : les vulnrabilits dans les composants
matriels et aussi, dans une certaine mesure, les vulnrabilits logicielles.
La mise en uvre de cette approche ncessite, en premier lieu, un outil dinjection de
fautes qui agisse au niveau des bus dentres-sorties. Un tel outil peut tre obtenu de diff-
rentes manires. La premire consiste altrer le systme logiciel excut par un contrleur
dentres-sorties sur tagre, par exemple en modifiant son firmware ou en exploitant une vul-
nrabilit au sein de celui-ci. Pour cette approche, il est ncessaire de sassurer au pralable
que le contrleur dentres-sorties permette au firmware excut de gnrer tout type daccs
dentres-sorties, en particulier des accs dentres-sorties invalides vis--vis des spcifications
des bus dentres-sorties. La plupart des contrleurs dentres-sorties qui offrent une telle pos-
sibilit ne permettent gnralement deffectuer que les accs dentres-sorties les plus usits et
nautorisent, dans le meilleur des cas, que la modification de certains paramtres de ces accs.
Cette approche nest alors pas adapte une tude exhaustive des attaques par entres-sorties.
linstar de lAgilent U4305A PCIe Exerciser [Agilent Technologies 12] et du LeCroy Summit z3-
16 Exerciser [LeCroy Corporation 12], il existe des quipements commerciaux ddis aux tests
et la vrification dimplmentations de standard de bus dentres-sorties. Il est probable que
ces quipements permettent galement de faire de linjection de fautes sur les bus dentres-
sorties. Malheureusement, ils sadressent gnralement un march de niche et restent trs
onreux 29 . Ainsi, seuls les fabricants de chipsets, les fabricants de cartes-mre et un nombre
restreint de fabricants de contrleurs dentres-sorties peuvent se permettre dinvestir dans un
tel quipement. Finalement, lapproche la moins onreuse consiste concevoir soi-mme un
tel outil. Aujourdhui, le dveloppement dun tel outil est facilit, entre autres, par les cartes de
dveloppement qui embarquent des technologies de logique programmable tels que les FPGA.
Cette dernire approche sest naturellement impose pour nos travaux.
29
Une carte Agilent U4305A PCIe Exerciser cote elle seule 13 065 euros. Cette carte ncessite lacquisition dune suite
logicielle dont la licence slve 27 318 euros.
77
Chapitre 4. Application des techniques de fuzzing sur les bus dentres-sorties
Une fois loutil dinjection de fautes mis au point, une seconde tape consiste simuler,
laide de celui-ci, un ensemble dattaques par entres-sorties. La mise en uvre de ces attaques
peut tre effectue manuellement : un oprateur humain dfinit alors les entres de test et les
excute une par une sur le systme sous test. Cette faon de procder est fastidieuse et sujette
aux erreurs. Aussi, une mise en uvre au moins partiellement automatise est prfrable.
Ces deux aspects font lobjet de ce chapitre qui sorganise comme suit. Nous commenons
par prsenter loutil dinjection de fautes sur les bus dentres-sorties que nous avons dve-
lopp au cours de nos travaux. Nous avons nomm notre prototype IronHide. Celui-ci est
capable de gnrer tout type daccs valides mais surtout invalides sur les bus dentres-
sorties. Il se prsente comme un contrleur dentres-sorties classique. Nous explorons ensuite
lide dappliquer des techniques de fuzzing pour automatiser la mise en uvre des diffrentes
attaques par entres-sorties. Cette technique de test va nous permettre, dune part, de vrifier
limplmentation des bus dentres-sorties des systmes Intel-PC et, dautre part, didentifier
des vulnrabilits et, ventuellement, des fonctionnalits caches. Nous rappelons ensuite les
grands principes du fuzzing avant de dcrire lenvironnement de test que nous avons mis en
uvre et les rsultats obtenus lors de nos exprimentations.
78
4.1. IronHide : outil dinjection de fautes sur les bus dentres-sorties
Logique du
Donnes
contrleur
Couche Numro de
Trame squence En-tte Donnes ECRC LCRC Trame
Physique
se charge du transport des TLP entre contrleurs dentres-sorties PCI Express adjacents. Un
TLP est ainsi transport de proche en proche, sur les pistes (en anglais, lanes) du bus PCI Ex-
press, vers le contrleur dentres-sorties de destination. Pour cela, cette couche protocolaire
encapsule son tour chaque TLP dans un Data Link Layer Packet (DLLP), en ajoutant celui-
ci un numro de squence (pour la gestion des ventuels dsquencements) et un autre code
correcteur derreurs appel LCRC (pour Link CRC). Finalement, la couche physique se charge
dmettre ou de recevoir les DLLP sur les pistes PCI Express. Elle se compose de circuits lec-
troniques : des convertisseurs parallle-srie et srie-parallle, des boucles verrouillage de
phase (en anglais, Phase Locked-Loop) et des circuits dadaptation dimpdance, etc.
Il convient de remarquer que le standard de bus PCI Express dfinit deux types de CRC :
un ECRC et un LCRC. Les deux types de CRC sont utiliss par les contrleurs dentres-sorties
pour vrifier lintgrit des paquets reus. lmission, un contrleur dentres-sorties procde
un calcul sur les donnes contenues dans le paquet sortant et lui adjoint le rsultat de ce
calcul. la rception, un contrleur dentres-sorties effectue le mme calcul sur le paquet
reu et compare le rsultat la valeur extraite du paquet. Le rcepteur dtecte une erreur de
transmission lorsque les deux valeurs calcules sont diffrentes. Ces deux types de CRC se
distinguent principalement par leurs tailles 32 bits pour lECRC contre 16 bits pour le LCRC
et par la couche PCI Express qui est en charge de leur calcul et de leur vrification.
Pour transfrer des donnes vers les diffrents espaces dadressage, les contrleurs PCI Ex-
press reposent sur des transactions. Nous distinguons quatre principales classes de transac-
tions. Les classes de transactions memory, I/O et configuration permettent daccder respective-
ment lespace dadressage principal de la mmoire, lespace Port I/O et lespace de confi-
guration des contrleurs dentres-sorties PCI ou PCI Express. Une dernire classe de tran-
sactions, appele message, permet de vhiculer des informations diverses entre les contrleurs
PCI Express. Elle est utilise notamment pour signaler des interruptions, des erreurs ou pour
vhiculer des messages de gestion dnergie. La table 4.1 prsente les principaux types de tran-
sactions dfinies dans le standard PCI Express pour chacune des classes de transactions.
Nous distinguons deux catgories de transactions, posted (sans rponse) et non-posted (avec
rponse), selon quelles impliquent ou pas une rponse (appele completion) de la part du
contrleur dentres-sorties qui traite laccs. Le paquet completion a pour rle dacquitter la
79
Chapitre 4. Application des techniques de fuzzing sur les bus dentres-sorties
Avec ou sans
Classes Type de transaction
rponse
Memory Read avec rponse
Memory Memory Write sans rponse
Memory Read Lock avec rponse
IO Read avec rponse
I/O
IO Write avec rponse
Configuration Read Type 0 avec rponse
Configuration Read Type 1 avec rponse
Configuration
Configuration Write Type 0 avec rponse
Configuration Write Type 1 avec rponse
Message Message sans rponse
bonne rception de la requte daccs et contient ventuellement les donnes demandes. Les
transactions dcriture correspondent, typiquement, des transactions posted car elles ne re-
quirent pas de rponse. Les transactions de lecture, quant elles, correspondent des tran-
sactions non-posted car elles requirent le renvoi dun paquet completion contenant les donnes
demandes. Sur les bus dentres-sorties, ces transactions se matrialisent par des Transaction
Layer Packets (TLP).
+0 +1 +2 +3
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Fmt Type T
R 0b10 R TC Reserv D E A r R Length
0b0 0000 P
Requester ID Tag LDBE FDBE
Address [32:2] R
Donnes
F IGURE 4.2 Format dun TLP de type Memory Write Request (format 32 bits)
Les champs Fmt et Type combins identifient le type de transaction contenue dans le pa-
80
4.1. IronHide : outil dinjection de fautes sur les bus dentres-sorties
quet. Il sagit, dans cet exemple, dune transaction dcriture (format 32 bits) 30 destination de
lespace dadressage principal de la mmoire. Le champ TC indique la classe de trafic laquelle
appartient le paquet. Il permet de diffrencier les transactions selon huit classes de trafic dis-
tinctes qui mettent en uvre des politiques de service diffrentes. Le bit TD indique si le TLP
contient un ECRC. Le bit EP indique si le TLP a t empoisonn , cest--dire que le paquet
mis nest pas valide. Le champ Attr contient des informations pour optimiser la gestion de
trafic. Le second bit de ce champ indique, par exemple, si une mise en cohrence du cache (en
anglais, snooping) est ncessaire pour cette transaction. Le champ Length indique la longueur
(exprime en blocs de 4 octets) des donnes transportes dans le TLP.
Il est intressant de retrouver dans cet exemple plusieurs lments utiliss par les tech-
nologies de type I/O MMU. Le champ Requester ID contient, par exemple, lidentit du
contrleur dentres-sorties qui initie la transaction. Le champ Address indique ladresse de
destination en mmoire centrale o sont crites les donnes. Finalement, le champ AT indique
si celui-ci contient une adresse DMA virtuelle ou une adresse (physique) issue de la traduction
dadresse effectue par le contrleur dentres-sorties dans le cadre des devices-I/O TLB.
81
Chapitre 4. Application des techniques de fuzzing sur les bus dentres-sorties
dentres-sorties alors que lmission de requtes invalides va nous permettre dvaluer la ro-
bustesse de ces mmes contrleurs vis--vis de fautes injectes au travers des bus dentres-
sorties.
Notre contrleur est galement polyvalent puisque son comportement est entirement pro-
grammable. Il est envisageable de lutiliser aussi bien pour faire de linjection de fautes sur les
bus PCI Express que pour muler une carte dextension PCI Express quelconque. Il suffit pour
cela de modifier le logiciel, crit en langage C, excut par le processeur quil embarque.
Enfin, nous avons conu son architecture de faon ce quelle puisse tre tendue par
plusieurs contrleurs de priphriques. Il est, par exemple, possible dy intgrer un contr-
leur srie RS-232 pour surveiller, sur une machine servant de moniteur, lvolution du contr-
leur dentres-sorties, un contrleur Ethernet pour interagir avec lui au travers du rseau, un
contrleur USB pour enregistrer sur un priphrique de stockage USB les rsultats de nos ex-
primentations, etc.
82
Circuit Logique Programmable (FPGA) Lgende
Systme embarqu
avec un processeur, Logique du Interruption Contrleur IP Core fournie
de la mmoire, Processeur embarqu
contrleur d'interruptions
des periphriques, etc.
Bus PLBv46 IP Core dveloppe
83
4.1. IronHide : outil dinjection de fautes sur les bus dentres-sorties
Chapitre 4. Application des techniques de fuzzing sur les bus dentres-sorties
clenche une interruption pour linformer de cet vnement. Une routine dinterruption vient
alors lire ce paquet puis effectue les traitements associs. Elle vrifie que les diffrents champs
de ce paquet (cest--dire les en-ttes et les ventuelles donnes) sont conformes au protocole
et construit un paquet completion lorsquune rponse est requise. Ce paquet completion est copi
dans une autre mmoire partage et est mis automatiquement par le pont PCIe vers PLBv46.
Notez que le processeur embarqu peut galement utiliser cette seconde mmoire partage
pour initier de lui-mme des requtes dentres-sorties valides ou invalides sur les bus PCI
Express.
Finalement, larchitecture de notre contrleur dentres-sorties peut tre tendue par des
contrleurs de priphriques divers qui peuvent tre utiliss pour surveiller le comportement
du systme embarqu ou pour lui permettre de communiquer avec un systme extrieur (par
exemple, une machine distante). terme, il serait intressant dutiliser ces contrleurs divers
pour muler des cartes dextension PCI Express standards, telles que des cartes Ethernet tout
en y insrant une porte drobe permettant, par exemple, de prendre le contrle distance du
contrleur, par une trame rseau spcifique.
4.1.2.3 Implmentation
Cette architecture a t implmente avec succs sur une carte de dveloppement Pico E-
17 [Pico Computing 11] commercialise par Pico Computing. Il sagit dune carte de dvelop-
pement au format Express Card qui dispose dun FPGA Xilinx Virtex-5 FX70T, dune mmoire
vive (DDR2-SDRAM) de 256 mgaoctets, dune mmoire flash de 64 mgaoctets et de diff-
rents contrleurs de priphriques (par exemple, plusieurs contrleurs Ethernet et un contr-
leur srie RS-232). Le comportement de la carte de dveloppement est entirement dfini par le
logiciel crit en langage C et excut par le processeur PowerPC quelle embarque. Notre im-
plmentation est a priori compatible avec toutes les cartes de dveloppement base de FPGA
Xilinx Virtex-5. En adaptant la configuration spcifique la carte de dveloppement que nous
avons utilise (cest--dire les contraintes temporelles, de placement, etc.), il est thoriquement
possible de porter notre implmentation sur une autre carte de dveloppement. Une adaptation
de notre implmentation sur la carte de dveloppement MLX-1000-XC5V [ModularLogix 10]
fabrique par ModularLogix (respectant le format PCI Express) est actuellement en cours.
84
4.2. lments de fuzzing
dans les implmentations de systmes logiciels que nous adaptons des systmes matriels.
La prochaine section introduit quelques lments sur cette technique de test.
85
Chapitre 4. Application des techniques de fuzzing sur les bus dentres-sorties
mat de ces entres. A contrario, les fuzzers par synthse construisent des entres de test partir
dune modlisation de ces entres.
86
4.2. lments de fuzzing
implmentations dun mme systme par rapport sa spcification. Par ailleurs, puisque les
entres de test sont gnres de faon dterministe, il est possible de rejouer plusieurs fois le
mme jeu dentres de test et de conserver une trace prcise de chaque test. Cependant, cette
mthode de slection dentres de test peut savrer limite si le document de spcification
nest pas suffisamment prcis. En effet, il est possible quil omette plusieurs conditions de fonc-
tionnement du systme et, ventuellement, certaines violations. Il est souvent ncessaire de
complter cette mthode par des entres de test alatoires pour couvrir un domaine dentre
plus important.
Une autre manire de slectionner des entres de tests est de les gnrer alatoirement.
Lide consiste alors fournir au systme des entres alatoires de faon influer (alatoire-
ment) sur lenchanement et le comportement de ses fonctions. Il sagit probablement de la
mthode la plus rapide mettre en uvre et celle qui ncessite le moins deffort car elle im-
plique uniquement lutilisation dun gnrateur pseudo-alatoire. Elle est, cependant, de loin
la moins efficace. En effet, un systme bien conu effectue systmatiquement un pr-traitement
de ses entres afin de dterminer si celles-ci sont valides ou, au contraire, invalides. Pour cela, il
applique des rgles lexicales et grammaticales ses entres et rejette les entres qui ne sont pas
conformes ces rgles. En raison de leur caractre alatoire, un grand nombre dentres ne se-
ront pas pertinentes et niront pas au del de ce pr-traitement. Il convient cependant de noter
que cette mthode conduit parfois des rsultats intressants. De nombreuses vulnrabilits
logicielles ont t ainsi mises au jour [Miller et al. 90, Forrester et Miller 00, Miller et al. 07]. Il est
noter quil existe une variante de cette mthode [Holzleitner 09] dite feedback, qui modifie
la gnration des entres de test en fonction des rsultats des tests prcdents. Cette approche
permet ainsi didentifier plus rapidement des cas intressants.
87
Chapitre 4. Application des techniques de fuzzing sur les bus dentres-sorties
Chacune de ces approches de slection de cas de tests a ses avantages et ses inconvnients.
Dans le but de couvrir un domaine dentre plus large, il est important de combiner ces diff-
rentes mthodes dans un fuzzer. La prochaine section prsente le fuzzer que nous avons dve-
lopp pour automatiser la mise en uvre (et ltude) des attaques par entres-sorties.
88
4.3. Mise en uvre du fuzzing sur les bus dentres-sorties
quil puisse effectuer un dpouillement manuel ultrieurement. Une fois le verdict prononc,
le contrleur de tests transmet nouveau loutil dinjection de fautes une nouvelle entre de
test. Ce cycle se termine lorsquil ny a plus dentres de test excuter. Afin de pouvoir v-
rifier ultrieurement les rsultats obtenus, nous avons journalis dans notre fuzzer lensemble
des tests effectus, les verdicts prononcs ainsi que les informations complmentaires remon-
tes par les agents.
Avant de discuter des exprimentations que nous avons effectues avec notre fuzzer, pr-
cisons quelques lments sur son implmentation. La majorit des lments du fuzzer ont t
implments dans le langage Python. En particulier, nous nous sommes appuys sur loutil de
manipulation de paquets rseau Scapy [Biondi 13] pour gnrer les Transaction Layer Packets
valides et invalides. Puisque ce dernier nimplmente pas nativement le protocole PCI Express,
nous lavons tendu pour intgrer ce nouveau protocole. En ce qui concerne la slection des
entres de test, nous avons favoris lapproche par synthse puisquelle donne gnralement
de meilleurs rsultats 33 . Nous avons galement combin plusieurs mthodes afin de couvrir
un domaine dentre plus important :
1. Entres de test prdfinies. Les spcifications du standard PCI Express sont relativement
compltes. Elles contiennent des exemples dentres de test et les comportements at-
tendus pour les contrleurs dentres-sorties vis--vis de celles-ci. Ces entres de test
couvrent non seulement les accs dentres-sorties valides, mais galement certains ac-
cs dentres-sorties invalides. Il peut tre intressant de les implmenter, puis de les
excuter afin de vrifier la conformit de limplmentation du PCI Express par les chip-
sets.
2. Entres de test gnres automatiquement. La majorit des TLP respectent un format de TLP
dfini par la spcification. La smantique et les plages de valeurs possibles pour chaque
champ tant prcises dans les specifications, il est possible de gnrer des entres de
test automatiquement. Dans ce cas, il est important de gnrer la fois des TLP valides
pour vrifier limplmentation du PCI Express par le chipset, mais galement des TLP
invalides, pour valuer la robustesse de cette implmentation. Certains champs nous
paraissent particulirement intressants lors de la gnration dentres de test :
les champs rservs : ils correspondent gnralement des emplacements destins
un usage futur. Un contrleur dentres-sorties source est suppos sassurer que
ces champs soient positionns zro. Quant au contrleur dentres-sorties destina-
taire, ce dernier se doit dignorer les valeurs contenues dans ces champs. Il convient
33
Dans [Miller et Peterson 07], les auteurs ont compar les deux approches de gnration dentres de test. En se
focalisant sur les formats de fichiers Portable Network Graphics (PNG), ils ont estim que lapproche par synthse
tait 80% plus efficace que lapproche par mutation.
89
Chapitre 4. Application des techniques de fuzzing sur les bus dentres-sorties
Au cours de nos exprimentations, nous nous sommes concentrs uniquement sur le test de
limplmentation du protocole PCI Express par les contrleurs dentres-sorties. Afin de limiter
le spectre de notre recherche de vulnrabilits, nous navons dlibrment pas tenu compte des
fonctionnalits spcifiques chacun 34 ni des protocoles ddis qui permettent dy accder.
90
4.3. Mise en uvre du fuzzing sur les bus dentres-sorties
F Agents
U
Z
Z
E Composants
Injecteur de fautes
matriels & logiciels
R
Systme Sous Test (SST)
B
A
N
C
D
E
T
E
S
T
PCI Express pour le contrleur de tests : il met tous les paquets reus depuis linterface Ether-
net en provenance de la machine moniteur vers les bus PCI Express de la machine cible et renvoie
vers la machine moniteur les rponses ventuelles. Le logiciel embarqu dans IronHide impl-
mente une pile TCP/IP et contient un serveur TCP qui relaie les paquets entre le contrleur de
tests et les bus dentres-sorties du systme sous test. Il est configur avec une adresse IP sta-
tique et le serveur TCP embarqu attend de nouvelles connexions sur un port que nous avons
dfini. Il est noter que nous aurions pu gagner en performance en choisissant lutilisation
dun serveur UDP plutt quun serveur TCP. Nous avons prfr utiliser le protocole TCP, de
faon fiabiliser les changes et ainsi viter les problmes lis aux pertes de paquets rseau par
congestion du contrleur IronHide ou de la machine moniteur lors de nos exprimentations.
Nous avons procd des exprimentations sur diffrents chipsets Intel rcents qui sont rap-
pels la table 4.2. Prcisons que nous avons repris le mme parc de machines que lors de notre
tude des attaques peer-to-peer (cf. section 3.3). Pour chaque machine exprimente, nous rap-
pelons le modle de chipset concern et le modle de machine utilis. Les exprimentations sur
chacune de ces machines ont t faites selon deux configurations matrielles diffrentes. Dans
la premire configuration matrielle, nous avons volontairement dsactiv lensemble des tech-
nologies matrielles, telles quIntel VT-d et les ACS, permettant de contrler les entres-sorties.
Nous avons ensuite rejou ces mmes tests en prsence de ces technologies matrielles. La com-
paraison des observations permet alors dvaluer la robustesse de ces technologies matrielles.
Nous avons produit environ 65 000 entres de test que nous avons joues sur chaque ma-
chine. En fonction des machines testes, la campagne de fuzzing a dur entre 2 jours et 2 se-
maines. Le temps ncessaire pour excuter chaque campagne de tests dpend directement du
91
Chapitre 4. Application des techniques de fuzzing sur les bus dentres-sorties
nombre de fautes dtectes sur une machine. En effet, puisque certains tests peut provoquer un
blocage de la machine, il est ncessaire, dans ces cas prcis, de redmarrer la machine teste.
La table 4.3 consigne quelques rsultats que nous avons obtenus dans ces deux configura-
tions matrielles. Par souci de lisibilit, nous avons regroup les machines qui prsentent des
comportements similaires. Nous avons galement rassembl les tests par classe de transactions
et par lment du TLP qui a t modifi. Certains de ces tests ont t marqus comme non-
applicables soit parce que les accs ne sont pas autoriss par le chipset (cas des machines 0, 1, 2
et 3), soit parce que la configuration du chipset na pas pu tre modifie pour le permettre (cas
de la machine 4).
Lanalyse des rsultats rvle que le comportement des machines 0, 1, 2 et 3 diffre du
comportement de la machine 4. Pour le premier groupe de machines, nous remarquons qu
la fois des paquets valides et des paquets invalides peuvent provoquer un dni de service du
systme. Il est intressant de prciser que le dni de service affecte uniquement la partie des
bus dentres-sorties concerne par la transaction et que le reste des bus dentres-sorties reste
fonctionnel. Cependant, puisque le systme dexploitation nest plus en mesure dinterroger
les composants connects ces bus dentres-sorties, les pilotes des composants matriels qui
ne sont pas conus pour grer ce type de situation entrent dans un tat derreur et provoquent
rapidement le blocage complet du systme. Un redmarrage du systme est alors ncessaire.
En enqutant sur les causes de ces dnis de service, nous nous sommes rendu compte que
ceux-ci rsultent soit de lutilisation de fonctionnalits auxiliaires prvues par les spcifications
PCI Express mais qui nont pas t implmentes, soit dune mauvaise configuration de la
plate-forme matrielle. Pour ce qui est de la machine 4, elle parvient dtecter la majorit des
paquets invalides et signaler des erreurs au systme dexploitation qui les journalise. Cette
diffrence de comportement entre les machines sexplique par les extensions du standard PCI
Express quelles implmentent. Les machines 0, 1, 2 et 3 nimplmentent aucune extension
particulire du PCI Express alors que la machine 4 dispose, en plus dIntel VT-d et des ACS,
une extension supplmentaire appele Advanced Error Reporting (AER) qui permet de vrifier
que les paquets PCI Express qui transitent sur les bus dentres-sorties sont conformes la
spcification. Cette extension effectue des vrifications sur diffrentes couches protocolaires.
Au niveau de la couche transaction, celle-ci est notamment capable de distinguer et remonter
diffrentes erreurs sur les paquets au systme dexploitation. Elle est capable de dtecter par
exemple un ECRC invalide, une communication avec un contrleur dentres-sorties inexistant,
des dpassements de tampons ou des TLP malforms. Limplmentation dune telle extension
montre une relle volont de la part des constructeurs de chipsets prendre en considration
les attaques par entres-sorties.
Il convient de remarquer quil est normal dobtenir, par cette approche danalyse de vul-
nrabilits, uniquement des consquences de type dnis de service car nous avons, dans nos
exprimentations, injecte des donnes alatoires. Pour aller plus loin, il serait intressant dana-
92
4.4. Conclusion
lyser plus finement ces dnis de services afin didentifier si les vulnrabilits dont ils sont issus
peuvent tre exploites autrement. tant donn que nous nous sommes focaliss sur le test
des implmentations matrielles, un rapprochement auprs des constructeurs semble indis-
pensable afin didentifier si ceux si rsultent de choix ou derreurs dimplmentation.
4.4 Conclusion
Au lieu de suivre la dmarche classique en analyse de vulnrabilits, nous avons propos,
dans ce chapitre, une dmarche complmentaire qui nous a permis de dcouvrir les vulnra-
bilits de faon systmatique (sinon exhaustive). Elle consiste injecter des fautes sur les bus
dentres-sorties dans le but de simuler les consquences dun large spectre de fautes. cet
effet, nous avons dvelopp un outil, baptis IronHide, capable de gnrer tout type de trames
sur les bus dentres-sorties. Celui-ci se prsente comme un contrleur dentres-sorties clas-
sique et a t implment laide de technologies de logique programmable tels que les FPGA.
Notre contrleur IronHide nous permet davoir les mmes pouvoirs quun attaquant ins-
tallant une porte drobe dans un contrleur quil conoit ou dans lequel il a dcouvert une
vulnrabilit le lui permettant. Nous avons ensuite utilis cet outil dinjection de fautes pour
mettre en uvre diffrentes attaques par entres-sorties. Afin dautomatiser ces attaques, nous
nous sommes inspirs des techniques de test de systmes logiciels. Nous avons appliqu plu-
sieurs systmes matriels les techniques de fuzzing gnralement utilises dans la recherche de
vulnrabilits dans des implmentations de systmes logiciels. Lanalyse des rsultats (prli-
minaires) que nous avons obtenus lors de nos exprimentations rvle qu la fois les paquets
valides et les paquets invalides peuvent provoquer un dni de service. Ceux-ci rsultent alors
soit de lutilisation de fonctionnalits auxiliaires prvues par les spcifications PCI Express mais
qui nont pas t implmentes, soit dune mauvaise configuration de la plate-forme matrielle.
Finalement, nous avons constat que lextension Advanced Error Reporting (AER) implmente
dans certaines plates-formes matrielles semble les immuniser aux attaques que nous avons
mises en uvre. Cette extension effectue des vrifications sur diffrentes couches protocolaires.
Au niveau de la couche transaction, celle-ci est notamment capable didentifier et remonter au
systme dexploitation diffrentes erreurs sur les paquets (par exemple, ECRC invalide, com-
munication avec un contrleur dentres-sorties inexistant, dpassements de tampons et TLP
malforms). Son implmentation dans certains chipsets montre une relle volont de la part des
constructeurs prendre en considration les attaques par entres-sorties.
93
Entres de test Technologies matrielles inactives Technologies matrielles actives
Type de transaction Champs modifis Machine 1, 2, 3, 4 Machine 5 Machine 1, 2, 3, 4 Machine 5
Format et Type - dtect - dtect
Traffic Class (TC) DoS - DoS -
TLP Digest (TD) DoS dtect DoS dtect
TLP Poisonned (EP) - - - -
Gnrique
Attribute (Attr) - dtect - dtect
Chapitre 4. Application des techniques de fuzzing sur les bus dentres-sorties
94
Conclusion gnrale
en juger par les volutions actuelles, les systmes informatiques vont vraisemblablement
continuer simmiscer davantage dans notre quotidien. Le dveloppement de ces systmes
de plus en plus ubiquitaires saccompagne naturellement de nombreux dfis technologiques
tels que la mobilit, lvolutivit et lautonomie, la ractivit, etc. Parmi ces dfis, la question
cruciale de la scurit reste un enjeu majeur en raison de la dmatrialisation croissante de
linformation et des risques de plus en plus importants lis la complexit de ces systmes.
Ce manuscrit de thse traite de la scurit en vie oprationnelle des systmes informatiques
sur tagre. Les travaux que nous avons raliss se concentrent principalement sur la protection
de ces systmes contre les attaques informatiques impliquant non seulement les composants lo-
giciels mais galement les composants matriels. Ils suscitent actuellement un intrt croissant
autant dans le monde acadmique que le monde industriel en raison de la prolifration de ce
type de menaces informatiques qui se font, aujourdhui, de plus en plus oppressantes.
Afin de cerner cette problmatique complexe, nous avons commenc par laborer un mo-
dle dattaques sur lequel nous nous sommes bass pour identifier les attaques dans un systme
informatique. Ensuite, nous avons instanci ce modle vis--vis des systmes auxquels nos tra-
vaux se sont intresss, savoir les ordinateurs compatibles PC. Cette instance nous a alors
permis, dune part, de positionner les attaques que nous avons analyses par rapport celles
qui sont habituellement considres et, dautre part, didentifier plusieurs scnarios dattaque
qui, jusqu prsent, ont t ngligs pour des raisons diverses.
Notre dmarche danalyse des attaques informatiques et des contre-mesures associes sest
oriente ensuite vers une tude exprimentale. Nous avons suppos que le problme des at-
taques (exclusivement) logicielles tait rsolu, nous poussant alors nous concentrer spci-
fiquement sur celles qui impliquent la fois des composants logiciels et matriels et, plus
particulirement, sur les attaques par entres-sorties qui sont encore relativement peu explo-
res. Ces attaques atypiques dtournent les entres-sorties, plus prcisment les mcanismes
de communication entre les processeurs et les contrleurs dentres-sorties, des fins mal-
veillantes. En nous appuyant sur notre modle, nous les avons tudies selon deux approches
complmentaires : une premire approche traditionnelle plutt empirique, consistant recher-
cher et identifier une vulnrabilit, dvelopper une preuve de concept qui permette de lex-
ploiter puis proposer des contre-mesures ; et une seconde approche, complmentaire la pre-
mire, plus systmatique et sinspirant des techniques de recherche de vulnrabilits dans les
composants logiciels. Ces deux approches ont permis de rvler, dune part, des vulnrabilits
dans les plates-formes matrielles actuelles et, dautre part, des insuffisances dans les contre-
mesures matrielles aux attaques par entres-sorties. Pour chacune delles, nous avons formul
quelques recommandations pour se protger dattaques qui les exploiteraient.
95
Conclusion gnrale
1 Contributions
Nous trouvons dans la littrature diffrentes taxonomies dattaques. Seulement, aucune
delles ne nous a pleinement satisfaits pour notre tude. En effet, elles nont pas permis de re-
prsenter lensemble des attaques sur un systme informatique que nous avons considres. En
nous inspirant de la logique de ces taxonomies dattaques, nous avons propos, dans un pre-
mier temps, une caractrisation de ces attaques informatiques (cf. chapitre 1). Pour cette ana-
lyse, nous sommes partis de la dfinition dun systme informatique, et nous avons conjectur
que ces attaques peuvent intervenir plusieurs niveaux dabstraction du systme, notamment
les composants logiciels, les composants matriels, les canaux de communication et lenviron-
nement du systme informatique. En dcomposant les attaques en squences dactions lmen-
taires, et en tudiant celles qui sont malveillantes, autrement dit leurs attaques lmentaires,
nous avons pu identifier les lments sur lesquels portent ces attaques ainsi que les vecteurs
dattaque utiliss. Nous sommes parvenus une classification de ces actions malveillantes se-
lon trois axes complmentaires le niveau dabstraction du systme sur lequel porte lattaque,
lobjet de lattaque et le vecteur dattaque utilis sur cet objet et cette classification sous-tend
le reste de notre manuscrit.
Afin dtudier mthodiquement les attaques dans un systme informatique, nous avons en-
suite propos un modle dattaques (cf. chapitre 2). Le modle que nous avons propos permet
de couvrir des scnarios dattaque qui impliquent ventuellement plusieurs niveaux dabstrac-
tion dun systme informatique. Dans ce modle, nous avons considr les composants mat-
riels dans un systme informatique comme des systmes part entire qui interagissent avec
dautres composants matriels (donc dautres systmes). Nous avons modlis leur structure
interne comme tant compos de plusieurs sous-systmes logiciel, logique (cble), configu-
ration et communication interdpendants. En nous appuyant sur notre prcdent travail de
caractrisation des attaques, nous avons dtermin lensemble des actions lmentaires et des
attaques lmentaires au sein dun composant matriel. Ce modle, combin aux interactions
entre les diffrents composants, nous a alors permis de dterminer les squences dattaques qui
sont possibles dans un systme informatique. Enfin, nous avons valid le modle obtenu en le
confrontant plusieurs exemples rels dattaques complexes.
Nous nous sommes alors focaliss sur le domaine des attaques par entres-sorties qui,
jusqu prsent, na t que relativement peu explor. Vis--vis de ces attaques, nous consta-
tons que les contre-mesures, qui taient jusqu prsent presquexclusivement logicielles, ne
suffisent plus et quune bonne connaissance de la plate-forme matrielle est ncessaire pour
une meilleure matrise de la scurit dun systme informatique. Cest pour cette raison que
nos approches danalyse de ces attaques informatiques se sont orientes rsolument vers des
tudes exprimentales. Celles-ci se sont principalement concentres sur les systmes informa-
tiques compatibles PC. Notre premire approche (cf. chapitre 3) sapparente aux approches
qui sont traditionnellement adoptes pour tudier les attaques informatiques : en saidant de
documents de spcification, le systme informatique cibl est analys en dtail dans le but
didentifier des vulnrabilits qui sont ventuellement exploitables. En dpit des efforts cons-
quents qui ont t entrepris ces dernires annes par diffrents acteurs de lindustrie informa-
tique (constructeurs, consortiums de normalisation, etc.) pour tenter dendiguer les problmes
lis aux utilisations des entres-sorties des fins malveillantes, nous avons pu constater plu-
sieurs insuffisances dans les contre-mesures matrielles implmentes dans les plates-formes
actuelles, notamment dans la technologie matrielle de virtualisation Intel VT-d et dans les
Access Control Services [Lone Sang et al. 10a, Lone Sang et al. 10b, Lone Sang et al. 11]. De faon
dlibre, nous avons ensuite exploit avec succs ces insuffisances afin de formuler quelques
96
2. Travaux futurs
2 Travaux futurs
Les travaux prsents dans ce manuscrit de thse ouvrent des axes dactivit complmen-
taires intressants. Outre les pistes damlioration dordre technique que nous avons dj men-
tionnes en fin de chaque chapitre, plusieurs axes de recherche que nous avons envisags sins-
crivent dans le prolongement de nos travaux.
97
Conclusion gnrale
pays. Bien que thoriquement difficile mettre en uvre, il est lgitime de penser que des at-
taquants, ventuellement aids par des organisations tatiques, russissent insrer des portes
drobes dans des lments du systme, en particulier les composants matriels [Bockel 12].
Le cas des systmes avioniques, de plus en plus ouverts vers lenvironnement de lavion, est
particulirement proccupant [Laarouchi 09]. tant donn le rle de plus en plus prpondrant
jou par ces systmes, il serait intressant dtudier leur robustesse vis--vis dattaques. En ef-
fet, une dfaillance de ces systmes pourraient avoir des effets catastrophiques qui conduiraient
invitablement des pertes humaines considrables. Certains de ces systmes reposent sur une
architecture matrielle similaire larchitecture PC que nous avons tudie dans ce manuscrit.
Par ailleurs, ceux-ci implmentent le protocole de bus PCI Express pour leurs bus dentres-
sorties. Nous pourrions alors, sans trop de peine, utiliser notre fuzzer (cf. chapitre 4) sur ces
systmes afin dvaluer limpact dattaques par entres-sorties et proposer, par l-mme, des
mcanismes de tolrance aux fautes adapts.
98
Annexe A
Cette section prsente une preuve de concept pour la vulnrabilit dtaille en section 3.2.
Nous commenons tout dabord par prsenter le scnario dattaque ainsi que la plate-forme ex-
primentale que nous avons considrs. Nous donnons ensuite quelques prcisions techniques
qui permettent de mieux apprhender lattaque que nous avons mise en place. Finalement,
nous concluons sur les rsultats que nous obtenons.
Considrons le scnario suivant pour notre preuve de concept. Alice, Bob et Eve travaillent
pour une grande entreprise. Alice et Bob changent des informations confidentielles travers
le rseau local. ve souhaite accder ces informations auxquelles normalement elle na pas
accs. Elle dcide alors dcouter leurs changes, plus particulirement les donnes que Bob
envoie Alice.
Il nest pas rare dans les grandes entreprises que le parc informatique soit compos de ma-
chines identiques (cest--dire, avec la mme configuration matrielle, avec un systme dex-
ploitation identique, etc.). Nous admettons ainsi quAlice, Bob et ve disposent de machines de
bureau identiques en tout point et excutant un noyau Linux. La figure A.1 prsente la confi-
guration de ces machines. Elles possdent lextension matrielle Intel VT-d dont le support a
t activ la fois dans le noyau et dans le BIOS. Ces machines possdent galement une carte
Ethernet et une carte FireWire connectes au mme bus PCI.
ve dcouvre que sa machine souffre de la vulnrabilit matrielle prsente en section 3.2.
Comme toutes les machines sont identiques, elle dduit que les autres machines de lentreprise,
en particulier celle de Bob, souffrent galement de cette vulnrabilit. Elle y trouve l un moyen
despionner Bob. Elle met en place une attaque DMA consistant injecter des trames Ethernet
malveillantes dans les tampons mmoires associs la carte Ethernet de Bob. Dans notre cas
dtude, ces trames correspondent des requtes ARP. Cette attaque DMA est mene depuis
un priphrique FireWire, par exemple un iPod modifi [Dornseif 04, Becher et al. 05] par ses
soins quelle prte Bob.
Nous donnons dans la suite quelques prcisions techniques sur le fonctionnement dune
carte Ethernet, ncessaires la comprhension de notre attaque.
99
Annexe A. Preuve de concept dattaque par partage didentifiants PCI Express
Processeur
Cette partie sintresse au fonctionnement de la carte Ethernet VIA Rhine VT6102 installe
dans la machine de Bob. Nous tudions uniquement la rception de trames. Nous dtaillons
pour commencer les mcanismes et les structures de donnes mises en jeu lors de la rception
de trames Ethernet. partir de l, nous mettons en vidence les points dinjection. Enfin, nous
dtaillons le mode opratoire suivi.
100
A.2. Injection des donnes dans une carte Ethernet
F IGURE A.2 Le tampon de rception dans la carte Ethernet VIA Rhine VT6102
Lorsquune trame est reue depuis le rseau, la carte Ethernet la stocke temporairement
dans une des mmoires tampons disponibles. Le transfert de donnes depuis la carte rseau
vers la mmoire seffectue par un accs DMA. La carte Ethernet accde galement aux descrip-
teurs de trame afin de dcrire de manire cohrente la mmoire tampon o est copie la trame
reue. Afin que le contrleur Ethernet puisse accder ces structures de donnes par DMA, le
systme dexploitation les alloue dans la partie de la mmoire rserve aux accs DMA. Une
fois la trame stocke dans la zone des tampons, la carte rseau effectue une interruption mat-
rielle qui va activer le gestionnaire dinterruption associ. Aprs avoir effectu certaines op-
rations, ce gestionnaire va consommer les trames Ethernet reues quil na pas encore traites.
Nous prsentons ci-aprs le mode opratoire de notre attaque.
101
Annexe A. Preuve de concept dattaque par partage didentifiants PCI Express
102
A.3. Application la corruption de cache ARP
1. ve commence par forger les trames Ethernet quelle va injecter dans la machine de Bob.
Elle peut utiliser par exemple loutil logiciel SCAPY. Elle forge des rponses ARP-REQUEST
qui vont associer ladresse MAC de sa carte rseau ladresse IP associe la machine
dAlice.
$> scapy
Welcome to Scapy ( 2 . 0 . 0 . 5 beta )
>>> bob = { ip : 192.168.1.1 , mac : 00:25:00:9f:3b:30 }
>>> alice = { ip : 192.168.1.2 , mac : 00:50:56:8a:3b:6b }
>>> eve = { ip : 192.168.1.3 , mac : 00:90:27:6a:58:74 }
>>> # Construction de la trame
. . . arp_request_packet = ARP ( op=who-has , hwsrc=eve [ mac ] ,
. . . psrc=alice [ ip ] , hwdst=00:00:00:00:00:00 , pdst=bob [ ip ] )
>>> ethernet_frame = Ether ( dst=ff:ff:ff:ff:ff:ff , src=eve [ mac ] )
>>> raw_frame = ethernet_frame/arp_reply_packet ;
>>> # Ecriture de la trame dans un fichier
. . . file_handle = open ( arp_reply_raw_frame , w )
>>> file_handle . write ( str ( raw_frame ) )
>>> file_handle . close ( )
2. ve programme ensuite son iPod pour injecter ces trames malveillantes dans les tam-
pons associs la carte rseau de Bob ds que liPod se trouve connect sa machine.
Elle localise ces tampons via les descripteurs de trame. Ceux-ci sont allous lors de lini-
tialisation de la carte rseau et leur localisation en mmoire est invariante dans le temps.
Comme les machines dve et Bob sont identiques, les descripteurs de trame sont locali-
ss aux mmes adresses physiques sur les deux machines.
3. ve demande Bob de lui copier des fichiers (documents, musique, etc.) sur son priph-
rique. Ne se doutant de rien, Bob connecte liPod malveillant sa machine. LiPod injecte
alors les paquets forgs dans les mmoires tampons associes la carte rseau. Pour vi-
ter tout risque dcrasement de ces trames malveillantes, ve configure son iPod pour
injecter une mme trame dans plusieurs mmoires tampons. Il met galement jour les
champs statut et longueur des descripteurs de trame afin quils dcrivent des don-
nes cohrentes en mmoire. Nous rappelons que linjection des trames malveillantes
seffectue aux dpens dIntel VT-d. Ce dernier est incapable de diffrencier les accs ef-
fectus par la carte FireWire et la carte rseau car ils possdent le mme source-id. Les
DRHU voient les accs effectus par la carte FireWire, pilote par liPod, comme tant
effectus par la carte rseau.
4. Finalement, elle attend que le systme dexploitation de Bob traite les trames Ethernet
injectes. Rappelons quve peut dclencher le traitement de celles-ci par lenvoi par le
rseau dun paquet valide destination de la machine de Bob. sa rception, la carte
rseau de Bob va gnrer une interruption matrielle, ce qui provoquera le traitement
des trames en attente de traitement, dont les trames injectes.
Le contenu du cache ARP de Bob suite lattaque est donn ci-dessous. Nous remarquons
que ladresse MAC dAlice a chang prouvant que linjection de trames Ethernet dans les tam-
pons associs la carte rseau a fonctionn.
$> hostname
Bob
$> arp
Address HWtype HWaddress Flags Mask Iface
Alice ether 00:90:27:6a:58:74 C eth0
Eve ether 00:90:27:6a:58:74 C eth0
103
Annexe A. Preuve de concept dattaque par partage didentifiants PCI Express
Cette preuve de concept, pour laquelle une vido est disponible [Lone Sang et al. 10], met
en vidence deux problmes. Tout dabord, elle nous a prouv lexistence dune vulnrabilit
dans la technologie Intel VT-d. Ensuite, nous avons dmontr combien il est problmatique de
laisser des contrleurs dentres-sorties partager une mme zone mmoire.
104
Annexe B
Nous avons implment une preuve de concept afin de montrer ce qui est ralisable, en
pratique, avec cette classe dattaque. Dans celle-ci, nous exploitons le mcanisme DMA dun
contrleur malveillant (par exemple, une carte FireWire ou une carte rseau) pour manipuler
la mmoire vido dune carte graphique. Nous rappelons brivement pour commencer larchi-
tecture dune carte graphique.
Mmoire interne
du contrleur
Moniteur graphique
RAM
Mmoire
Digital
Vido
Analog
(Framebu er)
Converter
BIOS
Vido
Graphic
Processing Registres
Unit
Une carte graphique est constitue de divers composants qui collaborent entre eux pour
produire une image que lon affiche sur un cran. Parmi ces composants, nous distinguons :
105
Annexe B. Preuve de concept dattaque par accs pair--pair sur une carte graphique
les registres de contrle qui permettent au systme dexploitation de piloter les dif-
frents composants de la carte graphique. En particulier, ils permettent de soumettre
des commandes au processeur graphique.
la mmoire vido (ou framebuffer) qui sert stocker les pixels produits par le proces-
seur graphique qui seront par la suite convertis en signaux analogiques ou num-
riques afin dtre affichs sur un cran.
la mmoire VBIOS ou BIOS vido qui contient les routines excutes par le BIOS au
dmarrage de la machine. Ces routines permettent par exemple dinitialiser la carte
vido et de lutiliser ds le dmarrage.
Le Graphics Processing Unit (GPU). Il sagit du processeur graphique qui permet de dchar-
ger le processeur principal des calculs graphiques. Il traite les objets graphiques (par
exemple, un ensemble de points ou de lignes dans lespace) fournis par le systme dex-
ploitation et en dduit les pixels afficher. Les pixels calculs sont stocks dans la m-
moire vido.
Le RAM Digital-Analog Converter (RAMDAC). Cet lment se charge de convertir le contenu
de la mmoire vido en signaux analogiques, par exemple compatibles avec la norme
VGA des crans graphiques.
Dans notre preuve de concept, nous nous intressons uniquement la mmoire vido de
la carte graphique car cest elle qui dtermine ce qui est affich sur lcran. Nous utilisons un
contrleur malveillant pour manipuler par DMA cette mmoire afin de permettre la recopie
distance de ce qui est affich sur la machine victime ou de faire afficher la machine victime un
contenu de notre choix. Les prochaines sections dtaillent le scnario dattaque que nous avons
considr et discutent des rsultats obtenus.
106
B.3. Rsultats obtenus
qui est affich sur lcran de Bob en crivant par DMA dans cette mme mmoire vido. La
figure B.2 reprsente ce scnario dattaque.
Processeur
C
bl
e
Fi
re
W
ir
e
BOB EVE
107
Annexe B. Preuve de concept dattaque par accs pair--pair sur une carte graphique
Nous avons dtermin plusieurs facteurs qui impactent les performances que nous obte-
nons pour notre attaque :
Lapplication excute sur lordinateur portable dve, qui lit la mmoire de la carte gra-
phique au travers du contrleur FireWire, a t dveloppe dans le langage Python.
Les bibliothques de fonctions que nous avons utilises pour communiquer sur les bus
FireWire et reconstituer lcran de Bob sont des wrappers Python de bibliothques d-
veloppes dans le langage C. Nous aurions pu obtenir de meilleures performances en
vitant cette sur-couche et en implmentant notre application dans un langage natif.
Dans notre attaque, nous avons utilis le contrleur FireWire disponible sur la carte-
mre. Ce contrleur est de type PCI. Comme la bande passante des bus PCI Express
est suprieure celle des bus PCI, nous aurions pu amliorer la fluidit de la lecture
dcran en impliquant uniquement des contrleurs de type PCI Express dans lattaque.
Cependant, lheure actuelle, peu de cartes-mre embarquent un contrleur FireWire
PCI Express et nous avons voulu utiliser un matriel reprsentatif des systmes actuels.
Nous avons remarqu au cours de nos exprimentations que les performances de notre
attaque sont fortement dpendantes du contrleur dentre-sortie que nous ciblons. En
effet, certains contrleurs dentre-sortie ne grent que des accs par octets, dautres par
mots, etc. Les types daccs supports par le contrleur dentre-sortie attaqu impactent
directement les rsultats des exprimentations.
108
Annexe C
Cette annexe dtaille les premires exprimentations que nous avons effectues avec notre
contrleur IronHide une fois que celui-ci a t mis au point. Comme nos travaux visent
tudier les attaques depuis les entres-sorties, et que linterface fournie par la majorit des
contrleurs sur tagre est gnralement restreinte aux requtes daccs lespace dadressage
principal de la mmoire (par exemple, pour le mcanisme daccs direct la mmoire), nous
avons cherch prsenter dans cette annexe des exprimentations difficiles, voire impossibles
mettre en uvre depuis des contrleurs conventionnels. Ainsi, les prochaines sections d-
taillent ces exprimentations atypiques ainsi que les rsultats associs. Afin de mieux les cerner,
nous commenons par dcrire la plate-forme dexprimentation.
109
Annexe C. Plusieurs exemples dexprimentations avec le contrleur IronHide
tme dexploitation de la machine cible. En plus dune interface Ethernet, nous avons ajout au
contrleur une interface srie RS-232 sur laquelle les activits du contrleur sont rgulirement
reportes.
La machine moniteur est celle qui va dfinir les transactions PCI Express mettre sur la
machine cible. Pour construire et dissquer les Transaction Layer Packets (TLP) PCI Express, nous
utilisons loutil rseau Scapy. Comme ce dernier nimplmente pas nativement le protocole PCI
Express, nous lavons tendu pour intgrer ce nouveau protocole 36 . Scapy est galement utilis
pour encapsuler les TLP PCI Express forgs dans un paquet TCP et se charge de les envoyer au
contrleur connect la machine cible.
110
C.2. Rsultats exprimentaux
face PCI Express de notre contrleur, uniquement les transactions qui lui sont destines et les
ventuelles transactions diffuses tous les contrleurs.
La figure C.2 prsente notre contrleur tel quil est vu par le systme dexploitation dans la
machine cible. Pour nos exprimentations, nous avons gard les identifiants par dfaut de notre
carte de dveloppement (Pico E-17 assemble par Pico Computing). Notez que notre contrleur
ne dispose pas de mmoire interne projete dans lespace dadressage mmoire principale ni
dans lespace Port I/O. Bien que nous nayons dvelopp ni install de pilote pour cette carte de
dveloppement sur la machine cible, remarquez que celle-ci est malgr tout reconnue et active
par dfaut par le systme dexploitation.
user@cible$ lspci -v
[...]
0e:00.0 Memory controller: Pico Computing Device 0e17 (rev 01)
Subsystem: Device 4658:0000
Flags: bus master, fast devsel, latency 0, IRQ 10
Expansion ROM at f1e00000 [disabled] [size=1M]
Capabilities: <access denied>
La figure C.3 prsente un extrait des commandes excutes sur la machine moniteur et les
rsultats qui lui ont t renvoys. Puisque nous recevons un nombre important de paquets du
contrleur, nous avons uniquement gard, sur cette figure, deux exemples de transactions que
nous avons reues.
Nous remarquons que notre contrleur reoit deux types de transactions : des transactions
111
Annexe C. Plusieurs exemples dexprimentations avec le contrleur IronHide
de type memory ( gauche) et des transactions de type message ( droite). Nous rappelons que
les transactions de type memory sont utilises pour des accs aux mmoires internes des contr-
leurs qui sont projetes dans lespace dadressage principal de la mmoire. Cet accs est effec-
tu uniquement au dmarrage de la machine cible et correspond en ralit au chargement des
ROM dextensions par le BIOS, lesquelles contiennent des routines dinitialisation des contr-
leurs fournies par les constructeurs, et excutes par le BIOS. Le champ reqID prcise que cet
accs est initi par le processeur, au travers du contrleur mmoire situ dans le northbridge
dont lidentifiant de bus est 00:00.0 (cest--dire, bus 00, device 00 et function 0).
Nous recevons galement rgulirement des transactions de type message. Ce type de tran-
sactions vhiculent diffrents types dinformations entre les contrleurs PCI Express. Elles sont
utilises notamment pour signaler des interruptions, des erreurs ou pour vhiculer des mes-
sages de gestion dnergie. Il sagit ici dune requte propre aux chipsets Intel. En effet, le champ
msgcode positionn la valeur 0x7f dsigne un message spcifique aux constructeurs, et nous
reconnaissons le constructeur Intel par le vendorID positionn 0x8086. Malheureusement,
ce type de transaction message nest pas document dans les spcifications du chipset que nous
avons tudi. Nous ne savons pas, pour linstant, quoi correspond cette transaction ni les
donnes quelle contient.
user@cible$ lspci -v
[...]
0e:00.0 Memory controller: Pico Computing Device 0e17 (rev 01)
Subsystem: Device 4658:0000
Flags: bus master, fast devsel, latency 0, IRQ 10
Expansion ROM at f1e00000 [disabled] [size=1M]
Capabilities: <access denied>
user@cible$ sudo setpci -s 0e:00.0 COMMAND.W=0
user@cible$ lspci -v | grep -B 3 Flags
[...]
0e:00.0 Memory controller: Pico Computing Device 0e17 (rev 01)
Subsystem: Device 4658:0000
Flags: fast devsel, latency 0, IRQ 10
F IGURE C.4 Dsactivation du bit Bus Master Enable (BME) sur un contrleur
Une fois la fonctionnalit dsactive dans le contrleur, nous avons programm des ac-
cs de type DMA depuis la machine moniteur. La figure C.5 prsente le type de requtes que
nous avons initi depuis le contrleur. notre grand regret, les requtes daccs vers lespace
dadressage principal de la mmoire que nous avons gnres ont toutes abouti et il nous a
t possible deffectuer des accs DMA bien que le systme dexploitation ait dlibrment
112
C.2. Rsultats exprimentaux
configur le contrleur pour empcher ce type daccs. Lutilisation dune I/O MMU est alors
indispensable pour bloquer (au moins partiellement) les ventuelles attaques inities depuis les
contrleurs. Nous rappelons que les I/O MMU dsignent des units de gestion de la mmoire
physique ddies aux contrleurs dentres-sorties. Elles ont t initialement conues pour vir-
tualiser lespace dadressage principal de la mmoire pour les contrleurs. Avec lavnement de
la virtualisation, elles ont t tendues afin dassurer galement des proprits disolation. Il est
aujourdhui possible de configurer les I/O MMU pour associer chaque contrleur un ou plu-
sieurs domaines distincts. Ces dernires sassurent en particulier quun attaquant ne dtourne
pas un contrleur associ un domaine pour accder frauduleusement (par un accs de type
DMA) aux rgions de mmoire associes un autre domaine. Dans notre exemple, le contr-
leur nest associ aucun domaine tant donn que le bit BME nest plus positionn. LI/O
MMU (si elle est correctement configure) bloque alors tous les accs DMA de ce contrleur.
113
Annexe C. Plusieurs exemples dexprimentations avec le contrleur IronHide
cies (cest--dire, les paquets completion) sont routes en fonction de lidentifiant du contrleur
qui a initi la requte. Comme nous avons usurp lidentit dun autre contrleur, la rponse
va naturellement tre route vers le contrleur pour lequel nous essayons de nous faire pas-
ser. Prcisons que cette attaque aurait pu tre pare si les extensions matrielles Acess Control
Services (ACS) avaient t actives et correctement configures. Nous rappelons que les ACS
dsignent une technologie de contrle daccs implmente dans certains contrleurs PCI Ex-
press du chipset (son implmentation tant optionnelle). Il est possible, par exemple, dactiver
le service ACS Source Validation dans les diffrents contrleurs PCI Express du chipset afin de
leur faire vrifier systmatiquement que lidentit utilise par un contrleur correspond bien
celle qui lui a t attribue, empchant ainsi toute possibilit dusurpation didentit.
114
C.2. Rsultats exprimentaux
user@moniteur $ od -t x1 dump-pio-x58-via-controleur
00000000 8c 0a 0f af 24 92 04 ff 00 ff ff ff ff ff ff 00
*
00000020 01 ff ff ff 01 ff ff ff 01 ff ff ff 01 ff aa 00
00000030 01 ff ff ff 01 ff ff ff 01 ff ff ff 01 ff ff ff
00000040 98 10 ac ff ff ff ff ff ff ff ff ff ff ff ff ff
00000050 d0 06 03 ff ff ff ff ff ff ff ff ff ff ff ff ff
00000060 fe 2c ff ff 74 ff ff ff ff ff ff ff ff ff ff ff
00000070 ff 02 7d 01 0b 02 7d 01 ff ff ff ff ff ff ff ff
00000080 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000090 ff 01 00 00 ff ff ff 00 ff 00 00 00 ff ff ff 00
000000a0 0c ff ff ff 0c ff ff ff 0c ff ff ff 0c ff ff ff
000000b0 0c ff a0 7f 0c ff ff ff 0c ff ff ff 0c ff ff ff
000000c0 00 80 d6 69 84 00 ff bf 02 00 fe ef 06 00 fa b5
000000d0 00 00 ff ff ff ff ff ff ff ff ff ff ff ff 00 00
000000e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
000000f0 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[...]
F IGURE C.7 Espace Port I/O vu de notre contrleur connect un chipset Intel x58
Bien que lespace Port I/O soit aujourdhui peu usit, nous observons que des contrleurs
(par exemple, le contrleur de clavier, les contrleurs VGA, SATA, USB) continuent y proje-
ter certains de leurs registres. Le contrleur de clavier projette, par exemple, des registres aux
adresses 0x60 et 0x64 qui informent le systme dexploitation des vnements du clavier ou
de la souris. Nous avons exploit la possibilit de lire ces ports dentres-sorties depuis notre
contrleur sur le chipset Intel x58 (cf. figure C.7) pour implmenter un enregistreur de frappe
au clavier. Actuellement, nous sommes capables denregistrer les frappes de claviers de type
PS/2 et ventuellement des claviers de type USB lorsque loption USB Legacy Support est ac-
tive dans le BIOS. Nous rappelons que cette option permet dutiliser certains priphriques
USB (par exemple, un clavier, une souris, un priphrique de stockage) au dmarrage de la
machine, bien avant que les contrleurs USB ne soient initialiss par le systme dexploitation.
Dans cette configuration, le BIOS (ou plus prcisment la routine de traitement de la SMI) pr-
sente les claviers ou les souris USB au systme dexploitation comme tant des priphriques
PS/2. Cette exprimentation exploite la possibilit dinitier des accs peer-to-peer sur certains
chipsets. Cette attaque aurait galement pu tre pare par une configuration adquate des ACS.
En particulier, il aurait t possible de bloquer tout accs peer-to-peer en activant le service ACS
Egress Control.
Ces exprimentations esquissent ltendue des possibilits qui soffrent nous (et aux atta-
115
Annexe C. Plusieurs exemples dexprimentations avec le contrleur IronHide
quants) avec un tel contrleur. Dans les exprimentations prsentes dans cette annexe, nous
nous sommes principalement intresss aux requtes bien formes et qui ne dvient pas ou qui
dvient peu par rapport au protocole PCI Express. Lutilisation dIronHide pour valuer la ro-
bustesse des chipsets vis--vis de requtes invalides (et explicitement interdites) par le protocole
PCI Express est discute au chapitre 4. Prcisons, pour terminer, quIronHide a t conu avec
la capacit d muler un contrleur PCI Express quelconque. Il pourrait alors tre person-
nalis pour rpondre des besoins (dattaques ou de dfenses) bien spcifiques. En adaptant
son logiciel embarqu, il est possible de lutiliser, par exemple, pour valuer la robustesse des
pilotes de contrleurs dentres-sorties ou de priphriques.
116
Bibliographie
[Abbott et al. 76] Robert P. Abbott, Janet S. Chin, James E. Donnelley, William L. Konigsford,
Shigeru Tokubo, et Douglas A. Webb. Security Analysis and Enhancements of Compu-
ter Operating Systems. Rapport technique numro NBSIR 76-1041, Institute for Com-
puter Sciences and Technology, National Bureau of Standards, Washington DC, (WA,
USA), avril 1976. http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA436876.
[Abrial et al. 91] Jean-Raymond Abrial, Matthew K. O. Lee, David Neilson, P. N. Scharbach,
et Ib Holm Srensen. The B-Method. In Sren Prehn et Hans Toetenel, diteurs :
VDM Europe : Formal Developments Methods (VDM 91), volume 552 de Lecture Notes in
Computer Science, pages 398405, Noordwijkerhout (The Netherlands). Springer Berlin
Heidelberg, 21-25 octobre 1991. ISBN 978-3-540-54868-3. http://dx.doi.org/10.
1007/BFb0020001.
[Adelsbach et al. 03] Andr Adelsbach, Dominique Alessandri, Christian Cachin, Sadie Creese,
Yves Deswarte, Klause Kursawe, Jean-Claude Laprie, David Powell, Brian Randell,
James Riordan, Peter Ryan, William Simmonds, Rober Stroud, Paulo Verssimo, Mi-
chael Waidner, et Andreas Wespi. MAFTIA, Malicious and Accidental-Fault Tole-
rance for Internet Applications : Conceptual Model and Architecture. David Powell
et Robert Stroud, diteurs. Rapport technique, 31 janvier 2003. Research Project IST-
1999-11583, delivrable D21. http://research.cs.ncl.ac.uk/cabernet/www.
laas.research.ec.org/maftia/deliverables/D21.pdf.
[Agilent Technologies 12] Agilent Technologies. Agilent U4301A PCI Express 3.0 Analyzer Mo-
dule - Datasheet. USA, 26 mars 2012. http://cp.literature.agilent.com/
litweb/pdf/5990-5018EN.pdf.
[Aleph One 96] Aleph One. Smashing The Stack For Fun And Profit. Phrack Magazine, 49(14),
8 novembre 1996. http://www.phrack.org/issues.html?issue=49&id=14.
[Anderson 80] James P. Anderson. Computer security threat monitoring and surveillance.
Rapport technique , Contrat numro 79F296400, James P. Anderson Co., Washington
(WA, USA), 26 fvrier 1980. http://csrc.nist.gov/publications/history/
ande80.pdf.
[Anderson et Kuhn 98] Ross J. Anderson et Markus G. Kuhn. Low Cost Attacks on Tamper
Resistant Devices. In Bruce Christianson, Bruno Crispo, Mark Lomas, et Michael Roe,
diteurs : Proceedings of the 5th International Workshop on Security Protocols, volume 1361
de Lecture Notes in Computer Science, pages 125136, Paris (France). Springer Berlin Hei-
delberg, 7-9 avril 1998. ISBN 978-3-540-64040-0. http://dx.doi.org/10.1007/
BFb0028165.
[Aslam 95] Taimur Aslam. A Taxonomy Of Security Faults In The Unix Operating System.
Mmoire de D.E.A., Department of Computer Sciences, Purdue University, West
117
Bibliographie
118
University of Southern California, Marina Del Rey (CA, USA), mai 1978. http:
//csrc.nist.gov/publications/history/bisb78.pdf.
[Bishop 95] Matt Bishop. A Taxonomy of UNIX System and Network Vulnerabilities. Rap-
port technique CSE-95-8, Department of Computer Science, University of Califor-
nia, Davis (CA, USA), mai 1995. http://nob.cs.ucdavis.edu/bishop/notes/
1995-cse-8/1995-cse-8.pdf.
[Bjrner et Jones 78] Dines Bjrner et Cliff B. Jones. The Vienna Development Method : The Meta-
Language, volume 61 de Lecture Notes in Computer Science. Springer Berlin Heidelberg,
1978. ISBN 978-3-540-08766-3. http://dx.doi.org/10.1007/3-540-08766-4.
[Bockel 12] Jean-Marie Bockel. La cyberdfense : un enjeu mondial, une priorit nationale.
Rapport dinformation numro 681, Commission des affaires trangres, de la d-
fense et des forces armes, 18 juillet 2012. http://www.senat.fr/rap/r11-681/
r11-6811.pdf.
[Boileau 06] Adam Boileau. Hit by a Bus : Physical Access Attacks with FireWire. In RUXCON
2006, Melbourne (Australia). 30 septembre - 1 octobre 2006. http://www.ruxcon.
org.au/files/2006/firewire_attacks.pdf.
[Boneh et al. 97b] Dan Boneh, Richard A. DeMillo, et Richard J. Lipton. On the Importance of
Checking Cryptographic Protocols for Faults. In Walter Fumy, diteur : Proceedings of
the 16th Annual International Conference on Theory and Application of Cryptographic Tech-
niques (EUROCRYPT 97), volume 1233 de Lecture Notes in Computer Science, pages 37
51, Konstanz (Germany). Springer Berlin Heidelberg, 1997. ISBN 978-3-540-62975-7.
http://dx.doi.org/10.1007/3-540-69053-0_4.
[Boneh et al. 01a] Dan Boneh, Richard A. DeMillo, et Richard J. Lipton. On the Importance
of Eliminating Errors in Cryptographic Computations. Journal of Cryptology, 14(2):
101119, Springer-Verlag, 2001. ISSN 0933-2790. http://dx.doi.org/10.1007/
s001450010016.
[Bouissou et Bon 03] Marc Bouissou et Jean-Louis Bon. A new formalism that combines ad-
vantages of fault-trees and markov models : Boolean logic driven Markov processes.
Reliability Engineering & System Safety, 82(2):149163, Elsevier Editions with the Eu-
ropean Safety and Reliability Association, and the Safety Engineering and Risk Ana-
lysis Division, novembre 2003. ISSN 0951-8320. http://dx.doi.org/10.1016/
S0951-8320(03)00143-1.
[Brinkley et Schell 95] Donald L. Brinkley et Robert R. Schell. What is There to Worry About ?
An Introduction to the Computer Security Problem. In Marshall D. Abrams, Sushil
Jajodia, et Harold J. Podell, diteurs : Information Security : An Integrated Collection of Es-
says, pages 1139. IEEE Computer Society Press, Los Alamitos (CA, USA), 1995. ISBN
978-0-818-63662-2.
[Budruk et al. 03] Ravi Budruk, Don Anderson, et Ed Solari. PCI Express System Architecture.
PC System Architecture Series, MindShare Inc. Addison-Wesley Developers Press,
Boston (MA, USA), septembre 2003. ISBN 978-0-321-15630-3.
[Carrier et Grand 04] Brian Carrier et Joe Grand. A Hardware-based Memory Acquisition
Procedure for Digital Investigations. Digital Investigation Journal, 1(1):5060, f-
vrier 2004. ISSN 1742-2876. http://www.digital-evidence.org/papers/
tribble-preprint.pdf.
119
Bibliographie
[Cesare 99] Silvio Cesare. Kernel Function Hijacking. novembre 1999. http://www.ouah.
org/kernel-hijack.txt.
[Cheheyl et al. 81] Harris M. Cheheyl, Morrie Gasser, George A. Huff, et Jonathan K. Mil-
len. Verifying Security. ACM Computing Surveys (CSUR), 13(3):279339, ACM Press,
New York (NY, USA), septembre 1981. http://doi.acm.org/10.1145/356850.
356853.
[Chifflier et al. 11] Pierre Chifflier, Loc Duflot, Olivier Levillain, Fernand Lone Sang, Arnauld
Michelizza, Benjamin Morin, et Yves-Alexis Perez. Scurit et architecture PC : lim-
possible confiance ? Multi-System & Internet Security Cookbook (MISC), 58:1847, Les
ditions Diamond, Slestat (France), novembre/dcembre 2011.
[Clarke et Emerson 08] Edmund M. Clarke et E. Allen Emerson. Design and Synthesis of Syn-
chronization Skeletons Using Branching-Time Temporal Logic. In Orna Grumberg et
Helmut Veith, diteurs : 25 Years of Model Checking, volume 5000 de Lecture Notes in
Computer Science, pages 196215. Springer Berlin Heidelberg, 2008. ISBN 978-3-540-
69849-4. http://dl.acm.org/citation.cfm?id=648063.747438.
[Cohen 86] Fred Cohen. Computer Viruses. Thse de doctorat, Faculty of the grade school,
University of Southern California, Los Angeles (CA, USA), janvier 1986. http://
www.all.net/books/Dissertation.pdf.
[Collins 97d] Robert R. Collins. The Intel Pentium F00F Bug - Description and Workarounds.
dcembre 1997. http://www.rcollins.org/Errata/Dec97/F00FBug.html.
[Collins 12a] Robert R. Collins. Intel Bugs - The Errata Series. Page consulte en 2012. http:
//www.rcollins.org/Errata/ErrataSeries.html.
[Collins 12b] Robert R. Collins. Intel Secrets, Bugs and Undocumented Opcodes. Page consul-
te en 2012. http://www.rcollins.org/secrets/IntelSecrets.html.
[Collins 12c] Robert R. Collins. Undocumented OpCodes : SALC. Page consulte en 2012.
http://www.rcollins.org/secrets/opcodes/SALC.html.
[Common Criteria 12] Common Criteria. Common Criteria for Information Techno-
logy Security Evaluation - Part 1 : Introduction and general model. Ver-
sion 3.1, rvision 4, numro CCMB-2012-09-001, septembre 2012. http://www.
commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R4.pdf.
[Corbat 91] Fernando J. Corbat. On Building Systems That Will Fail. In ACM Turing
Award Lecture. 5 mars 1991. http://larch-www.lcs.mit.edu:8001/~corbato/
turing91/.
[Cormen et al. 09] Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, et Clifford Stein.
Introduction to Algorithms. MIT Press, Cambridge (MA, USA), 3edition, 2009. ISBN
978-0-262-03384-8.
[Cousot 01] Patrick Cousot. Abstract Interpretation Based Formal Methods and Future Chal-
lenges. In Reinhard Wilhelm, diteur : Informatics - 10 Years Back. 10 Years Ahead.,
volume 2000 de Lecture Notes in Computer Science, pages 138156. Springer Ber-
lin Heidelberg, 2001. ISBN 978-3-540-41635-7. http://dx.doi.org/10.1007/
3-540-44577-3_10.
[Cousot et Cousot 77] Patrick Cousot et Radhia Cousot. Abstract interpretation : a unified lat-
tice model for static analysis of programs by construction or approximation of fix-
points. In Conference Record of the Fourth Annual ACM SIGPLAN-SIGACT Symposium
120
on Principles of Programming Languages, pages 238252, Los Angeles (CA, USA). ACM
Press (NY, USA), 1977.
[crazylord 02] crazylord. Playing with Windows /dev/(k)mem. Phrack Magazine, 59(16), 28
juillet 2002. http://www.phrack.org/issues.html?id=16&issue=59.
[Creed 99] Creed. Knark - Kernel Based Linux Rootkit. 24 dcembre 1999. http://biblio.
l0t3k.net/magazine/en/b4b0/0009/b4b0-09.txt.
[Crenshaw 10] Adrian Crenshaw. Programmable HID USB Keyboard/Mouse Dongle
for Pen-testing. In DEF CON 18, Las Vegas (NV, USA). 29 juillet - 1 aot 2010.
https://www.defcon.org/images/defcon-18/dc-18-presentations/
Crenshaw/DEFCON-18-Crenshaw-PHID-USB-Device.pdf.
[Crouzet et al. 06] Yves Crouzet, Helene Waeselynck, Benjamin Lussier, et David Powell. The
SESAME Experience : from Assembly Languages to Declarative Models. In Proceedings
of the 2nd Workshop on Mutation Analysis (MUTATION 06 - ISSRE Workshops 06), Raleigh
(NC, USA). IEEE Computer Society, Los Alamitos (CA, USA), 7-10 novembre 2006.
ISBN 978-0-769-52897-7. http://dx.doi.org/10.1109/MUTATION.2006.14.
[Davis 88] Alan M. Davis. A Comparison of Techniques for the Specification of External Sys-
tem Behavior. Communications of the ACM, 31(9):10981115, ACM Press, New York
(NY, USA), septembre 1988. ISSN 0001-0782.
[Delugr 10] Guillaume Delugr. Closer to metal : reverse-engineering the Broad-
com NetExtremes firmware. In Hack.lu, Luxembourg. 27-29 octobre 2010.
http://esec-lab.sogeti.com/dotclear/public/publications/
10-hack.lu-nicreverse_slides.pdf.
[Deransart et al. 96] Pierre Deransart, Laurent Cervoni, et AbdelAli Ed-Dbali. Prolog : The Stan-
dard Reference Manual. Springer Berlin Heidelberg, 1996. ISBN 978-3-540-59304-1.
http://dx.doi.org/10.1007/978-3-642-61411-8.
[Desautels 11] Adriel Desautels. Netragards Hacker Interface Device (HID). Netragard, Inc.,
Boston (MA, USA), 24 juin 2011. http://pentest.netragard.com/2011/06/
24/netragards-hacker-interface-device-hid/.
[Deswarte 03] Yves Deswarte. La scurit des systmes dinformation. In Yves Deswarte et
Ludovic M, diteurs : Scurit des rseaux et systmes rpartis, Trait IC2, srie Rseaux
et Tlcoms, chapitre 1, pages 1565. Herms Science, octobre 2003. ISBN-10 2-7462-
0770-2.
[Deswarte et Gambs 12] Yves Deswarte et Sbastien Gambs. Cyber-attaques et cyber-dfenses :
problmatique et volution. Revue de llectricit et de llectronique (REE), (2):2335,
juin 2012. http://hal.inria.fr/hal-00736950.
[Devine et Vissian 09] Christophe Devine et Guillaume Vissian. Compromission physique par
le bus PCI. In Actes du 7e Symposium sur la Scurit des Technologies de lInformation et
des Communications (SSTIC 09), pages 169193. 3-5 juin 2009. http://actes.sstic.
org/SSTIC09/Compromission_physique_par_le_bus_PCI/.
[Diaz 82] Michel Diaz. Modelling and Analysis of Communication and Cooperation Protocols
Using Petri Net Based Models. In Proceedings of the IFIP WG6.1 Second International
Workshop on Protocol Specification, Testing and Verification, pages 465510, Amsterdam
(The Netherlands). North-Holland Publishing Co., 1982. ISBN 0-444-86481-4.
[Dijkstra 76] Edsger W. Dijkstra. A Discipline of Programming. Series in Automatic Computa-
tion. Prentice Hall PTR, Upper Saddle River (NJ, USA), 1976. ISBN 978-0-132-15871-8.
121
Bibliographie
122
[Falliere et al. 11] Nicolas Falliere, Liam O Murchu, et Eric Chien. W32.stuxnet dossier, ver-
sion 1.4. Rapport technique, Symantec Security Response, Cupertino (CA, USA), f-
vrier 2011. http://www.symantec.com/content/en/us/enterprise/media/
security_response/whitepapers/w32_stuxnet_dossier.pdf.
[Filiol 03] ric Filiol. Les virus informatiques : thorie, pratique et applications. Collection Iris.
Springer Paris, Paris (France), 2003. ISBN 978-2-287-98199-9. http://dx.doi.org/
10.1007/978-2-287-98240-8.
[Floyd 67] Robert W. Floyd. Assigning Meanings to Programs. Mathematical Aspects of Com-
puter Science, 19(19-32):1932, American Mathematical Society, Providence (RI, USA),
1967. ISBN 978-0-821-86728-0. http://www.eecs.berkeley.edu/~necula/
Papers/FloydMeaning.pdf.
[Forrester et Miller 00] Justin E. Forrester et Barton P. Miller. An empirical study of the ro-
bustness of Windows NT applications using random testing. In Proceedings of the 4th
conference on USENIX Windows Systems Symposium (WSS 00) - Volume 4, page 6, Seattle
(WA, USA). USENIX Association, Berkeley (CA, USA), 2000. http://usenix.org/
events/usenix-win2000/full_papers/forrester/forrester.pdf.
[Ganesh et al. 09] Vijay Ganesh, Tim Leek, et Martin Rinard. Taint-based directed whitebox
fuzzing. In Proceedings of the 31st International Conference on Software Engineering (ICSE
09), pages 474484, Vancouver (Canada). IEEE Computer Society, Washington DC
(WA, USA), 16-24 mai 2009. ISBN 978-1-4244-3453-4. http://dx.doi.org/10.
1109/ICSE.2009.5070546.
[Gazet 11] Alexandre Gazet. Sticky fingers & KBC Custom Shop. In Actes du 9e Sympo-
sium sur la Scurit des Technologies de lInformation et des Communications (SSTIC 11),
pages 180193, Rennes (France). 8-10 juin 2011. http://www.sstic.org/media/
SSTIC2011/SSTIC-actes/sticky_fingers_and_kbc_custom_shop/.
[Giuliani 11] Marco Giuliani. Mebromi : the first BIOS rootkit in the wild. Webroot, Broomfield
(CO, USA), 13 septembre 2011. http://blog.webroot.com/2011/09/13/.
[Glory et Bergerand 90] Anne Ccile Glory et Jean-Louis Bergerand. SAGA : conception de
logiciels et preuve de proprits - Lapproche synchrone. Gnie Logiciel et Systmes
Experts, (18):3744, 1990.
[Godefroid et al. 12] Patrice Godefroid, Michael Y. Levin, et David Molnar. SAGE : Whitebox
Fuzzing for Security Testing. Queue, 10(1):2027, ACM Press, New York (NY, USA),
janvier 2012. http://dx.doi.org/10.1145/2090147.2094081.
[Gross et Yellen 03] Jonathan L. Gross et Jay Yellen. Handbook of Graph Theory. Discrete Ma-
thematics and Its Applications. CRC Press, Boca Raton (FL, USA), 29 dcembre 2003.
ISBN 978-1584880905.
[Gruskovnjak 12] Jordan Gruskovnjak. Advanced Exploitation of Xen Hypervisor Sys-
ret VM Escape Vulnerability. Vupen Security, Montpellier (France), 4 septembre
2012. http://www.vupen.com/blog/20120904.Advanced_Exploitation_
of_Xen_Sysret_VM_Escape_CVE-2012-0217.php.
[Guttag et Horning 93] John V. Guttag et James J. Horning. Larch : Languages and Tools for For-
mal Specification. Springer New York, New York (NY, USA), 1993. ISBN 978-1-4612-
7636-4. http://dx.doi.org/10.1007/978-1-4612-2704-5.
[halflife 97] halflife. Shared Library Redirection Techniques. Phrack Magazine, 51(8), 1 sep-
tembre 1997. http://www.phrack.org/issues.html?id=8&issue=51.
123
Bibliographie
[Harel et al. 90] David Harel, Amir Pnueli, Hagi Lachover, Amnon Naamad, Michal Politi, Rivi
Sherman, Aharon Shtull-Trauring, et Mark Trakhtenbrot. STATEMATE : A Working
Environment for the Development of Complex Reactive Systems. IEEE Transactions
on Software Engineering, 16(4):403414, IEEE Press, Piscataway (NJ, USA), avril 1990.
http://dx.doi.org/10.1109/32.54292.
[Heasman 07] John Heasman. Implementing and Detecting a PCI Rootkit. In BlackHat DC,
Washington DC (WA, USA). 26 fvrier - 1 mars 2007. http://www.blackhat.com/
presentations/bh-dc-07/Heasman/Paper/bh-dc-07-Heasman-WP.pdf.
[Hoare 69] C A. R. Hoare. An Axiomatic Basis for Computer Programming. Communications
of the ACM, 12(10):576580, ACM Press, New York (NY, USA), octobre 1969. ISSN
0001-0782. http://dx.doi.org/10.1145/363235.363259.
[Holzleitner 09] Jrgen Holzleitner. Using feedback to improve black box fuzz testing of SAT
solvers. Mmoire de D.E.A., Institut for Formal Model and Verification, Johannes Ke-
pler University Linz, Linz (Austria), dcembre 2009. http://80.66.43.7/~jh/
UniProjects/images/fuzz/fuzz.pdf.
[Howard 97] John Douglas Howard. An Analysis of Security Incidents on the Internet. Thse de
doctorat, Carnegie Mellon University, Pittsburgh (PA, USA), avril 1997. www.cert.
org/archive/pdf/JHThesis.pdf.
[IceLord 07] IceLord. BIOS Rootkit : Welcome home, my Lord ! 26 avril 2007. http://blog.
csdn.net/icelord/article/details/1604884.
[Igure et Williams 08] Vinay M. Igure et Ronald D. Williams. Taxonomies of Attacks and Vul-
nerabilities in Computer Systems. IEEE Communications Surveys & Tutorials, 10(1):6
19, IEEE Press, Piscataway (NJ, USA), janvier-avril 2008. ISSN 1553-877X. http:
//dx.doi.org/10.1109/COMST.2008.4483667.
[ITSEC 91] ITSEC. Information Technology Security Evaluation Criteria Provisional Harmonised
Criteria. Commission of the European Communities. DG XIII., Document COM(90)
314, Office for Official Publications of the European Communities, Luxembourg, juin
1991. ISBN-10 9-2826-3004-8. http://www.ssi.gouv.fr/site_documents/
ITSEC/ITSEC-uk.pdf.
[Jones 90] Cliff B. Jones. Systematic Software Development using VDM. Prentice-Hall, Inc., Upper
Saddle River (NJ, USA), 1990. ISSN 978-0-13-880733-7. http://www.vdmbook.com/
jones90.pdf.
[Kennedy 10] David Kennedy. Hacking your perimeter - Not everyone needs to use
zero days . . . . 2010. http://www.secmaniac.com/files/Hacking%20the%
20perimeter.pdf.
[Kocher et al. 99] Paul C. Kocher, Joshua Jaffe, et Benjamin Jun. Differential Power Analysis. In
Michael Wiener, diteur : Proceedings of the 19th Annual International Cryptology Confe-
rence on Advances in Cryptology (CRYPTO 99), volume 1666 de Lecture Notes in Compu-
ter Science, pages 388397. Springer Berlin Heidelberg, 1999. ISBN 978-3-540-66347-8.
http://dx.doi.org/10.1007/3-540-48405-1_25.
[Krahmer 05] Sebastian Krahmer. x86-64 buffer overflow exploits and the borrowed code
chunks exploitation technique. Rapport technique, 28 septembre 2005. http://www.
suse.de/~krahmer/no-nx.pdf.
[Krsul 98] Ivan Krsul. Software Vulnerability Analysis. Thse de doctorat, Department of
Computer Sciences, Purdue University, West Lafayette (IN, USA), 1998. https:
//www.cerias.purdue.edu/techreports-ssl/public/98-09.pdf.
124
[Laarouchi 09] Youssef Laarouchi. Scurits (immunit et innocuit) des architectures ouvertes
niveaux de criticit multiples : application en avionique. Thse de doctorat, Insti-
tut National des Sciences Appliques (INSA) de Toulouse, Toulouse (France), 30
novembre 2009. http://tel.archives-ouvertes.fr/docs/00/46/89/23/
PDF/Manuscrit_Youssef_Laarouchi.pdf.
[Lacombe et al. 09] ric Lacombe, Vincent Nicomette, et Yves Deswarte. A Hardware-Assisted
Virtualization-Based Approach on How to Protect the Kernel Space from Malicious
Actions. In Proceedings of the 18th EICAR Annual Conference, Berlin (Germany). 11-
12 mai 2009. http://www.eicar.org/files/eicar2009-elacombe-slides.
pdf.
[Landwehr et al. 94] Carl E. Landwehr, Alan R. Bull, John P. McDermott, et William S. Choi.
A Taxonomy of Computer Program Security Flaws, with Examples. ACM Computer
Survey, 26(3):211254, ACM Press, New York (NY, USA), septembre 1994. ISSN 0360-
0300. http://dx.doi.org/10.1145/185403.185412.
[Laprie 04] Jean-Claude Laprie. Sret de fonctionnement des systmes : concepts de base
et terminologie. Revue de llectricit et de llectronique (REE), (11):95105, novembre
2004.
[Laprie et al. 96] Jean-Claude Laprie, Jean Arlat, Jean-Paul Blanquart, Alain Costes, Yves Crou-
zet, Yves Deswarte, Jean-Charles Fabre, Hubert Guillermain, Mohamed Kaniche, Ka-
rama Kanoun, Corinne Mazet, David Powell, Christophe Rabjac, et Pascale Thve-
nod. Guide de la Sret de Fonctionnement. Cpadus, 2e dition, 1996. ISBN 978-2-854-
28382-2.
[LeCroy Corporation 12] LeCroy Corporation. Summit Z3-16 PCI Express Multi-Lane Exerci-
ser - Product Datasheet, mai 2012. http://cdn.lecroy.com/files/pdf/lecroy_
summit_z3-16_datasheet.pdf.
[Li et al. 11] Yanlin Li, Jonathan M. McCune, et Adrian Perrig. VIPER : verifying the integrity
of PERipherals firmware. In Proceedings of the 18th ACM conference on Computer and
Communications Security (CCS 11), pages 316, Chicago (IL, USA). ACM Press, New
York (NY, USA), 17-21 octobre 2011. ISBN 978-1-4503-0948-6. http://dx.doi.org/
10.1145/2046707.2046711.
[Lindqvist et Jonsson 97] Ulf Lindqvist et Erland Jonsson. How to Systematically Classify
Computer Security Intrusions. In Proceedings of the IEEE Symposium on Security and Pri-
vacy, pages 154163, Oakland (CA, USA). IEEE Computer Society, may 1997. http:
//dx.doi.org/10.1109/SECPRI.1997.601330.
[Lineberry 09] Anthony Lineberry. Alice in User-Land : Hijacking the Linux Kernel via
/dev/mem. BlackHat Europe, Amsterdam (The Netherlands), 14-17 avril 2009.
http://www.blackhat.com/presentations/bh-europe-09/Lineberry/
BlackHat-Europe-2009-Lineberry-code-injection-via-dev-mem.pdf.
[Lone Sang et al. 10] Fernand Lone Sang, Vincent Nicomette, et Yves Deswarte. Dmonstration
dune attaque par partage didentifiants entre un contrleur FireWire et un contrleur
rseau. janvier 2010. http://homepages.laas.fr/nicomett/Videos/.
[Lone Sang et al. 11a] Fernand Lone Sang, Vincent Nicomette, et Yves Deswarte. Attaques
par entre-sortie et contremesures. In Actes de la Journe Scurit des Systmes & Su-
ret des Logiciels (3SL), pages 1113, Saint-Malo (France). 10 mai 2011. http://www.
univ-orleans.fr/lifo/evenements/3SL/actes/3sl.pdf.
125
Bibliographie
[Lone Sang et al. 11b] Fernand Lone Sang, Vincent Nicomette, et Yves Deswarte. Dmonstra-
tion dune attaque pair--pair depuis un priphrique FireWire vers un contrleur gra-
phique. janvier 2011. http://homepages.laas.fr/nicomett/Videos/.
[Lone Sang et al. 11c] Fernand Lone Sang, Vincent Nicomette, et Yves Deswarte. I/O at-
tacks in Intel PC-based architectures and countermeasures. In Proceedings of
the 1st SysSec Workshop, pages 1825, Amsterdam (The Netherlands). 6 juillet
2011. http://www.syssec-project.eu/media/page-media/3/syssec-d2.
3-1st-project-workshop-proceedings.pdf.
[Lone Sang et al. 12a] Fernand Lone Sang, Vincent Nicomette, et Yves Deswarte. Dmons-
tration dune attaque par accs pair--pair depuis ironhide. janvier 2012. http:
//homepages.laas.fr/nicomett/Videos/.
[Lone Sang et al. 12b] Fernand Lone Sang, Vincent Nicomette, et Yves Deswarte. IronHide :
plate-forme dattaques par entres-sorties. In Actes du 10e Symposium sur la Scurit des
Technologies de lInformation et des Communications (SSTIC 12), pages 237265, Rennes,
France. 6-8juin 2012.
[Lone Sang et al. 11] Fernand Lone Sang, Vincent Nicomette, Yves Deswarte, et Loc Duflot.
Attaques DMA peer-to-peer et contre-mesures. In Actes du 9e Symposium sur la Scu-
rit des Technologies de lInformation et des Communications (SSTIC 11), pages 150179,
Rennes (France). 8-10 juin 2011. http://www.sstic.org/media/SSTIC2011/
SSTIC-actes/attaques_dma_peer-to-peer_et_contremesures/.
[Lone Sang et al. 10a] Fernand Lone Sang, ric Lacombe, Vincent Nicomette, et Yves
Deswarte. Analyse de lefficacit du service fourni par une IOMMU. In
Actes du 8e Symposium sur la Scurit des Technologies de lInformation et des
Communications (SSTIC 10), pages 189214, Rennes (France). 9-11 juin 2010.
http://www.sstic.org/media/SSTIC2010/SSTIC-actes/Analyse_de_
l_efficacite_du_service_fourni_par_une_/.
[Lone Sang et al. 10b] Fernand Lone Sang, ric Lacombe, Vincent Nicomette, et Yves Deswarte.
Exploiting an I/OMMU vulnerability. In Proceedings of the 5th International Confe-
rence on Malicious and Unwanted Software (MALWARE 10), pages 7 14, Nancy (France).
IEEE, 19-20 octobre 2010. ISBN 978-1-4244-9355-5. http://dx.doi.org/10.1109/
MALWARE.2010.5665798.
[Lough 01] Daniel L. Lough. A Taxonomy of Computer Attacks with Applications to
Wireless Networks. Thse de doctorat, Faculty of the Virginia Polytechnic
Institute and State University, Blacksburg (VA, USA), avril 2001. http:
//scholar.lib.vt.edu/theses/available/etd-04252001-234145/
unrestricted/lough.dissertation.pdf.
[Martin 07] Antonio Martin. FireWire memory dump of a Windows XP computer : a forensic
approach. Rapport technique, FriendsGlobal, 2007. http://www.friendsglobal.
com/papers/FireWire%20Memory%20Dump%20of%20Windows%20XP.pdf.
[May et Woods 79] Timothy C. May et Murray H. Woods. Alpha-Particle-Induced Soft Errors
in Dynamic Memories. IEEE Transactions on Electron Devices, 26(1):29, Institute of
Electrical and Electronics Engineers, New York (NY, USA), jan 1979. ISSN 0018-9383.
http://dx.doi.org/10.1109/T-ED.1979.19370.
[Maynor 05] David Maynor. 0wn3d by everything else - USB/PCMCIA Issues. In CanSecWest/-
core05, Vancouver (Canada). 4-5 mai 2005. http://cansecwest.com/core05/
DMA.ppt.
126
[Miller et al. 90] Barton P. Miller, Louis Fredriksen, et Bryan So. An empirical study of the
reliability of UNIX utilities. Communications of the ACM, 33(12):3244, ACM Press,
New York (NY, USA), dcembre 1990. ISSN 0001-0782. http://dx.doi.org/10.
1145/96267.96279.
[Miller et al. 07] Barton P. Miller, Gregory Cooksey, et Fredrick Moore. An empirical study of
the robustness of MacOS applications using random testing. SIGOPS Operating Systems
Review, 41(1):7886, ACM Press, New York (NY, USA), janvier 2007. ISSN 0163-5980.
http://dx.doi.org/10.1145/1228291.1228308.
[Miller et Peterson 07] Charlie Miller et Zachary N. J. Peterson. Analysis of Muta-
tion and Generation-Based Fuzzing. Rapport technique, Independent Security
Evaluators, mars 2007. http://securityevaluators.com/files/papers/
analysisfuzzing.pdf.
[ModularLogix 10] ModularLogix. MLX-1000-XC5V Module - Product Data Sheet. 4 oc-
tobre 2010. http://files.modularlogix.com/Documents/MLX-1000-XC5V/
MLX-1000-XC5V%20Datasheet.pdf.
[Myers et al. 04] Glenford J. Myers, Corey Sandler, Tom Badgett, et Todd M. Thomas. The Art of
Software Testing. Business Data Processing : a Wiley Series. John Wiley & Sons, Inc.,
New York (NY, USA), 2004. ISBN 978-0-471-46912-4. http://dx.doi.org/10.
1002/stvr.322/.
[Namestnikov 12] Yury Namestnikov. Kaspersky Security Bulletin - Statistics 2011. Kas-
persky Lab ZAO, 01 mars 2012. http://www.securelist.com/en/analysis/
204792216/Kaspersky_Security_Bulletin_Statistics_2011.
[Nergal 01] Nergal. The Advanced Return-into-lib(c) Exploits : PaX case study. Phrack Maga-
zine, 58(4), 28 dcembre 2001. http://www.phrack.org/issues.html?issue=
58&id=4.
[Neumann et Parker 89] Peter G. Neumann et Donn B. Parker. A Summary of Computer Mi-
suse Techniques. In Proceedings of the 12th National Computer Security Conference, pages
396407, Baltimore (MD, USA). National Institute of Standards and Technology/Na-
tional Computer Security Center (NIST/NCSC), 10-13 octobre 1989.
[Oehlert 05] Peter Oehlert. Violating Assumptions with Fuzzing. IEEE Security and Privacy,
3(2):5862, IEEE Educational Activities Department, Piscataway (NJ, USA), mars 2005.
http://dx.doi.org/10.1109/MSP.2005.55.
[Parker 75] Donn B. Parker. Computer Abuse Perpetrators and Vulnerabilities of Computer
Systems. In Proceedings of the National Computer Conference and Exposition, American
Federation of Information Processing Societies (AFIPS). ACM Press, New York (NY,
USA), 7-10 juin 1975. http://dx.doi.org/10.1145/1499799.1499810.
[Petri 62] Carl Adam Petri. Kommunikation mit Automaten. Thse de doctorat, Institut fr
Instrumentelle Mathematik, Schriften des IIM Nr. 2, Universitt Hamburg, Hamburg
(Germany), 20 juin 1962. http://edoc.sub.uni-hamburg.de/informatik/
volltexte/2011/160/.
[Petroni et al. 04] Nick L. Jr. Petroni, Timothy Fraser, Jesus Molina, et William A. Arbaugh. Co-
pilot - a Coprocessor-based Kernel Runtime Integrity Monitor. In Proceedings of the 13th
USENIX Security Symposium (SSYM 04), San Diego (CA, USA). USENIX Association,
Berkeley (CA, USA), 9-13 aot 2004. http://www.usenix.org/events/sec04/
tech/full_papers/petroni/petroni.pdf.
127
Bibliographie
[Pico Computing 11] Pico Computing. Pico Computing - the FPGA Computing Experts. Page
consulte en 2011. http://www.picocomputing.com/e_series.html.
[Pisani et al. 10] Jason Pisani, Paul Caruga, et Richard Rushing. USB-HID - Ha-
cker Interface Design. In BlackHat USA, Las Vegas (NV, USA). 28-29 juillet
2010. https://media.blackhat.com/bh-us-10/presentations/Rushing/
BlackHatUSA-2010-Rushing-USB-HID-slides.pdf.
[Pragmatic et THC 99] Pragmatic et THC. (nearly) Complete Linux Loadable Kernel Modules.
The definitive guide for hackers, virus coders and system administrators. mai 1999.
http://www.thc.org/papers/LKM_HACKING.html.
[QiHoo 360 11] QiHoo 360. 360 has published a technical analysis of the BMW virus. Qihoo
360 Technology Co. Ltd., Beijing (China), 2 septembre 2011. http://bbs.360.cn/
4005462/251096134.html.
[Queille et Sifakis 82] Jean-Pierre Queille et Joseph Sifakis. Specification and Verification of
Concurrent Systems in CESAR. In Mariangiola Dezani-Ciancaglini et Ugo Montanari,
diteurs : Proceedings of the 5th Colloquium on International Symposium on Programming,
volume 137 de Lecture Notes in Computer Science, pages 337351, London (GB). Springer
Berlin Heidelberg, 1982. ISBN 978-3-540-11494-9. http://dl.acm.org/citation.
cfm?id=647325.721668.
[Rogers et Ruppersberger 12] Mike Rogers et Dutch Ruppersberger. Investigative Re-
port on the U.S. National Security Issues Posed by Chinese Telecommuni-
cations Companies Huawei and ZTE. Rapport denqute, Permanent Select
Committee on Intelligence, U.S. House of Representatives, 8 octobre 2012.
http://intelligence.house.gov/sites/intelligence.house.gov/
files/Huawei-ZTE%20Investigative%20Report%20(FINAL).pdf.
[Roper 92] Marc Roper. Software Testing : A Selected Annotated Bibliography. Software Testing,
Verification and Reliability, 2(3):113132, John Wiley & Sons, Inc., New York (NY, USA),
1992. ISSN 1099-1689. http://dx.doi.org/10.1002/stvr.4370020303.
[Rushby et al. 91] J. Rushby, F. von Henke, et S. Owre. An Introduction to Formal Specification
and Verification Using EHDM. Rapport technique numro SRI-CSL-91-02, Menlo Park
(CA, USA), 1991. http://www.csl.sri.com/papers/csl-91-2/csl-91-2.
ps.
[Rutkowska 07] Joanna Rutkowska. Beyond The CPU : Defeating Hardware Based
RAM Acquisition. In BlackHat DC, Washington DC (WA, USA). 26-27 fvrier
2007. http://www.blackhat.com/presentations/bh-dc-07/Rutkowska/
Presentation/bh-dc-07-Rutkowska-up.pdf.
[Rutkowska et Wojtczuk 08] Joanna Rutkowska et Rafa Wojtczuk. Preventing and Detecting
Xen Hypervisor Subversions. In Black Hat USA, Las Vegas (NV, USA). 6-7 aot 2008.
http://invisiblethingslab.com/resources/bh08/part2-full.pdf.
[Schneier 99] Bruce Schneier. Attack Trees - Modeling security threats. Dr. Dobbs Journal of Soft-
ware Tools, 24(12), 1 dcembre 1999. http://www.drdobbs.com/%20architect/
184411129.
[Shacham 07] Hovav Shacham. The Geometry of Innocent Flesh on the Bone : Return-into-
libc without Function Calls (on the x86). In Proceedings of the 14th ACM conference on
Computer and Communications Security (CCS 07), pages 552561, Alexandria (VA, USA).
ACM Press, New York (NY USA), 29 octobre - 2 novembre 2007. ISBN 978-1-59593-
703-2. http://dx.doi.org/10.1145/1315245.1315313.
128
[Shamir et Tromer 04] Adi Shamir et Eran Tromer. Acoustic cryptanalysis - On nosy people
and noisy machines. Rump Session at the 23th Annual International Conference on the
Theory and Applications of Cryptographic Techniques (EUROCRYPT O4), Interlaken
(Switzerland), 2-6 mai 2004. http://tau.ac.il/~tromer/acoustic/.
[Sheyner 04] Oleg Mikhail Sheyner. Scenario Graphs and Attack Graphs. Thse de doctorat,
School of Computer Science, Computer Science Department, Carnegie Mellon Uni-
versity, Pittsburgh (PA, USA), 14 avril 2004. http://reports-archive.adm.cs.
cmu.edu/anon/anon/usr0/ftp/usr/ftp/2004/CMU-CS-04-122.pdf.
[Shirey 94] Robert W. Shirey. Security Architecture for Internet Protocols : A Guide for Protocol
Designs and Standards. novembre 1994. Internet Draft : draft-irtf-psrg-secarch-sect1-
00.
[Skorobogatov et Anderson 03] Sergei P. Skorobogatov et Ross J. Anderson. Optical Fault In-
duction Attacks. In Burton S. Kaliski, etin K. Ko, et Christof Paar, diteurs : Pro-
ceeding of the 4th International Workshop on Cryptographic Hardware and Embedded Sys-
tems (CHES 02), volume 2523 de Lecture Notes in Computer Science, pages 212, Red-
wood City (CA, USA). Springer Berlin Heidelberg, 2003. ISBN 978-3-540-00409-7.
http://dx.doi.org/10.1007/3-540-36400-5_2.
[Solar Designer 97] Solar Designer. Getting around non-executable stack (and fix). 10 aot
1997. http://seclists.org/bugtraq/1997/Aug/63.
[Song et al. 01] Dawn X. Song, David Wagner, et Xuqing Tian. Timing Analysis of Keystrokes
and Timing Attacks on SSH. In Proceedings of the 10th USENIX Security Symposium
(SSYM 01), pages 2525, Washington DC (WA, USA). USENIX Association, Berke-
ley (CA, USA), 13-17 aot 2001. http://static.usenix.org/events/sec01/
full_papers/song/song.pdf.
[Spafford 88] Eugene H. Spafford. The Internet Worm Program : An Analysis. Rapport
technique numro CSD-TR-823, Department of Computer Sciences, Purdue Uni-
versity, West Lafayette (IN, USA), 1988. http://spaf.cerias.purdue.edu/
tech-reps/823.pdf.
[Spengler 12] Brad Spengler. grsecurity. Page consulte en 2012. http://grsecurity.
net/.
[Spivey 88a] Mike J. Spivey. Understanding Z : A Specification Language and its Formal Semantics,
volume 3 de Cambridge Tracts in Theoretical Computer Science. Cambridge University
Press, New York (NY, USA), 1988. ISBN 978-0-521-05414-0.
[Spivey 92b] Mike J. Spivey. The Z Notation : A Reference Manual. International Series in Com-
puter Science. Prentice Hall International, Ltd., Hertfordshire (GB), 1992. ISBN 978-0-
139-78529-0. http://spivey.oriel.ox.ac.uk/~mike/zrm/.
[styx 12] styx. Infecting Loadable Kernel Modules - Kernel Versions 2.6.x/3.0.x. Phrack Ma-
gazine, 68(11), 14 avril 2012. http://www.phrack.org/issues.html?issue=
68&id=11#article.
[Sutton et al. 07] Michael Sutton, Adam Greene, et Pedram Amini. Fuzzing : Brute Force Vulne-
rability Discovery. Addison-Wesley Professional, 2007.
[ter Huurne 12] Maarten ter Huurne. [PATCH] /dev/mem : Add kernel config option to omit
this device. 29 mars 2012. http://lkml.org/lkml/2012/3/29/403.
[TESO 04] Team TESO. Adore-ng Rootkit. 6 janvier 2004. http://stealth.7350.org/
rootkits/adore-ng-0.23.tgz.
129
Bibliographie
130
[Weyuker 82] Elaine J. Weyuker. On Testing Non-Testable Programs. The Computer Journal,
25(4):465470, 1982. http://dx.doi.org/10.1093/comjnl/25.4.465.
[Wojtczuk et Rutkowska 09a] Rafa Wojtczuk et Joanna Rutkowska. Attacking SMM Me-
mory via Intel CPU Cache Poisoning. Rapport technique, Invisible Things Lab (ITL),
19 mars 2009. http://invisiblethingslab.com/resources/misc09/smm_
cache_fun.pdf.
[Wojtczuk et Rutkowska 11b] Rafa Wojtczuk et Joanna Rutkowska. Following the White Rab-
bit : Software Attacks against Intel VT-d. Rapport technique, Invisible Things Lab
(ITL), mai 2011. http://www.invisiblethingslab.com/resources/2011/
Software%20Attacks%20on%20Intel%20VT-d.pdf.
[Wojtczuk et al. 09] Rafa Wojtczuk, Joanna Rutkowska, et Alexander Tereshkin. Another
Way to Circumvent Intel Trusted Execution Technology - Tricking SENTER into mis-
configuring VT-d via SINIT bug exploitation. Rapport technique, Invisible Things
Lab, dcembre 2009. http://invisiblethingslab.com/resources/misc09/
Another%20TXT%20Attack.pdf.
[Wright 87] Peter Wright. SpycatcherThe Candid Autobiography of a Senior Intelligence Officer.
Viking Pr, juillet 1987. ISBN 0-85561-098-0.
[Xilinx 10a] Xilinx. LogiCORE IP PLBv46 RC/EP Bridge for PCI Express - Product Specifica-
tion. 14 dcembre 2010. http://www.xilinx.com/support/documentation/
ip_documentation/plbv46_pcie.pdf.
[Xilinx 11b] Xilinx. LogiCORE IP Endpoint Block Plus for PCI Express - Product Specifica-
tion. 22 juin 2011. http://www.xilinx.com/support/documentation/ip_
documentation/pcie_blk_plus/v1_15/pcie_blk_plus_ds551.pdf.
[Yen et al. 03] Sung-Ming Yen, Sangjae Moon, et Jae-Cheol Ha. Hardware Fault Attack on RSA
with CRT Revisited. In PilJoong Lee et ChaeHoon Lim, diteurs : Proceedings of the
5th International Conference on Information Security and Cryptology (ICISC 02), volume
2587 de Lecture Notes in Computer Science, pages 374388, Seoul (Korea). Springer Berlin
Heidelberg, 2003. ISBN 978-3-540-00716-6. http://dl.acm.org/citation.cfm?
id=1765361.1765394.
131
Bibliographie
132
Rsum
Les attaques ciblant les systmes informatiques vont aujourdhui au del de simples logi-
ciels malveillants et impliquent de plus en plus des composants matriels. Cette thse sin-
tresse cette nouvelle classe dattaques et traite, plus prcisment, des attaques par entres-
sorties qui dtournent des fonctionnalits lgitimes du matriel, tels que les mcanismes entres-
sorties, diffrentes fins malveillantes. Lobjectif est dtudier ces attaques, qui sont extrme-
ment difficiles dtecter par des techniques logicielles classiques (dans la mesure o leur mise
en uvre ne ncessite pas lintervention des processeurs) afin de proposer des contre-mesures
adaptes, bases sur des composants matriels fiables et incontournables. Ce manuscrit se
concentre sur deux cas : celui des composants matriels qui peuvent tre dlibrment conus
pour tre malveillants et agissants de la mme faon quun programme intgrant un cheval de
Troie ; et celui des composants matriels vulnrables qui ont t modifis par un pirate informa-
tique, localement ou au travers du rseau, afin dy intgrer des fonctions malveillantes (typi-
quement, une porte drobe dans son firmware). Pour identifier les attaques par entres-sorties,
nous avons commenc par laborer un modle dattaques qui tient compte des diffrents ni-
veaux dabstraction dun systme informatique. Nous nous sommes ensuite appuys sur ce
modle dattaques pour les tudier selon deux approches complmentaires : une analyse de
vulnrabilits traditionnelle, consistant identifier une vulnrabilit, dvelopper des preuves
de concept et proposer des contre-mesures ; et une analyse de vulnrabilits par fuzzing sur les
bus dentres-sorties, reposant sur un outil dinjection de fautes que nous avons conu, baptis
IronHide, capable de simuler des attaques depuis un composant matriel malveillant. Les r-
sultats obtenus pour chacunes de ces approches sont discuts et quelques contre-mesures aux
vulnrabilits identifies, bases sur des composants matriels existants, sont proposes.
Mots-cls: scurit informatique, attaques par entres-sorties, modle dattaques, analyse de
vulnrabilits, fuzzing.
Abstract
Nowadays, attacks against computer systems may involve hardware components in
order to bypass the numerous countermeasures against malicious software. This PhD thesis
focuses on this novel class of attacks and specifically deals with Input/Output attacks. In such
attacks, attackers divert legitimate hardware features, such as I/O mechanisms, to achieve dif-
ferent malicious actions. Since detecting such attacks by conventional software techniques is
not easy (as far as they do not require the intervention of the CPU), we have analyzed these at-
tacks in order to propose appropriate countermeasures based mainly on reliable and unavoid-
able hardware components. This manuscript focuses on two cases : hardware components that
can be deliberately designed to be malicious and acting in the same way as a program incor-
porating a Trojan horse ; and vulnerable hardware components that have been modified by a
hacker, either locally or through the network, to include malicious functions (typically a back-
door in the firmware). To identify the potential I/O attacks, we developed an attack model
which takes into account the different abstraction levels in a computer system. Then, we stud-
ied these attacks with two complementary approaches : the classical approach to vulnerability
analysis consisting in identifying a vulnerability, developing a proof-of-concept and proposing
countermeasures ; and fuzzing-based vulnerability analysis, using IronHide, a fault injection
tool we have designed, which is able to simulate a powerful malicious hardware. The results
obtained with both approaches are discussed and several countermeasures to the vulnerabili-
ties we identified, based on existing hardware components, are proposed.
Keywords: computer security, I/O attacks, attack model, vulnerability analysis, fuzzing.
133
134