Thesis Fernand Lone Sang

THE` SE
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
Presentee et soutenue par :

Fernand Lone Sang
Le 27 novembre 2012
Titre :
`
Protection des systemes
informatiques contre les attaques par entrees-sorties
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
Chapitre 1 Actions malveillantes impactant la scurit des systmes informatiques 5

1.1 Scurit des systmes informatiques . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.1 Concepts et terminologie des systmes . . . . . . . . . . . . . . . . . . . . 6
1.1.2 Sret de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.3 Scurit des systmes informatiques . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Classification des attaques sur les systmes informatiques . . . . . . . . . . . . . 11
1.2.1 Attaques agissant au niveau des systmes logiciels . . . . . . . . . . . . . 12
1.2.2 Attaques agissant au niveau des systmes matriels . . . . . . . . . . . . . 16
1.2.3 Attaques agissant au niveau des canaux de communication . . . . . . . . 18
1.2.4 Attaques agissant au niveau des canaux auxiliaires . . . . . . . . . . . . . 20
1.3 Mthodes et techniques pour llimination des fautes . . . . . . . . . . . . . . . . 24
1.3.1 Analyse statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3.2 Preuve mathmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.3 Analyse de comportement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.4 Excution symbolique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapitre 2 laboration dun modle dattaques 29

2.1 Infrastructure matrielle dun systme informatique . . . . . . . . . . . . . . . . . 29
2.1.1 Architectures de communication . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.2 Composants matriels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2 Modle dattaques bas sur les interactions entre les composants . . . . . . . . . . 34
2.2.1 Modle des actions lmentaires et des attaques lmentaires . . . . . . . 35
2.2.2 Squences dactions et dattaques lmentaires . . . . . . . . . . . . . . . . 37
v
Table des matires
2.2.3 Application un modle de systme informatique . . . . . . . . . . . . . . 38

2.3 Illustration du modle par plusieurs exemples rels dattaque . . . . . . . . . . . 41
2.3.1 Usurpation didentit de priphriques USB . . . . . . . . . . . . . . . . . 41
2.3.2 Modification dune ROM flashable dextension PCI . . . . . . . . . . . . . 45
2.3.3 Modification de la routine de traitement de la SMI . . . . . . . . . . . . . . 46
2.4 Limites du modle dattaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Chapitre 3 Mise en uvre dattaques par entres-sorties sur une architecture PC 49

3.1 Aperu de larchitecture Intel-PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.1 Infrastructure matrielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.2 Espaces dadressage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1.3 Modes dentre-sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2 Contrle des accs directs la mmoire centrale . . . . . . . . . . . . . . . . . . . 57
3.2.1 Attaques par accs direct la mmoire . . . . . . . . . . . . . . . . . . . . 58
3.2.2 Quelques contre-mesures spcifiques . . . . . . . . . . . . . . . . . . . . . 61
3.2.3 Contre-mesure gnrique : une I/O MMU . . . . . . . . . . . . . . . . . . 62
3.2.4 Attaques par partage didentifiants . . . . . . . . . . . . . . . . . . . . . . 66
3.2.5 Contre-mesures complmentaires . . . . . . . . . . . . . . . . . . . . . . . 67
3.3 Contrle des accs pair--pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.3.1 Attaques par accs pair--pair . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.3.2 Mise en uvre sur plusieurs chipsets rcents . . . . . . . . . . . . . . . . . 70
3.3.3 Contre-mesures envisageables . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Chapitre 4 Application des techniques de fuzzing sur les bus dentres-sorties 77

4.1 IronHide : outil dinjection de fautes sur les bus dentres-sorties . . . . . . . . . 78
4.1.1 Introduction aux bus PCI Express . . . . . . . . . . . . . . . . . . . . . . . 78
4.1.2 Contrleur dentres-sorties IronHide . . . . . . . . . . . . . . . . . . . . . 81
4.2 lments de fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2.1 Principes du fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2.2 Phases du fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.2.3 Mthodes de fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.3 Mise en uvre du fuzzing sur les bus dentres-sorties . . . . . . . . . . . . . . . . 88
4.3.1 Architecture du fuzzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.3.2 Exprimentations et rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
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 A Preuve de concept dattaque par partage didentifiants PCI Express 99

A.1 Description de notre plate-forme exprimentale . . . . . . . . . . . . . . . . . . . 99
A.2 Injection des donnes dans une carte Ethernet . . . . . . . . . . . . . . . . . . . . 100
A.3 Application la corruption de cache ARP . . . . . . . . . . . . . . . . . . . . . . . 102
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
Annexe C Plusieurs exemples dexprimentations avec le contrleur IronHide 109

C.1 Description de la plate-forme dexprimentation . . . . . . . . . . . . . . . . . . . 109
C.2 Rsultats exprimentaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.2.1 coute sur les bus dentres-sorties . . . . . . . . . . . . . . . . . . . . . . . 110
C.2.2 Non-respect de la configuration matrielle . . . . . . . . . . . . . . . . . . 112
C.2.3 Usurpation didentit sur les bus dentres-sorties . . . . . . . . . . . . . . 113
C.2.4 Enregistreur de frappe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Bibliographie 117
vii
Table des matires
viii
Table des figures
1.1 Arbre de la sret de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Propagation des erreurs dans un systme de systmes . . . . . . . . . . . . . . . . 8
1.3 Classification des attaques sur les systmes informatiques . . . . . . . . . . . . . 13
1.4 Classification des techniques de vrification . . . . . . . . . . . . . . . . . . . . . . 24
2.1 Illustration de la terminologie des bus informatiques . . . . . . . . . . . . . . . . 31

2.2 Modle dinfrastructure matrielle pour un systme informatique . . . . . . . . . 32
2.3 Actions lmentaires dans un composant matriel . . . . . . . . . . . . . . . . . . 36
2.4 Attaques lmentaires dans un composant matriel . . . . . . . . . . . . . . . . . 37
2.5 Exemple de systme informatique . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.6 Graphe des actions lmentaires pour un systme informatique . . . . . . . . . . 42
2.7 Illustration de plusieurs exemples rels dattaques . . . . . . . . . . . . . . . . . . 43
3.1 Exemple darchitecture matrielle Intel-PC (chipset Q45) . . . . . . . . . . . . . . . 51

3.2 Espaces dadressage dfinis dans les architectures PC . . . . . . . . . . . . . . . . 52
3.3 Espace de configuration dun contrleur PCI . . . . . . . . . . . . . . . . . . . . . 55
3.4 Structure simplifie de la table ACPI DMAR . . . . . . . . . . . . . . . . . . . . . 64
3.5 Logique de parcours des tables de configuration pour Intel VT-d . . . . . . . . . . 64
4.1 Couches protocolaires PCI Express . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.2 Format dun TLP de type Memory Write Request (format 32 bits) . . . . . . . . . . 80
4.3 Architecture de notre contrleur dentres-sorties IronHide . . . . . . . . . . . . . 83
4.4 Architecture du fuzzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.5 Plate-forme exprimentale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.1 Plate-forme exprimentale considre . . . . . . . . . . . . . . . . . . . . . . . . . 100

A.2 Le tampon de rception dans la carte Ethernet VIA Rhine VT6102 . . . . . . . . . 101
B.1 Architecture simplifie dune carte graphique . . . . . . . . . . . . . . . . . . . . . 105

B.2 Scnario dattaque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
C.1 Plate-forme dexprimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

C.2 Dtection de notre contrleur par la machine cible . . . . . . . . . . . . . . . . . . 111
C.3 Quelques exemples de requtes reues par notre contrleur . . . . . . . . . . . . . 111
C.4 Dsactivation du bit Bus Master Enable (BME) sur un contrleur . . . . . . . . . . 112
C.5 Transaction MemoryWriteRequest avec un identifiant quelconque . . . . . . . 114
C.6 Exemple daccs frauduleux dtect par lI/O MMU . . . . . . . . . . . . . . . . . 115
C.7 Espace Port I/O vu de notre contrleur connect un chipset Intel x58 . . . . . . . 115
ix
Table des figures
x
Liste des tableaux
3.1 Access Control Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.2 Liste des chipsets expriments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.3 Rsultats exprimentaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1 Transactions PCI Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.2 Liste des chipsets expriments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.3 Quelques rsultats exprimentaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
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
sources matrielles et logicielles qui y sont associes.

Les attaquants font aujourdhui de plus en plus preuve dingniosit pour attaquer les sys-
tmes informatiques : les malveillances peuvent cibler les programmes qui sexcutent sur
le systme mais galement le systme dexploitation lui-mme et en particulier, son noyau.
Corrompre le noyau dun systme dexploitation est particulirement intressant du point de
vue dun attaquant car cela signifie corrompre potentiellement tous les programmes qui sex-
cutent au-dessus de ce noyau, voire prendre compltement le contrle du systme. cet ef-
fet, il dispose de divers vecteurs dattaque. La plupart des scnarios dattaque sappuient sur
des vecteurs dattaque lis au logiciel sexcutant sur le processeur principal : un attaquant
peut, par exemple, utiliser des fonctionnalits trop permissives du systme (le chargeur de
modules noyau, les priphriques virtuels, etc.) ou exploiter des erreurs dimplmentations lo-
gicielles (les dbordements de tampons ou dentiers, les chanes de format, etc.). Cette classe
dattaques est relativement bien connue ce jour, et de nombreux mcanismes (les piles non-
excutables, la distribution alatoire de lespace dadressage, la technique du canari, etc.) per-
mettent de sen protger. Depuis quelques annes, nous constatons que les scnarios dattaque
voluent et deviennent chaque jour plus complexes. En effet, certaines attaques ne reposent
plus exclusivement sur lutilisation de composants logiciels, et nous observons de plus en plus
dattaques impliquant des composants matriels, tels que le chipset, les contrleurs dentres-
sorties (un contrleur Ethernet, un contrleur de clavier, etc.) ou les priphriques (un iPod
avec une connectique FireWire, une souris USB, etc.). Celles-ci dtournent des fonctionnalits
lgitimes du matriel, tels que les mcanismes entres-sorties (accs direct la mmoire, inter-
ruption, etc.) diffrentes fins malveillantes (escalade de privilges, fuite dinformations, dni
de service, etc.).
Pour se protger de ces vecteurs dattaque multiples, nous constatons alors que les contre-
mesures, qui taient jusqu prsent presquexclusivement logicielles, ne suffisent plus et quune
bonne connaissance de la plate-forme matrielle devient de plus en plus importante pour une
meilleure matrise de la scurit dun systme informatique. Ainsi, il est aujourdhui essentiel
de connatre non seulement le fonctionnement des programmes, mais galement de veiller au
bon comportement de lintgralit de la chane de traitement, y compris des composants ma-
triels moins connus, tels que le chipset, les contrleurs dentres-sorties ou les priphriques.
Cette problmatique constitue le principal fil conducteur de nos travaux.
2 Prsentation de nos travaux

Les travaux dcrits dans ce manuscrit de thse se focalisent sur la scurit en vie opration-
nelle des systmes informatiques de type COTS vis--vis dattaques impliquant des compo-
sants matriels. Nous nous intressons plus particulirement aux attaques dites par entres-
sorties , lesquelles se distinguent des attaques usuelles par les vecteurs dattaque quelles em-
ploient : ces actions malveillantes dtournent les mcanismes dentres-sorties, cest--dire les
mcanismes de communication entre le processeur principal et les autres composants. Depuis
un certain nombre dannes, nous constatons que ces attaques atypiques suscitent un engoue-
ment croissant, dpassant mme pour certaines dentre elles le stade de preuve de concept.
Rcemment, lentreprise de solutions logicielles Qihoo 360 [QiHoo 360 11] a signal lappari-
tion dun maliciel reprenant les techniques dattaque prsentes dans la preuve de concept
IceLord [IceLord 07] publie quelques annes auparavant sur le Chinese Software Developer Net-
work (CSDN). Ce maliciel, initialement identifi comme tant le virus BMW 2 puis renomm
2
BMW est lacronyme de BIOS MBR Windows et ne dsigne en aucun cas la marque du constructeur automobile.
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
Actions malveillantes impactant la

scurit des systmes informatiques
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.
1.1 Scurit des systmes informatiques

Avant de prciser la notion de scurit des systmes informatiques, il convient de dfinir
au pralable ce que nous entendons par le terme systme. Nous prcisons ensuite la termino-
logie et les concepts fondamentaux lis la sret de fonctionnement dans laquelle sinscrit
plus particulirement la scurit des systmes. Finalement, nous rappelons la dfinition de la
scurit des systmes informatiques telle quelle a t initialement dcrite dans les Information
Technology Security Evaluation Criteria [ITSEC 91] puis, par la suite, reprise dans les Critres
Communs [Common Criteria 12], cest--dire la scurit comme la combinaison de trois pro-
prits : la confidentialit, lintgrit et la disponibilit de linformation.
5
Chapitre 1. Actions malveillantes impactant la scurit des systmes informatiques
1.1.1 Concepts et terminologie des systmes [Laprie 04]

Un systme est une entit qui interagit avec dautres entits, donc dautres systmes, y com-
pris le matriel, le logiciel, les humains et le monde physique avec ses phnomnes naturels.
Ces autres systmes constituent lenvironnement du systme considr. La frontire du systme
est la limite commune entre le systme et son environnement.
La fonction dun systme est ce quoi il est destin. Elle est dcrite par la spcification fonc-
tionnelle. Le comportement dun systme est ce que le systme fait pour accomplir sa fonction et
est dcrit par une squence dtats. Lensemble des tats de traitement, de communication, de
mmorisation, dinterconnexion et des conditions physiques constituent son tat total.
La structure dun systme est ce qui lui permet de gnrer son comportement. Dun point
de vue structurel, un systme est constitu dun ensemble de composants interconnects en
vue dinteragir. Un composant est un autre systme, etc. La dcomposition sarrte lorsquun
systme est considr comme tant un systme atomique : aucune dcomposition ultrieure
nest envisage ou nest envisageable, soit par nature, soit parce que dnue dintrt.
Le service dlivr par un systme, dans son rle de fournisseur, est son comportement tel que
peru par ses utilisateurs ; un utilisateur est un autre systme qui reoit un service du fournis-
seur. Un systme peut tre, squentiellement ou simultanment, fournisseur et utilisateur dun
autre systme, cest--dire dlivrer un service cet autre systme et en recevoir. La partie de
la frontire du systme o ont lieu les interactions avec ses utilisateurs est linterface de service.
La partie de ltat total du fournisseur qui est perceptible linterface de service est son tat
externe ; le reste est son tat interne.
Il est noter quun systme accomplit gnralement plusieurs fonctions et dlivre plusieurs
services. Les concepts de fonction et de service peuvent donc tre vus comme constitus de
fonctions lmentaires et de services lmentaires.
1.1.2 Sret de fonctionnement

La sret de fonctionnement fournit un cadre conceptuel intressant pour situer la scurit
par rapport dautres proprits des systmes informatiques. En effet, depuis de nombreuses
annes, les spcialistes de la sret de fonctionnement ont dvelopp une terminologie et des
mthodes dont lapplication la scurit peut tre enrichissante. Nous rappelons, dans cette
sous-section, les dfinitions et les concepts de base de la sret de fonctionnement directement
adapts de [Laprie et al. 96] et de [Laprie 04].
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.
1.1.2.1 Attributs de la sret de fonctionnement

Les attributs de la sret de fonctionnement sont dfinis par diverses proprits dont lim-
portance relative dpend de lapplication et de lenvironnement auxquels est destin le systme
informatique considr :
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
F IGURE 1.1 Arbre de la sret de fonctionnement
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).
1.1.2.2 Entraves la sret de fonctionnement

Un service correct est dlivr par un systme lorsquil accomplit sa fonction. Une dfaillance
du service, souvent simplement dnomme dfaillance, est un vnement qui survient lorsque
le service dvie de laccomplissement de la fonction du systme. Le service dlivr tant une
squence dtats externes, une dfaillance du service signifie quau moins un tat externe dvie
du service correct. La partie de ltat du systme qui dvie du fonctionnement correct, au-
trement dit qui est anormale ou incorrecte, est une erreur ; une faute est la cause adjuge ou
suppose dune erreur, et peut tre interne ou externe au systme.
La relation de causalit entre fautes, erreurs et dfaillances peut tre exprime comme suit.
Une faute active produit une erreur qui peut se propager dans un composant ou dun compo-
sant un autre, et est susceptible de provoquer une dfaillance. La dfaillance dun composant
cause une faute permanente ou temporaire interne pour le systme qui le contient, tandis que la
dfaillance dun systme cause une faute permanente ou temporaire externe pour les systmes
avec lesquels il interagit. Ce processus de propagation est illustr sur la figure 1.2.
Deux principales classes de fautes sont considrer ds lors que nous nous intressons aux
fautes malveillantes : les logiques malignes et les intrusions. Nous reprenons les dfinitions de
ces termes telles quelles ont t introduites dans le projet MAFTIA (Malicious- and Accidental-
Fault Tolerance for Internet Applications) [Adelsbach et al. 03]. Les logiques malignes sont des par-
ties du systme conues pour provoquer des dgts (les bombes logiques, les virus, etc.) ou
pour faciliter des intrusions futures au travers de vulnrabilits cres volontairement telles
que les portes drobes. Les logiques malignes peuvent tre introduites ds la cration du sys-
7
faute
^
erreurs
systme 1 systme 2 systme 3 utilisateur
dfaillance
F IGURE 1.2 Propagation des erreurs dans un systme de systmes
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.
1.1.2.3 Moyens pour la sret de fonctionnement
Le dveloppement dun systme sr de fonctionnement passe par lutilisation combine

dun ensemble de mthodes qui sont rparties en quatre classes de moyens :
la prvention de fautes : comment empcher, par construction, loccurrence ou lintroduc-
tion de fautes ; elle est principalement obtenue par des mthodes de spcification et de
dveloppement relevant de lingnierie des systmes ;
la tolrance aux fautes : comment fournir un service mme de remplir la fonction du
systme en dpit des fautes ; elle est mise en uvre par la dtection derreurs et le rta-
blissement du systme ;
llimination des fautes : comment rduire le nombre et la svrit des fautes ; elle peut tre
ralise pendant la phase de dveloppement dun systme par vrification, diagnostic
et correction, ou pendant sa phase oprationnelle par maintenance ;
la prvision des fautes : comment estimer la prsence, la cration et les consquences des
fautes ; elle est effectue par valuation du comportement du systme par rapport
loccurrence des fautes, leur activation et leurs consquences.
Ces moyens sont interdpendants et peuvent tre groups de diffrentes faons. Ainsi,
la prvention de fautes et llimination des fautes peuvent tre groupes dans lvitement des
fautes, cest--dire comment tendre vers un systme exempt de fautes, alors que la tolrance
aux fautes et la prvision des fautes peuvent tre groupes dans lacceptation des fautes, sa-
voir comment vivre avec un systme comportant des fautes. Un autre groupement consiste
associer la prvention de fautes et la tolrance aux fautes pour constituer la fourniture de la s-
ret de fonctionnement, et donc laptitude dlivrer un service de confiance ; llimination des
fautes et la prvision des fautes sont alors groupes en lanalyse de la sret de fonctionnement,
destine obtenir une confiance justifie dans le service, donc sassurer que les spcifications
fonctionnelles et de sret de fonctionnement sont adquates et que le systme les satisfait.
8
1.1. Scurit des systmes informatiques
1.1.3 Scurit des systmes informatiques [Deswarte 03]

Nous nous intressons prsent la scurit-immunit que nous appellerons simplement
scurit lorsquil ny aura pas dambigit avec la scurit-innocuit. Plutt que de dfinir la s-
curit des systmes informatiques vis--vis de leur seule capacit rsister des agressions ex-
ternes physiques (incendie, inondation, bombes, etc.) ou logiques (erreurs de saisie, intrusions,
piratages, logiques malicieuses, etc.), nous prfrons, linstar des Information Technology Secu-
rity Evaluation Criteria [ITSEC 91] et des Critres Communs [Common Criteria 12], considrer
la scurit comme la combinaison de trois proprits 4 : la confidentialit, lintgrit et la dispo-
nibilit. Il convient cependant de prciser que ces deux points de vue sont complmentaires. En
effet, la sret de fonctionnement considre la scurit comme lassociation des trois proprits
(confidentialit, intgrit et disponibilit) vis--vis des actions autorises (cest--dire des ser-
vices) alors que ces trois proprits se rapportent linformation dans le cadre des ITSEC. Le
terme dinformation doit tre pris ici dans son sens le plus large, couvrant non seulement les
donnes et les programmes, mais aussi les flots dinformation, les traitements et la connaissance
de lexistence de donnes, de programmes, de traitements et de communications. Cette notion
dinformation doit aller jusqu couvrir le systme informatique lui-mme dont parfois lexis-
tence doit tre tenue secrte (confidentialit). Pour tre plus prcis, nous distinguerons donnes
et mta-donnes : les donnes correspondent des informations identifies et accessibles un
certain niveau dabstraction, alors que les mta-donnes correspondent des informations in-
directes relies aux donnes ou aux services. Bien videmment, une mta-donne un certain
niveau dabstraction correspond une donne relle un niveau plus bas. titre dexemple,
les identifiants internes (uid, gid, etc.) sont considrs comme des donnes ou comme des mta-
donnes selon que lon se place au niveau du systme dexploitation (donnes) ou au niveau
dune application (mta-donnes).
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
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.
1.1.3.4 Autres facettes de la scurit
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
mission informatique dans un environnement donn. Un systme informatique peut alors d-

signer un simple ordinateur, ou encore un rseau dordinateurs. Il est galement possible de
modliser un rseau dordinateurs comme un systme de systmes informatiques. Les deux
visions concordent avec notre dfinition, seule la granularit de la modlisation change. Aussi,
pour plus de clart, nous allons retenir cette seconde vision pour la suite de ce manuscrit et
nous allons distinguer un ordinateur et un rseau dordinateurs.
1.2 Classification des attaques sur les systmes informatiques

Tout acte sur un systme dont lintention est de nuire au moins lune des proprits de
scurit (cf. sous-section 1.1.3) est qualifi de malveillant et constitue, de ce fait, une attaque sur
ce systme. Nous trouvons dans la littrature des manires diffrentes de classer les attaques 5 .
Certaines taxonomies les organisent en fonction dun unique critre. Parmi ces critres, les plus
rcurrents sont :
la cause de lattaque (utilisateur interne ou externe, intrus, etc.) [Anderson 80] ;
le mode ou le type de lattaque (virus, ver, coute passive, dguisement, etc.) [Parker 75,
Neumann et Parker 89] ;
le rsultat de lattaque (divulgation, perturbation, etc.) [Shirey 94, Brinkley et Schell 95] ;
la vulnrabilit exploite par lattaque ; plusieurs aspects peuvent alors tre considrs :
la phase de cration ou doccurrence de la vulnrabilit (lors de la conception, du dvelop-
pement, de lexploitation du systme, etc.), la nature de la vulnrabilit (concurrence,
dfaut de validation, etc.) [Abbott et al. 76, Bisbey et Hollingworth 78].
Dautres taxonomies considrent les attaques comme un processus et les classent en fonc-
tion de plusieurs critres qui constituent alors des axes ou des dimensions de classification. Les
critres retenus pour ces classifications dpendent de lobjectif poursuivi par les auteurs. Les
taxonomies publies dans [Landwehr et al. 94, Bishop 95, Aslam 95, Lindqvist et Jonsson 97,
Howard 97, Krsul 98]reposent ainsi sur ce principe. Cependant, aucune delles ne nous satisfait
pleinement pour nos travaux. Les classifications gnriques ont, certes, le mrite denglober la
majorit (voire la totalit) des attaques mais sont trop peu prcises sur la dfinition des caract-
ristiques des attaques. loppos, les classifications plus spcifiques les dcrivent de manire
trop prcise et ne couvrent potentiellement pas lensemble des attaques possibles, encore moins
celles qui restent encore inconnues.
Aussi, dans cette section, nous prsentons une classification des actions malveillantes im-
pactant la scurit des systmes informatiques laquelle nous avons abouti pour nos tra-
vaux. Celle-ci sinspire de la logique des taxonomies dattaques prcites et va nous servir,
entre autres, de fondation pour le modle dattaques que nous dtaillons dans le chapitre 2.
Il convient cependant de noter que cette classification ne constitue pas encore, du moins dans
son tat actuel, une taxonomie qui puisse tre une alternative celles que nous avons prcites.
Nous envisageons encore de la retravailler, de la raffiner sur certains aspects et de la valider en
la confrontant de nombreux exemples rels dattaques afin quelle puisse tre considre en
tant que telle.
Dans notre dmarche, nous avons considr une attaque comme une squence dactions,
dont lintention de certaines dentre elles les attaques lmentaires est de nuire au moins
lune des proprits de disponibilit, dintgrit ou de confidentialit du systme cible ou dun
systme ayant une quelconque relation avec lui (par exemple, un sur-systme qui le contient,
5
Lanalyse des diffrentes taxonomies dattaques ne fait pas lobjet de cette section et ne sera pas aborde dans ce
manuscrit. Aussi, le lecteur intress pourra consulter les analyses publies dans [Lough 01, Igure et Williams 08].
11
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.
1.2.1 Attaques agissant au niveau des systmes logiciels

Les systmes logiciels constituent un premier niveau dabstraction partir duquel un atta-
quant peut mettre en dfaut la scurit dun systme informatique. Dans ce contexte, le terme
systme logiciel doit tre pris dans son sens le plus gnral. Il dsigne tous types de logiciels
dans un systme informatique, couvrant aussi bien les programmes dapplication, le systme
dexploitation et son noyau, que les logiciels implants (en anglais, firmware) dans les compo-
sants matriels. Une attaque, ce niveau dabstraction, repose alors soit sur lutilisation dune
fonctionnalit logicielle lgitime du systme (ventuellement accessible grce une erreur dans
la configuration logicielle), soit sur lexploitation dune fonctionnalit logicielle vulnrable
des fins malveillantes. La prsente sous-section discute de ces deux vecteurs dattaque.
1.2.1.1 Abus dune fonctionnalit logicielle lgitime
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
Abus dune fonctionnalit

Configurations logicielle lgitime
Systmes
et fonctionnalits
logiciels Exploitation dune fonctionnalit
logicielles
logicielle vulnrable
Abus dune fonctionnalit

matrielle lgitime
Logique cable
Exploitation dune fonctionnalit
Systmes matrielle vulnrable
matriels Modification valide de la
configuration matrielle
A Configuration
T matrielle Modification invalide de la
T
configuration matrielle
A
Q
Destruction de messages
U
E Modification de messages
S Canaux de Messages
communication Captation de messages
Insertion de messages
Canaux de fuite Analyse des canaux de fuite

Environnement
Canaux
Injection de fautes
auxiliaires
Niveaux dabstrac-
Objet de lattaque Vecteurs dattaque
tion du systme
F IGURE 1.3 Classification des attaques sur les systmes informatiques
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
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
de modules dextension au sein du noyau de systme dexploitation. Cela limite fortement

(mais nempche cependant pas) lutilisation de ce vecteur dattaque.
1.2.1.2 Exploitation dune fonctionnalit logicielle vulnrable

La plupart des systmes logiciels contiennent des vulnrabilits, cest--dire des fautes de
conception ou de configuration. Un attaquant peut alors exploiter ces vulnrabilits comme
autant de vecteurs dattaque pour effectuer diffrentes actions malveillantes dans un systme
informatique. Cette partie dcrit quelques vulnrabilits courantes dans les systmes logiciels.
Le lecteur intress est invit se rfrer [Dowd et al. 06] pour une liste des vulnrabilits
logicielles courantes illustre par des exemples de programmes ayant t vulnrables.
Les dbordements de tampon font partie des vulnrabilits logicielles les plus rpandues
et reprsentent prs de 60% des annonces de scurit des Computer Emergency Response Team
(CERT) ces dernires annes. Un dbordement de tampon (en anglais, buffer-overflow) est une
vulnrabilit dans laquelle les donnes copies dans une zone de mmoire excdent la taille
alloue pour stocker ces donnes, crasant, par l-mme, les zones de mmoire contigus qui
peuvent contenir des donnes critiques. Ces dbordements peuvent avoir lieu deux emplace-
ments de la mmoire : la pile ou le tas. Nous parlons alors plus spcifiquement de dbordement
dans la pile (en anglais, stack-overflow) ou de dbordement dans le tas (en anglais, heap-overflow).
Lexploitation dune telle vulnrabilit implique ncessairement une modification de ltat du
systme logiciel : le dbordement crase alors soit des variables auxiliaires (variables locales,
arguments de fonction, etc.), soit des variables de ltat dexcution (adresse de retour dune
fonction, le pointeur de pile, etc.). Sur les systmes informatiques respectant larchitecture de
von Neumann 10 [von Neumann 45], dans laquelle les instructions et les donnes requises ou
gnres par le traitement sont stockes dans une mme mmoire, un dbordement de tampon
peut conduire la modification de la structure dun programme en cours dexcution. cet
effet, lattaquant injecte dans la mmoire du processus un shellcode, autrement dit une chane
de caractres malveillante contenant un code arbitraire quil souhaite excuter, puis sarrange
(par exemple, en modifiant ladresse de retour dune fonction) pour dtourner le chemin dex-
cution du programme vers ce shellcode [Aleph One 96]. Le ver Inet Worm cre par Robert T.
Morris Jr. [Eichin et Rochlis 89, Spafford 88] en novembre 1988 exploitait dj ce vecteur dat-
taque. Le ver envoyait aux dmons fingerd une requte de 536 octets alors que seuls 512 oc-
tets taient allous dans la pile pour contenir cette requte. Le shellcode, inject en mmoire par
le dbordement dans la pile, lui a ensuite permis dobtenir une invite de commande (en anglais,
shell) distance.
Les dbordements dentiers forment une autre catgorie de vulnrabilits logicielles que
nous retrouvons couramment dans les systmes logiciels. Il sagit dune vulnrabilit qui sur-
vient lorsquun nombre stocker en mmoire excde, par exemple, la plage de valeurs que le
systme informatique peut reprsenter. Cette vulnrabilit provient souvent soit dun transty-
page (par exemple, le systme logiciel stocke un rsultat dans une variable de trop petite taille),
soit dun calcul arithmtique (par exemple, la somme dentiers positifs peut donner un nombre
ngatif en raison de la reprsentation des nombres en mmoire). Une telle vulnrabilit a t
constate par le pass sur le systme logiciel de la fuse Ariane 5G V88/501, premire de la
srie des fuses Ariane 5, qui embarquait la majorit du code produit pour la fuse Ariane 4.
cause de paramtres de vol diffrents, le code alors correct pour la fuse Ariane 4 ne ltait
plus pour la fuse Ariane 5 et la conversion dun rel sur 64 bits vers un entier sign sur 16
10
Par opposition larchitecture Harvard, dans laquelle les instructions et les donnes utilises et gnres par le
traitement sont stockes dans des mmoires diffrentes qui sont connectes deux bus distincts.
15
bits a provoqu une exception matrielle correspondant un dbordement arithmtique car

le rel sur 64 bits contenait alors une valeur trop grande pour pouvoir tre stocke dans un
entier sign sur 16 bits. Or, pour des raisons de performance, la routine de traitement de cette
exception avait justement t dsactive. Cette dfaillance a provoqu, par la suite, une cas-
cade de problmes jusqu causer la dfaillance des deux systmes primaire et secondaire
de guidage inertiel de la fuse qui sest auto-dtruite le 4 juin 1996, peine 37 secondes aprs
son lancement. Dans la plupart des cas, les dbordements dentiers ne sont pas exploitables.
Cependant, ils peuvent mener dautres classes de vulnrabilits comme des dbordements
de tampons, par exemple, lorsque lentier o se situe la vulnrabilit est utilis pour allouer
dynamiquement de la mmoire. Comme nous lavons dcrit prcdemment, ces autres classes
de vulnrabilits peuvent porter atteinte la confidentialit, lintgrit et la disponibilit
des donnes et du service.
Les chanes de format constituent une autre classe de vulnrabilits associe lutilisa-
tion inapproprie des familles de fonctions auxquelles appartiennent printf(), err() et
syslog(). Le flux de caractres produit par ces familles de fonctions est construit par-
tir dune chane de format. Celle-ci peut contenir des caractres ordinaires et des caractres
spciaux (appels des spcificateurs de format) qui indiquent la fonction comment ma-
nipuler les arguments qui lui sont passs en paramtres. Des problmes de scurit peuvent
alors survenir lorsque lattaquant contrle cette chane de format. En faisant en sorte que les
spcificateurs de format ne correspondent pas aux arguments fournis la fonction, latta-
quant va le plus souvent provoquer une dfaillance du systme logiciel conduisant un dni
de service. Cependant, en construisant astucieusement la chane de format, il peut afficher
le contenu de la pile, voire faire excuter au systme logiciel des portions du code exis-
tant [Solar Designer 97, Nergal 01, Krahmer 05, Shacham 07].
1.2.2 Attaques agissant au niveau des systmes matriels

Les systmes matriels constituent un second niveau dabstraction partir duquel il est
possible de nuire la scurit dun systme informatique. Bien quil soit plus simple pour un
attaquant de cibler directement les systmes logiciels, nous observons quactuellement de plus
en plus dattaques sappuient sur les systmes matriels pour impacter indirectement le sys-
tme logiciel. Nous discernons deux raisons principales cela. La premire est que le fonction-
nement des systmes logiciels repose sur les systmes matriels. Ainsi, corrompre un systme
matriel signifie potentiellement corrompre tous les systmes logiciels qui en dpendent pour
leur excution. Le fait que les systmes matriels sont souvent soumis des restrictions moins
drastiques que les systmes logiciels constitue une seconde raison. En effet, au niveau du mat-
riel, il nexiste plus de notion de privilges, disolation de processus, etc. Une attaque au niveau
des systmes matriels agit alors soit sur les fonctionnalits matrielles qui ont t implmen-
tes en logique cble, soit sur leur configuration matrielle. Une telle attaque peut tre mise
en uvre de diffrentes faons, prsentes dans les trois sous-sections suivantes.
1.2.2.1 Abus dune fonctionnalit matrielle lgitime

Les systmes matriels, tant les supports dexcution des systmes logiciels, ont automati-
quement accs aux ressources utilises par ces derniers. linstar du mcanisme daccs direct
la mmoire dans les contrleurs dentres-sorties 11 , il est possible de dtourner les fonction-
nalits matrielles qui accdent ces ressources dans le but de perptrer des attaques contre
11
Les attaques qui exploitent le mcanisme daccs direct la mmoire seront discutes en dtail dans le chapitre 3.
16
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.
1.2.2.2 Exploitation dune fonctionnalit matrielle vulnrable
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.
1.2.2.3 Modification de la configuration matrielle
Le fonctionnement dun systme matriel repose en partie sur sa configuration matrielle.

Un attaquant peut chercher altrer la configuration dun systme matriel de faon reconfi-
gurer ou dsactiver certaines fonctionnalits matrielles. Par exemple, la plupart des systmes
dexploitation actuels configurent les zones de la mmoire centrale correspondant des don-
17
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.
1.2.3 Attaques agissant au niveau des canaux de communication

Les canaux de communication constituent un autre niveau dabstraction partir duquel un
attaquant peut mettre en dfaut la scurit dun systme informatique. La notion de canal de
communication dsigne ici tout type de mdium de transmission dinformation dont le rle est
dacheminer des messages entre des systmes qui interagissent, et couvre aussi bien les canaux
de communication physiques que les canaux de communication logiques (par exemple, les m-
moires partages, les fichiers partags, etc.). Une attaque, ce niveau dabstraction, repose alors
sur des vecteurs dattaque lis aux messages changs entre les systmes logiciels ou matriels
qui interagissent. Nous distinguons alors quatre vecteurs dattaque possibles qui ncessitent
pour lattaquant un accs au canal de transmission : la destruction, la modification, la captation
et linsertion de messages, ces messages pouvant tre soit cohrents, soit incohrents par rap-
port au protocole de communication. La suite de cette sous-section prsente de faon succincte
ces vecteurs dattaque.
1.2.3.1 Destruction de messages
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.
1.2.3.2 Modification 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
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.
1.2.3.3 Captation de messages
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.
1.2.3.4 Insertion de messages
Ce vecteur dattaque consiste insrer des messages dans un canal de communication. La

mise en uvre dun tel vecteur dattaque ncessite alors un accs au canal de communication
en mission. Un attaquant peut, en particulier, rejouer des squences de messages quil aura
captes prcdemment, par exemple pour se faire passer pour un autre utilisateur (rptition
dune squence dauthentification) ou pour faire excuter plusieurs fois une mme action (r-
ptition dun transfert lectronique de fonds), etc. Lorsque linsertion consiste mettre des
messages, valides ou invalides, en trs grand nombre, il sagit plutt dune attaque contre la
disponibilit qui peut aller jusquau dni de service. Nous parlons alors dinondation (en an-
glais, flooding). Un cas particulier dinondation est lblouissement, qui consiste saturer les
canaux de communication par des messages incohrents de faon mettre temporairement
hors ligne un ou plusieurs systmes (par exemple, des systmes de dtection dintrusions) de
19
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.
1.2.4 Attaques agissant au niveau des canaux auxiliaires

Lenvironnement dun systme informatique constitue un dernier niveau dabstraction
partir duquel un attaquant peut porter atteinte la scurit de ce systme. En particulier, un
attaquant peut agir au niveau des canaux auxiliaires, cest--dire les canaux autres que ceux g-
nralement utiliss pour la transmission dinformation. Une attaque, ce niveau dabstraction,
peut alors consister analyser les canaux de fuite ou injecter des fautes dans le systme infor-
matique via les canaux auxiliaires. La suite de cette sous-section explore ces vecteurs dattaque.
Toutefois, notre intention nest pas de faire un examen exhaustif des techniques existantes, mais
plutt de mettre en vidence la philosophie qui sous-tend les principales attaques. Aussi, seuls
les canaux auxiliaires les plus usits seront voqus ici.
1.2.4.1 Analyse des canaux de fuite

Ce vecteur dattaque repose sur lexistence dune corrlation entre des mesures physiques
(consommation dnergie, temps de calcul, rayonnement lectromagntique, etc.) et les traite-
ments effectus par un systme. Cette corrlation est parfois utilise afin dextraire des infor-
mations du systme analys et constitue, par consquent, un canal de fuite. Les attaques sur ces
canaux de fuite se droulent gnralement en deux temps. Dans une premire phase dite din-
teraction, lattaquant mesure une ou plusieurs caractristiques physiques du systme quil sou-
haite attaquer. Au cours dune seconde phase, appele phase dexploitation, lattaquant analyse
ces observations afin dinfrer linformation recherche. Dans le cas de terminaux cryptogra-
phiques, cette information peut tre, par exemple, une cl secrte. Plusieurs caractristiques
physiques peuvent tre exploites pour perptrer ce type dattaques.
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
Attaque par analyse de la consommation lectrique. La consommation lectrique dun sys-

tme lectronique varie en fonction des traitements quil effectue. Dans le cas dun processeur,
par exemple, celle-ci est corrle linstruction excute (voire aux instructions suivantes dans
le cas dun processeur avec pipeline), ses oprandes (registres, adresses, valeurs, etc.) et aux
valeurs des cellules mmoire et des bus. Un attaquant peut alors dterminer prcisment les
oprations effectues en analysant cette grandeur physique. Nous parlons alors dattaques par
analyse de la consommation lectrique (en anglais, power attack). Celles-ci se divisent en deux
catgories : Simple Power Attack (SPA) et Differential Power Attack (DPA) [Kocher et al. 99]. La dif-
frence entre ces techniques rside dans le fait que les SPA reposent sur une simple analyse de
consommation lectrique alors que les DPA ncessitent de soumettre plusieurs excutions simi-
laires (par exemple, en changeant un bit dans le message chiffrer) et analyser les diffrences
entres les traces de consommation.
Attaque par analyse du rayonnement lectromagntique. Dans un circuit lectronique, le

dplacement de charges lectriques produit un champ lectromagntique. Par l-mme, les va-
riations du courant lectrique dans un systme lectronique saccompagnent dune variation
de son champ lectromagntique. Les deux grandeurs physiques tant troitement lies, les
techniques danalyse que nous avons dtailles prcdemment pour la consommation lec-
trique peuvent tre appliques indiffremment au rayonnement lectromagntique. Dans la
littrature, ce type de rayonnement est parfois appel effet van Eck , du nom dun chercheur
des PTT nerlandais qui a montr quavec un matriel de faible cot, il tait possible dafficher
sur un cran de tlvision le contenu de lcran dun terminal distant de plusieurs centaines
de mtres [van Eck 85]. Une attaque similaire sur des claviers dordinateur a t rcemment
prsente par [Vuagnoux et Pasini 09]. En mesurant les ondes lectromagntiques mises par
les claviers, ils ont russi retrouver chaque touche saisie jusqu une distance de 20 mtres.
Chaque touche du clavier avait, en effet, une signature lectromagntique caractristique.
Attaque par analyse acoustique. Les composants mcaniques et lectroniques mettent un

bruit dont la frquence et lintensit varient en fonction des oprations quils effectuent 12 . Il
est alors possible de reconstituer fidlement le traitement effectu partir des bruits mesurs.
Peter Wright, alors scientifique pour lUK Government Communications Headquarters (GCHQ) en
1965, raconte dans son autobiographie [Wright 87] que le MI5, service de renseignements bri-
tannique, tenta de casser le chiffrement utilis par lambassade gyptienne Londres durant
la crise du canal de Suez. Limits par les capacits de leurs calculateurs, P. Wright suggra de
placer un microphone prs des dispositifs (mcaniques) de chiffrement utiliss par les gyp-
tiens dans le but de capter le bruit produit. Avec le concours des services postaux britanniques,
qui taient lpoque en charge des lignes tlphoniques, ils ont dlibrment provoqu des
dysfonctionnements dans les quipements tlphoniques de lambassade gyptienne. Ils ont
ensuite envoy des agents du MI5 dans lambassade, dguiss en agents de maintenance de la
compagnie tlphonique, qui ont russi poser les microphones grce ce subterfuge. Lop-
ration, du nom de code ENGULF, sest ensuite couronne de succs car en coutant les clics
produits par les dispositifs de chiffrement, ils ont pu dduire la position de 2 ou 3 de ses rotors.
Cette information supplmentaire a rduit leffort de cryptanalyse, et le MI5 a pu espionner, par
ce biais, les communications de lambassade gyptienne Londres pendant plusieurs annes.
12
Dans les composants lectroniques, ce bruit est d en particulier aux condensateurs qui mettent un claquement
lorsquils se chargent ou se dchargent.
21
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.
1.2.4.2 Injection de fautes par les canaux auxiliaires.
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].
Modification de la frquence dhorloge. De la mme faon que pour la tension lectrique,

les circuits lectroniques fonctionnent correctement uniquement dans une plage de frquences
dhorloge dfinie par son constructeur. Lutilisation temporaire dune frquence anormalement
leve ou basse peut entraner des erreurs dans le traitement effectu. Nous parlons alors dat-
taques par drive de la frquence dhorloge (en anglais, frequency glitch). Dans le cas dun pro-
cesseur, linjection dune anomalie dans sa frquence dhorloge de rfrence peut lamener
omettre plusieurs instructions et compltement changer son comportement. Comme la com-
prhension de ce phnomne physique ne fait pas lobjet de cette partie, le lecteur intress
est invit consulter [Anderson et Kuhn 98] pour plus de dtails. Il est intressant de noter
que cette technique, relativement simple dans son principe, a permis de contourner les mca-
nismes de scurit dau moins deux consoles de jeux vidos rputes pour tre difficilement
13
Ce type de fautes accidentelles est de plus en plus frquent, en particulier dans les systmes aronautiques et
spatiaux : avec la rduction de taille des circuits intgrs, est aussi rduite lnergie ncessaire pour perturber leur
fonctionnement. Nous parlons gnralement de Single Event Upset (SEU).
22
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.
Modification de la temprature. Les constructeurs de composants lectroniques dfinissent

galement les tempratures extrmes (minimales et maximales) jusquauxquelles les compo-
sants fonctionnent correctement. En faisant fonctionner un composant en dehors de cette plage
de temprature nominale, il est possible de perturber son fonctionnement. Sur les cartes puce
(en anglais, smart-cards), il est possible dobserver deux effets lorsque ce vecteur dattaque est
utilis : la modification alatoire des mmoires RAM dues lchauffement des composants et
une incohrence entre ce qui est crit et ce qui est lu de la mmoire. Ce dernier phnomne
est d en particulier au fait que les tempratures extrmes de fonctionnement des mmoires
diffrent pour les oprations de lecture et dcriture.
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
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.
1.3 Mthodes et techniques pour llimination des fautes

Comme prcdemment indiqu (cf. sous-section 1.1.2), la conception et la ralisation dun
systme informatique sr de fonctionnement passent par lutilisation combine dun ensemble
de mthodes qui sont classes en quatre moyens : la prvention, llimination, la tolrance et
la prvision des fautes. La prsente section sintresse plus particulirement llimination des
fautes, qui vise rduire le nombre et la svrit des fautes. Elle est ralise pendant la phase
de dveloppement dun systme par vrification, diagnostic et correction, ou pendant sa phase
oprationnelle par maintenance [Laprie et al. 96].
La vrification consiste dterminer si le systme satisfait des proprits, appeles condi-
tions de vrification [Cheheyl et al. 81] ; si ce nest pas le cas, deux autres tapes doivent tre
entreprises : diagnostiquer la ou les fautes qui ont empch les conditions de vrification dtre
remplies, puis apporter les corrections ncessaires. Aprs correction, le processus doit tre re-
commenc afin de sassurer que llimination des fautes na pas eu de consquences indsi-
rables.
Les fautes prsentes dans un systme peuvent tre rvles par diffrentes techniques qui
sont classes selon quelles impliquent ou non lactivation du systme (cf. figure 1.4). La vrifica-
tion dun systme sans activation relle est dite statique, par opposition la vrification dynamique
qui ncessite son activation. Les sous-sections suivantes dtaillent ces diffrentes techniques.
Analyse statique
Statique Preuve mathmatique
Analyse de comportement
Vrification
Excution symbolique
Dynamique
Test
F IGURE 1.4 Classification des techniques de vrification
1.3.1 Analyse statique

Lanalyse statique peut tre manuelle, ou automatique. Lanalyse statique manuelle corres-
pond aux techniques de revue ou dinspection prvues tout au long du cycle de dvelop-
pement du systme [Fagan 76, Dyer 92, van Emden 92, Ebenau et Strauss 94, Myers et al. 04].
Une quipe de personnes se runit pour analyser en dtail les documents (par exemple, spci-
fication, ou dossier de conception gnrale ou dtaille, ou code-source) relatifs la phase en
cours. Lexamen de ces documents est guid par des listes de contrle (en anglais, check-list)
(contenant des questions se poser, des standards respecter, etc.) et donne lieu des ques-
tions ou remarques qui sont discutes avec les auteurs du document. Lanalyse statique automa-
tique regroupe tous les contrles effectus laide doutils informatiques des compilateurs
aux analyseurs les plus volus. Ces outils fournissent des caractristiques du code (mesures
de complexit, rfrences croises, chemins dexcution, etc.) qui facilitent le travail danalyse
24
1.3. Mthodes et techniques pour llimination des fautes
statique manuelle et signalent certaines anomalies structurelles (variables non-initialises, in-

terfaces incompatibles entre composants, utilisations incohrentes de variables globales, code
mort, etc.). cet effet, les algorithmes mis en uvre dans ces outils peuvent se baser sur des
heuristiques simples ou sur des modles ou thories plus complexes tels que les graphes de
contrle ou linterprtation abstraite [Cousot et Cousot 77, Cousot 01].
1.3.2 Preuve mathmatique

Une preuve mathmatique est une suite finie dinfrences dans un systme formel, cest--dire
dans un formalisme ayant une syntaxe et une smantique sappuyant sur des fondements ma-
thmatiques associs des rgles de manipulation permettant deffectuer des transformations
et des vrifications. La preuve du programme dont est issu un systme logiciel ou matriel par
rapport sa spcification ncessite une formalisation du problme de vrification : la descrip-
tion du systme, les hypothses formules sur son environnement et les proprits attendues
doivent tre exprimes dans un langage formel qui sappuie sur un cadre logique bien dfini.
La plupart des mthodes qui concernent les programmes squentiels ont recours une ap-
proche base sur la smantique axiomatique. Cette smantique, dont les fondements remontent
[Floyd 67, Hoare 69, Dijkstra 76], consiste dfinir une logique mathmatique permettant de
prouver des proprits sur des programmes crits dans un langage de programmation donn.
Les logiques mathmatiques utilises peuvent tre bases sur :
la logique des prdicats, reprsentes par les mthodes Larch [Guttag et Horning 93] ou
EHDM (Enhanced Hierarchical Development Methodology) [Rushby et al. 91]) ;
la thorie des ensembles, reprsentes pincipalement par la mthode VDM (Vienna Develop-
ment Method) [Bjrner et Jones 78, Jones 90], puis la mthode Z [Spivey 88a, Spivey 92b]
et la mthode B [Abrial et al. 91], qui occupent une place de choix de par le fait quelles
sont actuellement trs utilises par lindustrie informatique ;
Il convient de noter que la preuve mathmatique dun systme requiert un investissement
important, et nest souvent applicable qu des systmes de taille restreinte. Elle permet nan-
moins de garantir le respect de certaines proprits cruciales pour la scurit, exprimes par
exemple sous forme dinvariants [Glory et Bergerand 90],sous rserve que la preuve soit elle-
mme correcte et que le systme formel construit soit cohrent.
1.3.3 Analyse de comportement

Lanalyse de comportement est base sur des modles comportementaux du systme, dduits
de la spcification, ou des dossiers de conception, ou des codes-sources [Diaz 82, Davis 88,
Harel et al. 90].Cette analyse met en jeu des simulations de son comportement, modlises
partir de graphes, dautomates tats finis, de tables de dcision, de rseaux de Petri, etc. Il est
possible de vrifier des proprits de cohrence, compltude, vivacit, temps de rponse, etc.
ds lors quune smantique formelle est associe au modle utilis. La vrification de modles
(en anglais, model checking), propose par [Clarke et Emerson 08, Queille et Sifakis 82], consti-
tue un cas particulier des techniques danalyse de comportement. Il sagit dun ensemble de
techniques de vrification automatique de proprits temporelles sur des systmes ractifs (par
exemple, protocoles de communication, composants lectroniques, etc.), cest--dire un sys-
tme qui est en interaction permanente avec son environnement et dont le rythme est impos
par cet environnement. Elle ncessite de formuler les spcifications dans une logique tempo-
relle propositionnelle et de modliser le systme sous la forme dun graphe orient, constitu
dtats et de transitions. Loutil de model checking (ou model checker) parcourt ensuite de faon
25
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.4 Excution symbolique

Lexcution symbolique de programme consiste excuter un programme en lui soumet-
tant des valeurs symboliques en entre : par exemple, si une entre X est un nombre entier
positif, nous pouvons lui affecter une valeur symbolique a qui reprsente lensemble des va-
leurs entires suprieures 100. Une excution symbolique consiste alors propager les sym-
boles sous forme de formules au fur et mesure de lexcution des instructions. Elle fournit
comme rsultats les expressions symboliques obtenues pour les sorties. En pratique, les limites
auxquelles se heurte cette technique sont nombreuses : dans lexemple prcdent, comment
connatre le rsultat dune condition de branchement portant sur une valeur prcise de X (par
exemple, X = 200), rsultat qui conditionne la suite des instructions excuter ? Que repr-
sente llment dindice X dans un tableau lorsque X a la valeur a ? Comment matriser lex-
plosion de la taille et de la complexit des formules obtenues ?
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
28
Chapitre 2
laboration dun modle dattaques
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.
2.1 Infrastructure matrielle dun systme informatique

Nous avons prcdemment dfini un systme informatique comme la composition de deux
systmes complexes, lun matriel et lautre logiciel, organiss dans le but de remplir une fonc-
tion ou une mission informatique dans un environnement donn (cf. section 1.2). Dans la pr-
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.
2.1.1 Architectures de communication

Dans une infrastructure matrielle, les composants matriels peuvent endosser plusieurs
rles sur les bus informatiques. Ceux qui initient et contrlent les transferts de donnes sont
appels composants matres. Ils se connectent aux bus informatiques au travers de ports matres.
Typiquement, les processeurs se comportent en matres car ils initient des oprations de lec-
ture et dcriture vers dautres composants matriels du systme informatique (par exemple,
la mmoire centrale, les contrleurs, etc.). Les composants esclaves rpondent simplement aux
demandes de transfert de donnes des composants matres sans pouvoir en initier eux-mmes.
Ceux-ci sont relis aux bus informatiques par des ports esclaves. La plupart des priphriques
sont des composants esclaves. Ils rpondent aux oprations de lecture et dcriture dautres
composants matres tels que les processeurs. Il convient de remarquer que certains composants
peuvent aussi jouer les deux rles de matre et desclave. Cest le cas, en particulier, des contr-
leurs de mmoire, des contrleurs de priphriques et, plus gnralement, des ponts. Nous
rappelons quun pont est un composant matriel qui permet dinterconnecter deux bus qui
nimplmentent pas ncessairement les mmes protocoles et, ventuellement, ne fonctionnent
pas aux mmes frquences dhorloge. ce titre, il endosse alternativement le rle de composant
matre (pour mettre) et de composant esclave (pour recevoir) sur les bus quil interconnecte.
Chaque composant esclave se voit gnralement attribuer une plage dadresses. Lorsquun
composant matre effectue un transfert de donnes, il diffuse sur les bus ladresse de destination
et les donnes transfrer. Le dcodeur se charge alors dinterprter cette adresse et de slection-
ner le composant esclave destin recevoir ces donnes. Cette opration de dcodage dadresse
peut tre mise en uvre de faon centralise ou de faon distribue. Dans le cas dune mise en
uvre centralise, le dcodeur prend en entre ladresse du transfert de donnes et met en-
suite un signal pour activer le composant esclave auquel est destin ce transfert. loppos,
tous les esclaves ont leurs propres dcodeurs dans le cas dune mise en uvre distribue. Lors
dun transfert de donnes, les dcodeurs associs chaque esclave dcodent individuellement
ladresse transmise sur les bus afin de dterminer si le transfert leur est destin.
Lorsque plusieurs composants matres sont connects un mme bus, il est possible quils
initient simultanment un transfert de donnes. tant donn que seul un transfert de donnes
peut avoir lieu sur les bus un instant donn, un arbitre est ncessaire pour dsigner le com-
posant matre prioritaire pour procder un transfert de donnes. Les critres retenus pour
dterminer le composant matre qui a accs au bus forment le schma darbitrage. De la mme
faon que pour un dcodeur, un arbitre peut tre mis en uvre de faon centralise ou de fa-
on distribue. La figure 2.1 illustre ces notions de composant matre et de composant esclave,
darbitre et de dcodeur que nous venons daborder.
Les bus informatiques peuvent tre organiss de diffrentes manires au sein dun systme
informatique. Le choix dune organisation par rapport une autre dpend gnralement de
30
2.1. Infrastructure matrielle dun systme informatique
Mmoire Mmoire
Processeur
interne interne
Dcodeur Arbitre
Port matre Port esclave Port esclave
Port esclave Port esclave Port esclave
Contrleur Contrleur Contrleur Contrleur

Pont
de mmoire de priphriques d'entres-sorties d'entres-sorties
Port matre Port matre Port matre Port esclave Port matre & esclave
Port esclave Port esclave
Mmoire
Priphrique
externe
F IGURE 2.1 Illustration de la terminologie des bus informatiques
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.
2.1.2 Composants matriels
Conceptuellement, linfrastructure matrielle du systme informatique peut tre dcrite par

un modle similaire celui reprsent sur la figure 2.2. Les processeurs, le rpartiteur, le contr-
leur de mmoire et ses mmoires, les contrleurs dentres-sorties, les priphriques, le contr-
leur dinterruptions, et le gestionnaire de la plate-forme sont interconnects au travers dune
architecture de communication. Dans ce modle, certains composants matriels sont indispen-
sables au fonctionnement du systme informatique et dautres sont optionnels. La prsente
sous-section dcrit succinctement les principales fonctions de ces composants.
31
lements obligatoires Composant esclave

Processeur Processeur
lements optionnels Composant matre
Frontire du systme Composant matre et esclave
Rpartiteur d'entres-sorties Rpartiteur d'entres-sorties Rpartiteur d'entres-sorties
Contrleur Contrleur Gestionnaire Contrleur Contrleur Contrleur de

d'interruptions de priphriques de la plate-forme interne de rseaux mmoire
Mmoires
Intrieur
Extrieur
Contrleur Contrleur
Priphriques
de priphriques externe
Contrleur
Priphriques Priphriques
de priphriques
F IGURE 2.2 Modle dinfrastructure matrielle pour un systme informatique
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.
2.1.2.3 Contrleur de mmoire et mmoires associes

La mmoire centrale stocke toutes les instructions et les donnes des programmes qui sont
excuts par le processeur. Elle rsulte de lassociation, dune part, du contrleur de mmoire
et, dautre part, des circuits lectroniques qui forment la mmoire et sur lesquels sont physi-
quement stockes les donnes. Le contrleur de mmoire agit comme un pont entre les bus
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.
2.1.2.4 Contrleurs dentres-sorties
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
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.1.2.6 Contrleur dinterruptions
Le contrleur dinterruptions se charge de mettre en attente les demandes dinterruptions

provenant des diffrents contrleurs dentres-sorties et de les notifier aux processeurs qui vont
immdiatement excuter une routine dinterruption pour les traiter. Pour traiter les demandes
dinterruptions qui ont lieu simultanment, il est possible de programmer le contrleur din-
terruptions pour affecter des priorits diffrentes chaque contrleur dentres-sorties. Lin-
terruption de priorit suprieure est alors traite la premire pendant que linterruption de
priorit plus faible est mise en attente. Du point de vue de larchitecture de communication,
le contrleur dinterruptions agit comme un pont qui interconnecte dune part les lignes din-
terruptions qui transportent les demandes dinterruptions des contrleurs dentres-sorties et
dautre part la ligne dinterruption qui notifie le processeur de ces demandes. Aujourdhui, ces
lignes dinterruptions sont intgres aux bus locaux et aux bus systmes.
2.1.2.7 Gestionnaire de la plate-forme
Le gestionnaire de la plate-forme regroupe un ensemble de composants matriels en charge

de la configuration et la maintenance de la plate-forme matrielle. Sur les systmes informa-
tiques compatibles PC, les mmoires qui stockent le Basic Input/Output System (BIOS) et lUnified
Extensible Firmware Interface (UEFI) sont des exemples de tels composants matriels. Dautres
technologies matrielles plus spcifiques aux plates-formes telle quIntel Active Management
Technology (AMT) 14 dans les chipsets Intel rcents sont galement considres comme faisant
partie du gestionnaire de la plate-forme. Il interagit avec les autres composants matriels du
systme informatique au travers du bus local sur lequel il agit soit en composant matre soit en
composant esclave en fonction des composants matriels qui y sont intgrs.
Avec la conjonction de lvolution des technologies de fabrication des circuits intgrs et de

la nature du march des systmes lectroniques, il est aujourdhui possible dintgrer ces com-
posants matriels sur un ou plusieurs circuits intgrs relativement petits. Nous parlons alors
spcifiquement de systmes sur puce (en anglais, system on-chip). Dans cette sous-section, nous
avons prsent les caractristiques fonctionnelles de chacun de ces composants matriels indif-
fremment de leur degr dintgration. Ce travail de caractrisation est lorigine du modle
dattaques que nous dcrivons dans la prochaine section (2.2).
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.
2.2.1 Modle des actions lmentaires et des attaques lmentaires

Le modle que nous souhaitons tablir cherche couvrir de manire aussi complte que
possible les attaques dans un systme informatique et doit satisfaire, cet effet, plusieurs ca-
35
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
Sous-systme du composant matriel

Configuration Logique
Action lmentaire
Communication
F IGURE 2.3 Actions lmentaires dans un composant matriel
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
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
F IGURE 2.4 Attaques lmentaires dans un composant matriel
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.
2.2.2 Squences dactions et dattaques lmentaires

Il est possible de dterminer lensemble des attaques pour un systme informatique par
un parcours exhaustif des chemins du graphe des actions lmentaires. Bien que fastidieux et
sujet de nombreuses erreurs, ce traitement peut tre opr de faon manuelle. Il peut ga-
lement tre assist par des outils automatiques implmentant des algorithmes de parcours de
graphes [Cormen et al. 09]. Nous donnons, dans la suite, quelques lments dimplmentations
dun tel outil qui contribueraient acclrer considrablement ses calculs.
En raison de la caractrisation (parfois trop) fine des actions lmentaires, il peut apparatre
au sein du graphe certaines actions lmentaires qui ne contribuent pas directement au proces-
sus dattaque et qui sont par l-mme superflues. Nous pouvons alors envisager de rduire la
37
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.
2.2.3 Application un modle de systme informatique

La prsente sous-section illustre la mise en uvre de notre modle dattaques en linstan-
ciant un systme informatique particulier reprsent sur la figure 2.5. Il sagit dune instance
(trs) simplifie du modle gnrique de systme informatique que nous avons prcdemment
dcrit en section 2.1 (cf. figure 2.2). Pour les besoins du manuscrit, cette instance omet volontai-
rement plusieurs composants matriels (tels que le contrleur dinterruption, le gestionnaire de
la plate-forme, etc.) que nous nallons pas considrer pour notre tude. Il convient galement de
remarquer que nous avons regroup plusieurs composants matriels implmentant des fonc-
tions similaires (les contrleurs dentres-sorties, les priphriques, etc.) au sein dune mme
entit afin de rduire la taille du graphe des actions lmentaires construit et, par l-mme,
gagner en lisibilit. Bien videmment, un systme informatique rel sera trs rarement aussi
simple. Ainsi, le systme informatique que nous allons considrer est compos dun seul pro-
cesseur, dune mmoire centrale et de contrleurs dentres-sorties, interconnects au moyen
de bus distincts relis un unique rpartiteur. Les contrleurs dentres-sorties tant ici gn-
riques, ils pourront tre considrs comme des contrleurs internes, comme des contrleurs
externes ou comme des contrleurs de priphriques selon le contexte.
Rpartiteur Contrleur de
Processeur
mmoire
Contrleurs
Priphriques Mmoires
d'entres-sorties
F IGURE 2.5 Exemple de systme informatique
Pour identifier lensemble des attaques lmentaires dans le systme informatique, nous
38
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
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.
2.3 Illustration du modle par plusieurs exemples rels dattaque

Dans cette section, nous illustrons le modle dattaques que nous venons dtablir par plu-
sieurs preuves de concept dattaques qui ont t dmontres pour des systmes informatiques
compatibles PC. Cette section va nous permettre, dune part, de confronter notre modle dif-
frentes attaques relles et, par l-mme, de le valider ; et, dautre part, permettre au lecteur
dapprhender facilement notre modle. Pour chacun des trois exemples dattaques que nous
dtaillons dans la suite, nous commenons par rappeler quelques considrations techniques
permettant de mieux les comprendre. En nous appuyant sur le modle dattaques que nous
avons tabli, nous donnons ensuite les grandes lignes de lattaque. Les squences dactions
lmentaires sont reprsentes sur la figure 2.7
2.3.1 Usurpation didentit de priphriques USB

LUniversal Serial Bus (USB) est un standard de bus srie conu pour connecter chaud
des priphriques externes des plates-formes matrielles. Ceux-ci sont alors automatique-
ment reconnus par le systme dexploitation qui leur affecte dynamiquement des ressources et
charge les pilotes de priphriques correspondants sans quun redmarrage ne soit ncessaire.
De par la multiplicit de leurs utilisations, les priphriques USB sont omniprsents dans les
environnements informatiques actuels. Ceux-ci sduisent les utilisateurs par les nombreuses
fonctionnalits attractives quils offrent : le transport et le stockage de donnes moindre cot,
lamorce dun systme, lexcution automatique dun programme, etc.
Ces fonctionnalits sont parfois dtournes des fins malveillantes. En effet, il nest pas rare
quun priphrique USB contienne des logiciels malveillants placs intentionnellement par le
concepteur ou le propritaire du priphrique, mais linsu de son utilisateur. Ces maliciels
exploitent ces fonctionnalits pour sexcuter et se propager sur les systmes auxquels ils sont
connects. Les systmes informatiques au cur de linstallation nuclaire Iranienne de Natanz
tant isols du rseau Internet, lAdvanced Persistent Threat (APT) Stuxnet a pleinement pro-
fit de ces fonctionnalits (et en particulier de lexcution automatique de programmes) des
priphriques USB pour infecter ces systmes [Falliere et al. 11]. Cette sous-section traite plus
particulirement des attaques qui usurpent lidentit de priphriques USB de type Human
Interface Device (HID) tels que les claviers USB.
Du point de vue de llectronique, un priphrique USB est relativement simple. Il com-
munique avec le contrleur de priphriques USB au travers de deux paires de fils. Une pre-
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

2 2
4
3 3 3
Configuration Logique Configuration Logique Configuration Logique
4 4
3 5 4 3 5 4

Logiciel Logiciel
5 5
5 5
Priphriques Contrleurs d'entres-sorties Mmoires
F IGURE 2.6 Graphe des actions lmentaires pour un systme informatique
42

Processeur Rpartiteur Contrleur de mmoire
5
5
Logiciel

3
Configuration Logique Configuration 4 Logique Configuration Logique

3 3
2 2
2
4
Configuration Logique 3
Configuration Logique Configuration Logique

Logiciel Logiciel
Priphriques Contrleurs d'entres-sorties Mmoires
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
F IGURE 2.7 Illustration de plusieurs exemples rels dattaques

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
et linstaller sur le poste victime. Cette porte drobe est ensuite utilise par lattaquant pour
accder au parc informatique de lentreprise cliente.
2.3.2 Modification dune ROM flashable dextension PCI
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
2.3.3 Modification de la routine de traitement de la SMI

Les processeurs x86 supportent plusieurs modes dopration. Le mode dopration nominal
correspond au mode protg pour les processeurs exploits en 32-bits et mode IA-32e pour les
processeurs 64-bits. Ils fournissent un ensemble de fonctionnalits tels que les anneaux (en
anglais, rings) qui rpartissent les fonctions du processeur sur diffrents niveaux de privilge,
les units de segmentation et de pagination qui assurent la protection de la mmoire, etc. Le
mode rel, quant lui, permet une compatibilit descendante avec les processeurs Intel 8086. Il
sagit du mode dopration initial des processeurs x86 et il incombe au systme dexploitation
de passer ensuite dans le mode protg. Le mode 8086 virtuel (virtual-8086 mode) contribue
galement la compatibilit avec les processeurs Intel 8086. Il rend possible lexcution de
logiciels crits pour ce type de processeur dans un environnement o chaque tche dispose
dun espace dadressage isol. Finalement, le mode de gestion systme (System Management
Mode ou SMM) est une fonctionnalit architecturale standard de tous les processeurs x86. Il est
ddi lexcution dune routine dinterruption qui gre diffrents vnements spcifiques
la plate-forme matrielle. La prsente sous-section sintresse ce dernier mode dopration.
Le processeur entre dans le mode SMM la rception dune SMI (System Management Inter-
rupt). Il sagit dune interruption matrielle gnre par le chipset lorsque certains vnements
se produisent : le rveil dun priphrique, la surchauffe du processeur, les erreurs physiques de
la mmoire, le contrle des diffrents ventilateurs, etc. Lorsque le processeur reoit une SMI, il
bascule automatiquement dans le mode SMM et sauvegarde en mmoire le contexte de la tche
qui sexcutait jusqualors (en particulier ltat des registres de donnes et de contrle du pro-
cesseur), dans une rgion de la mmoire centrale appele SMRAM (System Management RAM)
mise en place par le BIOS linitialisation de la machine. Suite cela, la routine de traitement
de la SMI est alors excute. Celle-ci sexcute de faon transparente et a accs lensemble de
la plate-forme matrielle : la mmoire physique de la machine (dans une limite de 4 Go), les re-
gistres de configuration ou de lespace de mmoire propre des priphriques, etc. Un attaquant
qui serait capable dinjecter du code dans cette routine de traitement de la SMI pourrait alors
simplement prendre le contrle de la machine.
Les accs la SMRAM sont contrls par le chipset. La configuration de ce mcanisme re-
pose sur le positionnement de certains bits des registres SMRAMC (SMRAM Control) et ESM-
RAMC (Extended SMRAM Control). Lorsque le bit D_OPEN du registre SMRAMC est positionn
0, alors laccs la SMRAM nest autoris que depuis le mode SMM. Sil est 1, la SMRAM
est accessible depuis nimporte quel mode dopration du processeur. Le BIOS est cens, aprs
avoir copi la routine SMI dans cette rgion, positionner le bit D_LCK 1. Cela provoque auto-
matiquement la mise 0 de D_OPEN et empche toute modification des registres SMRAMC et
ESMRAMC avant le prochain redmarrage de la machine. Depuis 2006, la plupart des concep-
teurs de BIOS utilisent bon escient ce mcanisme de contrle daccs la SMRAM. Aussi,
il est aujourdhui difficile de remplacer le code de cette routine dinterruption par du code
malveillant et il est ncessaire, sur les plates-formes matrielles rcentes, de trouver une autre
technique pour contourner ce mcanisme de contrle daccs la SMRAM.
En 2009, plusieurs auteurs [Wojtczuk et Rutkowska 09a, Duflot et Levillain 09] ont propos,
de manire indpendante, une technique dattaque qui repose sur lempoisonnement du cache
des processeurs. Pour remplacer la routine de traitement de la SMI, lattaquant commence par
configurer la rgion de mmoire centrale o la SMRAM est situe en Write-Back (WB) afin que
toute criture cette rgion de mmoire soit automatiquement mise en cache (transition ).
Lattaquant crit ensuite du code malveillant dans cette rgion de mmoire dans le but de rem-
placer la routine de traitement de la SMI dans le cache (transition puis ). Il ne reste plus,
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 ).
2.4 Limites du modle dattaques

Notre travail de rflexion sur un modle dattaques capable de reprsenter les attaques
lmentaires pour chaque niveau dabstraction dun systme informatique a abouti un nou-
veau formalisme de modlisation graphique dattaques. La modlisation que nous proposons
ne prtend aucunement remplacer les formalismes classiquement utiliss dans le domaine de
la scurit, tels que les arbres dattaque [Schneier 99], les arbres de dfaillances dynamiques (en
anglais, Dynamic Fault Trees ou DFT) [Bechta Dugan et al. 90], les graphes dattaques [Sheyner 04]
ou les Boolean logic Driven Markov Processes (BDMP) [Bouissou et Bon 03]. Compar aux autres
formalismes, notre modle nous a paru plus simple mettre en uvre afin de reprsenter
et analyser diffrents scnarios envisageables par un attaquant, impliquant diffrents niveaux
dabstraction dun systme informatique, pour atteindre un ou plusieurs objectifs.
Llaboration dun modle dattaques est unanimement reconnue comme une problma-
tique ardue et mriterait elle seule que nous lui consacrions une thse. Ainsi, le modle que
nous prsentons dans ce chapitre est ncessairement incomplet et prsente quelques limites.
Une des premires limites que nous pouvons signaler dcoule de la formalisation math-
matique que nous avons tablie pour dfinir une attaque. Dans celle-ci, nous avons considr
une attaque comme une succession dactions lmentaires dont le squencement suit un ordre
total. Or, certaines actions lmentaires dans une attaque peuvent suivre un ordre partiel. Une
attaque par blouissement (cf. chapitre 1) noie, par exemple, les actions lmentaires consti-
tuant une attaque dans un nombre important dactions lmentaires sans relle relation avec
la dite attaque. Ces dernires peuvent sentrelacer de faon arbitraire avec les actions lmen-
taires constituant lattaque dans la mesure o leurs effets nimpactent pas ltat du systme ci-
bl. Considrer un ordre partiel sur les actions lmentaires nest pas trivial dans notre modle
dattaques car cela ncessite de dfinir quelles pr-conditions permettent deffectuer une action
lmentaire. ce propos, nous gagnerions probablement en lisibilit et en puissance de mod-
lisation si le modle dattaque tait reprsent sous la forme dun rseau de Petri [Petri 62]. En
effet, les rseaux de Petri sont des formalismes puissants qui permettent la spcification gra-
phique dinteractions complexes tels que les conflits, la synchronisation, les boucles, les exclu-
sions mutelles ou encore le partage de ressources. Entre autres, leur puissance de modlisation
permettrait de rendre compte plus simplement de laspect squentiel des attaques, des actions
concurrentes, etc.
Une autre limite que nous avons identifie est son passage lchelle. Le graphe de flots de
donnes peut rapidement devenir complexe ds lors que nous ajoutons des composants mat-
riels. Le modle correspondant sera alors difficilement lisible et lexplosion combinatoire des
chemins explorer pour identifier les attaques deviendra rapidement problmatique. Jusqu
prsent, nous navons pas de pistes intressantes pour pallier ce problme.
Il convient de noter que nous aurions pu approfondir notre modle en travaillant sur les
limites mentionnes prcdemment. Cependant, dans son tat actuel, celui-ci est un stade
suffisament avanc pour nous permettre de nous focaliser sur ltude des attaques par entres-
sorties qui constitue lobjectif principal de cette thse. Nous avons envisag dlaborer davan-
tage notre modle dattaques pour nos travaux futurs.
47
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
Mise en uvre dattaques par

entres-sorties sur une architecture PC
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.
3.1 Aperu de larchitecture Intel-PC

Dans la littrature, nous retrouvons plusieurs dfinitions diffrentes associes au terme ar-
chitecture matrielle. Aussi nous parat-il essentiel de le prciser. Dans un systme informatique,
le terme architecture matrielle couvre trois aspects du systme. Historiquement, ce terme dsi-
gnait uniquement le jeu dinstructions (en anglais, instruction set) des processeurs. Nous par-
lions alors, par exemple, darchitecture matrielle SPARC, PowerPC, ARM ou MIPS. Des volu-
tions architecturales ont ensuite t apportes pour que les processeurs puissent atteindre des
frquences plus leves. La dfinition de ce terme a suivi cette volution et sest tendue pour
y adjoindre la micro-architecture des processeurs. Le mme jeu dinstructions Intel pouvait
alors tre implment par plusieurs (micro-)architectures matrielles de processeurs : Pentium,
Core, Nehalem, Sandy Bridge, etc. Rcemment, la dfinition associe ce terme sest davantage
largie et couvre aujourdhui galement linfrastructure matrielle du systme informatique.
Puisque ce chapitre est ddi aux attaques reposant sur les contrleurs dentres-sorties,
cest tout dabord ce dernier aspect auquel nous nous intressons. Puis, nous dtaillons les
diffrents espaces dadressage ainsi que les modes dentre-sortie supports par larchitec-
ture Intel-PC. Le lecteur intress par dautres aspects de cette architecture pourra consulter,
en complment, le dossier que nous avons publi dans la revue de vulgarisation scientifique
Multi-System & Internet Security Cookbook (MISC) [Chifflier et al. 11].
3.1.1 Infrastructure matrielle

La structure matrielle dun systme informatique de type PC se compose dun circuit im-
prim principal appel carte-mre qui relie lectriquement plusieurs composants matriels :
un ou plusieurs processeurs ;
la mmoire centrale, qui se matrialise physiquement sous la forme dune ou de plu-
sieurs barrettes composes de circuits intgrs qui constituent la mmoire ;
des contrleurs dentres-sorties internes, dont le rle est dtendre les bus dentres-
sorties ou de piloter dautres composants internes ou externes tels que les disques ;
une ou plusieurs cartes dextension (ou cartes-fille), qui embarquent un ou plusieurs
contrleurs dentres-sorties externes. Elles sont enfiches sur des connecteurs spci-
fiques relis un ou plusieurs bus dextension tels quels les bus PCI et les bus PCI
Express ;
plusieurs circuits intgrs, qui sont directement souds sur la carte-mre pour raliser
des fonctions annexes tels que le stockage de la configuration du matriel et lhorloge ;
un ou plusieurs priphriques, qui se connectent aux contrleurs de priphriques
laide de connecteurs spcifiques relis des bus de priphriques tels que les bus USB
50
3.1. Aperu de larchitecture Intel-PC
et les bus FireWire.

Au sein de la carte-mre, les diffrents composants communiquent au travers dun en-
semble de puces lectroniques appel chipset. Il interconnecte le ou les processeurs dautres
composants matriels tels que la mmoire centrale, la carte graphique, la carte rseau, les
contrleurs de disques, les priphriques, etc. La plupart des chipsets dIntel (et, jusqu rcem-
ment, ceux de ses concurrents) reposent sur une infrastructure plusieurs niveaux incorporant
une partie northbridge (littralement, pont du nord) et une partie southbridge (littralement, pont
du sud) relis entre eux par un bus propritaire parfois appel Direct Media Interface (DMI).
La figure 3.1 prsente une organisation possible de ces composants matriels.
Processeur
Cur Cur Cur Cur
bus PCI
bus PCI Express Unit de gestion mmoire
autres bus
bus FSB
Memory Controller Hub
Pont PCI Express
Carte graphique Pont PCI Express Direct Media Interface
bus DMI
Southbridge
Disque Contrleur de disque Direct Media Interface
Haut-parleurs Contrleur audio
RJ45 Contrleur Ethernet Pont PCI Express-PCI Carte FireWire
Cl USB Contrleur USB

Clavier Contrleur SuperIO Pont PCI Express
F IGURE 3.1 Exemple darchitecture matrielle Intel-PC (chipset Q45)
Le northbridge relie le ou les processeurs et la mmoire centrale aux diffrents contrleurs

dentres-sorties. Ces derniers peuvent tre connects au northbridge, soit directement, soit par
lintermdiaire dun pont PCI Express, lorsque ceux-ci requirent de larges bandes passantes
(typiquement, les contrleurs graphiques), ou au travers du southbridge, lorsque ceux-ci nces-
sitent moins de ressources. Sur les anciennes cartes-mre, le northbridge pouvait comprendre
jusqu trois puces. Aujourdhui, il nest constitu que dune seule puce qui tend mme tre
directement intgre dans les processeurs. Par exemple, les processeurs Intel ( partir de Ne-
halem et surtout Sandy Bridge) et les processeurs AMD (Fusion) actuels intgrent dsormais le
contrleur de mmoire et quelques contrleurs dentres-sorties rapides tels que les contrleurs
graphiques.
Le southbridge assure la connexion entre la plupart des contrleurs dentres-sorties et le
northbridge. Il fournit plusieurs interfaces qui permettent de communiquer sur diffrents types
de bus tels que les bus USB, les bus FireWire ou les bus PCI auxquels peuvent tre connects
dautres contrleurs dentres-sorties (internes ou externes) et des priphriques. La commu-
nication avec ces bus seffectue au travers de ponts (par exemple, un pont PCI Express-PCI) ou
au travers de contrleurs de bus (tels que des contrleurs USB, des contrleurs FireWire). Le
southbridge a toujours t constitu dune seule puce et il est, dune certaine manire, interchan-
geable. En effet, un mme modle de puce pour le northbridge est compatible avec diffrents
modles de puce pour le southbridge, permettant ainsi aux fabricants de cartes-mre de diversi-
51
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).
3.1.2 Espaces dadressage

Les architectures PC dfinissent trois espaces dadressage distincts (cf. figure 3.2) : lespace
mmoire, lespace dentre-sortie et lespace de configuration des contrleurs PCI et PCI Ex-
press. Chaque espace dadressage dispose dun mcanisme daccs qui lui est spcifique.
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
F IGURE 3.2 Espaces dadressage dfinis dans les architectures PC
3.1.2.1 Espace mmoire

Lespace mmoire (en anglais, memory space) peut stendre jusqu 4 gigaoctets dans les sys-
tmes informatiques qui supportent un mode dadressage de la mmoire sur 32 bits, et jusqu
16 exaoctets sur ceux qui supportent un mode dadressage de la mmoire sur 64 bits. Les accs
cet espace dadressage utilisent des adresses physiques 16 et sont, pour la plupart, aiguills
vers le contrleur de mmoire (Memory Controller Hub). Elles concernent, par consquent, prin-
cipalement les accs la mmoire centrale. Cependant, plusieurs contrleurs dentres-sorties
16
Il est important ici de distinguer les adresses virtuelles et les adresses physiques. Les adresses manipules par
les programmes correspondent des adresses virtuelles et sont utilises pour accder une mmoire virtuelle. Les
units de gestion de la mmoire situes dans les processeurs convertissent systmatiquement ces adresses virtuelles
en adresses physiques pouvant tre manipules par les contrleurs dentres-sorties. Cette conversion ncessite des
tables de traduction les tables des pages (en anglais, page tables) stockes en mmoire centrale.
52
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.
3.1.2.2 Espace dentre-sortie

Lespace dentre-sortie (en anglais, I/O space) est ddi aux entres-sorties. Il sagit dun es-
pace dadressage logiquement indpendant de lespace mmoire. Il peut stendre thorique-
ment jusqu 4 gigaoctets. Cependant, de nombreuses plates-formes matrielles restreignent
laccs cet espace dadressage uniquement aux 64 premiers kilooctets. Cette restriction tait
initialement due la limite dadressabilit de cet espace dans les premiers processeurs In-
tel 8086 (16 bits). Elle a t maintenue jusque dans les processeurs rcents compatibles x86 mal-
gr leur capacit dadressage plus grande (32 ou 64 bits). Historiquement, cet espace dadres-
sage servait interroger, au travers de registres, des composants matriels divers : les contr-
leurs de disques Advanced Technology Attachment (ATA), les ports srie et les ports parallle,
les claviers implmentant le standard PS/2 et les souris, les manettes de jeu vido, etc. Les
registres projets dans cet espace sont appels plus spcifiquement des ports dentres-sorties
justifiant ainsi le nom attribu ce mcanisme : Port Mapped I/O (PMIO) ou plus simplement
Port I/O (PIO). Aujourdhui, cet espace dadressage reste trs peu usit cause de la lenteur des
transferts dentres-sorties quimplique son utilisation et nest gard que pour des raisons de
rtro-compatibilit. En effet, lespace dadressage tant de taille restreinte, les portions de m-
moire interne des contrleurs dentres-sorties ne peuvent pas tre directement projetes dans
cet espace. Pour pallier cette limite, les contrleurs dentres-sorties dfinissent un mcanisme
de fentrage qui, au lieu de projeter lintgralit de la mmoire interne dans cet espace, projette
uniquement une sous-partie spcifique de cette mmoire interne. Ce mcanisme consomme
ainsi moins de resources, mais requiert plus de cycles du processeur (et par-l mme, plus de
temps) dans la mesure o la fentre dfinie par le contrleur dentres-sorties est petite et que la
quantit de donnes transfrer est importante. Les performances dentres-sorties moindres
par rapport aux accs lespace mmoire sexpliquent galement par les modes daccs quils
supportent respectivement : lespace dentre-sortie ne supporte que des accs par blocs de
taille fixe (de 1, 2 ou 4 octets) alors que lespace mmoire autorise des accs par blocs de taille
variable pouvant aller thoriquement jusqu 4096 octets.
3.1.2.3 Espace de configuration des contrleurs PCI et PCI Express

La configuration matrielle des premiers systmes informatiques compatibles PC tait une
opration souvent dlicate et source de problmes importants. En effet, ils ncessitaient daffec-
17
Sur des architectures PC plus anciennes, il arrivait que le chipset rserve une partie des adresses utilises pour la
mmoire centrale au mcanisme de MMIO, empchant ainsi son utilisation. Ce phnomne tait d une limite
dadressabilit des processeurs de lpoque. Ce problme nest plus dactualit avec les processeurs 64 bits actuels.
53
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
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
I/O Base I/O Limit Memory Base Memory Limit
En-tte gnrique Partie spcifique
F IGURE 3.3 Espace de configuration dun contrleur PCI
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.
3.1.3 Modes dentre-sortie
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
3.1.3.1 Entres-sorties programmes

Les entres-sorties programmes (en anglais, programmed I/O 18 ) dsignent un mode dentre-
sortie synchrone dans lequel les processeurs initient et grent eux-mmes les transferts de don-
nes avec les contrleurs dentres-sorties 19 . Au sein dun programme, ces transferts dentres-
sorties sont mis en uvre laide dinstructions spcifiques des processeurs. titre dexemple,
les transferts de donnes dans lespace dentre-sortie ncessitent lutilisation dinstructions
ddies : les instructions in (respectivement, out) en assembleur pour des oprations de lec-
ture (respectivement, dcriture). A contrario, les transferts de donnes vers lespace mmoire
ne requirent pas dinstructions ddies et se font simplement en utilisant les instructions mov
en assembleur.
3.1.3.2 Bus-mastering I/O

Les transferts de donnes vers lun des espaces dadressage peuvent galement tre grs
par certains contrleurs dentres-sorties. Cest le cas, en particulier, des contrleurs dits bus-
masters qui sont capables leur propre initiative, linitiative dun processeur ou dun pri-
phrique de prendre le contrle des bus dentres-sorties et deffectuer sur ces bus un trans-
fert de donnes vers lun des espaces dadressage. Ce mode dentre-sortie asynchrone soulage
les processeurs de ces transferts de donnes et leur permet deffectuer dautres tches pen-
dant que les transferts se droulent. Actuellement, de nombreux contrleurs dentres-sorties
sont capables deffectuer des accs vers lespace mmoire, notamment pour changer des don-
nes avec la mmoire centrale. Nous parlons alors daccs direct la mmoire (Direct Memory
Access, ou DMA). Il convient de prciser que, mme si en pratique cela est assez peu usit, cer-
tains contrleurs dentres-sorties utilisent aussi ce mode dentre-sortie pour dialoguer avec
dautres contrleurs dentres-sorties. Nous parlons alors daccs pair--pair (en anglais, peer-
to-peer). Certaines cartes graphiques rcentes, utilises pour des calculs hautes performances,
peuvent sen servir pour dialoguer directement avec dautres cartes graphiques sans utiliser
les processeurs comme intermdiaires. Nous dtaillons davantage ces deux modes de commu-
nication DMA et pair--pair dans les prochaines sections.
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.
3.2 Contrle des accs directs la mmoire centrale
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
3.2.1 Attaques par accs direct la mmoire

Laccs direct la mmoire ou DMA (Direct Memory Access) est un mcanisme o la gestion
des transferts de donnes vers la mmoire centrale est laisse aux contrleurs dentres-sorties.
Les processeurs ne sont notifis qua posteriori par une interruption qui les prvient de la fin
du transfert. Pour accomplir ces transferts, un contrleur dentres-sorties endosse temporaire-
ment le rle de matre sur les bus dentres-sorties de faon en prendre le contrle et mettre
sur ceux-ci les requtes daccs correspondantes. Jusqu trs rcemment, ces transferts se ra-
lisaient de manire transparente pour le systme dexploitation. Ni les processeurs, ni le chipset
ntaient alors en mesure de contrler les adresses vers lesquelles seffectuaient ces transferts
et, encore moins, de bloquer les ventuels accs frauduleux. Des attaquants ont naturellement
profit de cette faiblesse structurelle pour violer les proprits de scurit (intgrit et confi-
dentialit) des composants logiciels chargs en mmoire centrale. Laccs certaines rgions de
mmoire (par exemple, celles contenant le code du noyau de systme dexploitation) pouvant
tre restreint par les processeurs, il tait ainsi plus simple, pour un attaquant, de mettre en place
ces accs avec le concours dun contrleur dentres-sorties. En effet, de tels accs ne peuvent
pas tre contrls par un logiciel de dtection ou de protection tant donn quils ne ncessitent
pas lintervention des processeurs principaux. Nous parlons alors dattaques par accs direct
la mmoire, en rfrence au type daccs dentres-sorties sur lequel elles sappuient. Chaque
contrleur dentres-sorties implmente une manire de configurer un transfert de donnes
qui lui est spcifique. Toutefois, cette configuration seffectue depuis un processeur, depuis un
priphrique, voire depuis le contrleur dentres-sorties lui-mme.
3.2.1.1 Attaques DMA inities par les processeurs

Les attaques par accs direct la mmoire dont les transferts sont initis par les proces-
seurs ncessitent lexcution dun code malveillant par le processeur principal. Une attaque ty-
pique consiste mettre en place, dans un premier temps, des structures de contrle en mmoire
centrale qui dcrivent les transferts effectuer : ladresse, la direction 20 et la taille de chacun
deux doivent notamment tre prcises. Le logiciel malveillant prcise ensuite au contrleur
dentres-sorties, en positionnant un registre prvu cet effet, la localisation de la structure de
contrle concerne, et le contrleur excutera les transferts programms la rception dun v-
nement spcifique (par exemple, une interruption). Ces transferts peuvent cibler une adresse
quelconque de la mmoire centrale. En particulier, il peut tre intressant, pour un attaquant,
de cibler le noyau de systme dexploitation (code ou tables de configuration, en particulier les
tables de gestion de la mmoire). En effet, corrompre le systme dexploitation signifie poten-
tiellement corrompre lensemble des applications qui sexcutent au dessus de ce noyau.
Les preuves de concept dattaques qui reposent sur ce mode opratoire mettent en uvre
des contrleurs dentres-sorties varis. Celle publie dans [Duflot 07] dcrit, par exemple, une
escalade de privilges laide de contrleurs de priphriques USB : lattaquant met en place
plusieurs transferts de donnes dans le contrleur USB de faon lui faire craser des rgions
prcises de la mmoire centrale (la rgion de donnes contenant la valeur du securelevel 21 dans
un systme OpenBSD) par les donnes fournies par les priphriques USB. Les transferts sont
20
Nous distinguons deux directions de transfert de donnes possibles : un transfert de la mmoire centrale vers le
contrleur dentres-sorties ou linverse, cest--dire du contrleur dentres-sorties vers la mmoire centrale.
21
Dans un systme de type BSD, cette variable indique le niveau de scurit mis en uvre par le noyau de systme
dexploitation. Des restrictions au sein du systme (par exemple, accs aux priphriques virtuels, oprations au-
torises sur les disques, etc.) sont instaures en fonction de sa valeur. Plus celle-ci est leve, plus elle implique de
restrictions.
58
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.
3.2.1.2 Attaques DMA inities par les priphriques

Les attaques par accs direct la mmoire dont les transferts sont initis par les priph-
riques requirent au pralable un accs physique au systme cible. En effet, elles ncessitent la
modification dun priphrique de faon ce quil puisse se comporter la fois en matre et
en esclave sur son bus et non plus uniquement en esclave comme est suppos se comporter un
priphrique classique. Un attaquant exploite ensuite la capacit de ce priphrique prendre
le contrle de son bus afin de soumettre au contrleur de priphrique des commandes pour
mettre en place des transferts de donnes avec la mmoire centrale. Aujourdhui, de nombreux
59
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.
3.2.1.3 Attaques DMA inities par un contrleur dentres-sorties
Finalement, certains contrleurs dentres-sorties peuvent initier eux-mmes des transferts

de donnes vers la mmoire centrale. Nous distinguons, parmi les contrleurs dentres-sorties
qui disposent dune telle capacit, ceux qui ont t conus dlibrment pour cela et ceux qui
ont t modifis cet effet.
La plupart des contrleurs dentres-sorties conus pour initier eux-mmes des transferts
de donnes vers la mmoire centrale reposent sur un micro-contrleur pour piloter les bus
dentres-sorties ou sont programms laide de technologies de logique programmable tels
que les FPGA. De nombreuses preuves de concept dattaques par entres-sorties ont recours
ce type de contrleur dentres-sorties malveillant [Aumaitre et Devine 10, Carrier et Grand 04,
Devine et Vissian 09, Petroni et al. 04]. Puisque lattaquant conoit lui-mme son propre contr-
leur dentres-sorties, il a la libert de dfinir son propre canal de commande et dimplmenter,
au sein de son contrleur dentres-sorties, des fonctionnalits qui ne seraient pas disponibles
dans les contrleurs dentres-sorties sur tagre.
Une autre possibilit, cependant moins permissive que lapproche prcdente, consiste
modifier un contrleur dentres-sorties existant. Ceci est possible parce que les contrleurs
dentres-sorties disposent de plus en plus de capacits de calcul pour dcharger davantage
les processeurs principaux de certains calculs et pour gagner en performances. cet effet, ils
embarquent un ou plusieurs processeurs sur lesquels sexcute un firmware qui dcrit les trai-
tements effectuer. Il est possible de modifier ce programme de faon ce que le contrleur
dentres-sorties puisse, de lui mme, initier des accs la mmoire centrale. notre connais-
sance, A. Triulzi a t le premier utiliser cette technique : il dcrit dans [Triulzi 08a] une
modification (hors-ligne) du firmware de la carte rseau Broadcom Tigon consistant trans-
22
lorigine, les bus FireWire ont t crs pour accueillir des priphriques externes qui ncessitent une bande
passante leve. Parmi ceux-ci, les priphriques multimdias tels que les appareils photo, les camras numriques
et les disques durs externes ncessitent des taux de transferts particulirement levs. Ces besoins expliquent la
possibilit offerte ces priphriques de commander le contrleur de priphriques auquel ils sont relis et dinitier
des transferts avec sa mmoire. Les accs cette mmoire sont gnralement redirigs vers la mmoire centrale.
60
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.
3.2.2 Quelques contre-mesures spcifiques

Plusieurs solutions techniques ont t proposes pour parer les attaques par accs direct
la mmoire. Dans cette sous-section, nous analysons quelques-unes de ces solutions.
Une premire solution, propose par L. Duflot [Duflot 07], vise spcifiquement le problme
des attaques par accs direct la mmoire inities par les processeurs. Elle consiste filtrer, au
niveau des processeurs, les accs dentres-sorties qui peuvent tre considrs comme dange-
reux. Si laccs est jug peu dangereux (par exemple, une opration de lecture sur un registre
dont la valeur ninflue pas sur la scurit du systme), le noyau de systme dexploitation laisse
lopration se drouler. En revanche, si laccs peut tre utilis pour mettre en place une attaque
(et, en particulier, pour configurer des accs directs la mmoire), le noyau de systme dex-
ploitation bloque laccs. La mise en place dune telle solution de filtrage des entres-sorties
ncessite dapporter des modifications consquentes au noyau de systme dexploitation (no-
tamment, les appels systme) de faon intercepter et vrifier tous les accs dentres-sorties.
Il ncessite galement dintgrer au sein du noyau une infrastructure permettant dappliquer
des rgles de filtrage qui peuvent voluer en fonction des vnements matriels (par exemple,
ajout ou retrait dun composant matriel). Cette solution tant inefficace vis--vis dattaques
inities par un priphrique ou par un contrleur dentres-sorties, elle napporte quune r-
ponse partielle au manque de contrle daccs sur les bus dentres-sorties.
Dautres solutions ont t proposes pour dtecter une attaque excute par un firmware
malveillant sur un contrleur dentres-sorties. Elles sinspirent des techniques de protection
dapplications logicielles qui sont aujourdhui largement prouves et ncessitent, en pratique,
daltrer le code du firmware. Dans [Duflot et al. 11], les auteurs proposent, par exemple, de
vrifier les chemins dexcution du firmware. cet effet, une copie de la pile est cre chaque
61
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.
3.2.3 Contre-mesure gnrique : une I/O MMU

Les I/O MMUs dsignent des units de gestion de la mmoire centrale ddies aux contr-
leurs dentres-sorties. Elles ont t initialement conues pour virtualiser cette mmoire pour
les contrleurs dentres-sorties, leur mise en uvre permettant, entre autres, de simplifier les
accs dentres-sorties. Il est possible, par exemple, dutiliser une I/O MMU pour mettre en
62
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).
3.2.3.1 Intel VT-d : I/O MMU ddie aux architectures Intel-PC
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
DRHD Segment Number

RRMR Register Base Address
Remapping Structures[] Device Scope[]
F IGURE 3.4 Structure simplifie de la table ACPI DMAR
Requester ID Adresse DMA Virtuelle
15 8 7 3 2 0 63 39 38 30 29 21 20 12 11 0
bus device function index index index offset
x8 x8 x8
4kB Page
Page Table #3
Page Table #2
Root-entry Root-entry Context-entry Page Table #1
Table Address Table Table
F IGURE 3.5 Logique de parcours des tables de configuration pour Intel VT-d
64
3.2.3.2 Limitations dIntel VT-d
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 insuffisant La contre-mesure matrielle Intel VT-d ne permet de contrler

que partiellement les entres-sorties. En effet, seuls les accs la mmoire centrale sont filtrs.
Il reste possible, par exemple, aux contrleurs dentres-sorties de dialoguer directement entre
eux, via lun des espaces dadressages. Nous traitons des attaques exploitant les communica-
tions pair--pair dans la section 3.3.
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.).
Activation la discrtion du systme dexploitation. Puisque lactivation de lI/O MMU et,

par l-mme, la mise en uvre de son contrle daccs sur les bus dentres-sorties est la
discrtion du systme dexploitation, un attaquant peut ventuellement forcer le systme dex-
ploitation ne pas activer cette contre-mesure matrielle, par exemple, suite lexploitation
dune vulnrabilit logicielle. Par ailleurs, la dtection et la mise en uvre de celle-ci dpend
de tables ACPI charges en mmoire. Comme le chargement du systme dexploitation vient
aprs linitialisation des contrleurs dentres-sorties par le BIOS, une autre attaque qui peut
tre envisage pour dsactiver lI/O MMU consiste profiter de ce laps de temps pour effacer
ces tables de la mmoire depuis un contrleur malveillant initialis. Cette attaque est cepen-
dant difficile mettre en uvre car il est ncessaire de changer la structure de lensemble des
65
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.
3.2.4 Attaques par partage didentifiants

Le standard PCI (pour Peripheral Component Interconnect) a longtemps t utilis comme
norme de bus systme dans un ordinateur. Cependant, avec laugmentation croissante de la fr-
quence des processeurs au fil des annes (de 66 MHz en 1993 plus de 3 GHz en 2003), la bande
passante du PCI est rapidement devenue un goulot dtranglement dans les ordinateurs. Pour
pallier ce problme, Intel a alors encourag au cours de lt 2004 lutilisation du PCI Express
comme bus systme. Afin dassurer la retro-compatibilit des contrleurs dentres-sorties PCI
sur la nouvelle architecture, des ponts PCI Express-PCI ont t rajouts au niveau du chipset.
Ceux-ci interconnectent les bus PCI aux bus PCI Express et se chargent de faire la traduction
de toutes les requtes dun standard lautre. Dans la pratique, le fonctionnement des ponts
PCI Express-PCI se rapproche plus de celui dun mandataire (en anglais, proxy) que dun pont.
Pour nous en convaincre, analysons comment seffectue la traduction dun accs direct la m-
moire depuis un contrleur dentres-sorties PCI. Ces accs, contrairement ceux effectus par
les contrleurs PCI Express, ne contiennent pas de champ Requester ID. Pour combler ce
66
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.
3.2.5 Contre-mesures complmentaires

Pour se protger contre le partage didentit sur le bus PCI, une solution simple consiste
isoler chaque contrleur dentres-sorties PCI sur un bus spar. Ce faisant, la confusion entre
les identifiants des contrleurs PCI disparatrait. La fonctionnalit que nous avons utilise pour
notre tude ne serait plus exploitable car lisolation entre les rgions de mmoires associes
26
Constat effectu sur les cartes-mre Intel dont les spcifications techniques sont disponibles ladresse http://
ark.intel.com/ProductCollection.aspx?familyId=1125
67
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.
Type de contrle daccs Description

ACS Source Validation Bloque toutes les requtes ayant un numro de bus nap-
partenant pas une plage attendue
ACS Translation Blocking Bloque toutes les requtes ayant le champ AT positionn
ACS P2P Request Redirect Redirige toutes les requtes directes entre contrleurs (dites
pair--pair) vers dautres contrleurs
ACS P2P Completion Redirect Redirige toutes les rponses directes entre contrleurs
(dites pair--pair) vers dautres contrleurs
ACS P2P Upstream Forwarding Redirige toutes les requtes directes entre contrleurs (dites
pair--pair) vers dautres contrleurs
ACS P2P Egress Control Bloque toutes les requtes pair--pair
ACS Direct Translated P2P Lorsque le champ AT est positionn, transmet la requte
vers le contrleur de destination sans vrification suppl-
mentaire
TABLE 3.1 Access Control Services
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.
3.3 Contrle des accs pair--pair

Dans la section prcdente, nous navons considr que les accs depuis les contrleurs
dentres-sorties destins la mmoire centrale. Il est opportun de remarquer que certains
contrleurs dentres-sorties, notamment certaines cartes graphiques et certaines cartes rseau,
ont la facult de communiquer entre eux, sans que les processeurs ne se chargent des trans-
ferts ni que la mmoire centrale ne soit utilise comme relais. Dans les architectures PC plus
anciennes, ces communications directes entre contrleurs dentres-sorties seffectuaient au tra-
vers de bus ddis (et propritaires) : il tait alors ncessaire de coupler plusieurs contrleurs
au moyen de connecteurs spcifiques (par exemple, par un cble SLI ou CrossFire pour le cas
de cartes graphiques). Les vitesses des bus actuels ont permis de saffranchir de ces connecteurs
spcifiques et les changes se font aujourdhui directement au travers des bus dentres-sorties.
Nous parlons alors daccs pair--pair.
La prsente section sorganise comme suit. Nous commenons par rappeler les principes
des accs pair--pair. Nous prcisons en particulier les mcanismes internes aux chipsets qui
permettent de mettre en uvre ce type daccs. Nous voyons sans trop de peine les bnfices
que pourrait alors tirer un attaquant dun tel mcanisme. Les attaques par accs pair--pair
sont dautant plus dangereuses quelles ne modifient aucun moment la mmoire centrale
et, par l-mme, constituent des menaces encore plus difficiles dtecter par les solutions lo-
gicielles habituelles. Aprs avoir dtaill le principe de ces attaques, nous prsentons les r-
sultats de ltude que nous avons mene sur diffrents chipsets rcents afin didentifier les ac-
cs pair--pair possibles et les attaques qui peuvent en dcouler. Finalement, nous discutons
des contre-mesures celles-ci. Les rsultats prsents dans cette section ont t publis lors
du Symposium sur la Scurit des Technologies de lInformation et des Communications (SS-
TIC) [Lone Sang et al. 11] en 2011.
3.3.1 Attaques par accs pair--pair

Le chipset peut tre considr comme un rseau commut organis selon une topologie de
bus hirarchique. Chaque pont se charge daiguiller chaque accs quil reoit sur lun de ses
bus dentres-sorties pre ou fils (cf. figure 3.1). Laccs se propage ainsi, de proche en proche,
au travers des bus jusquau contrleur de destination o il sera trait. Afin que la configuration
de lensemble du chipset soit cohrente, il incombe au BIOS de configurer individuellement,
lors du dmarrage du systme, chaque pont au travers de lespace de configuration PCI ou
PCI Express qui leur est associ. Notamment, la paire de champs I/O Base et I/O Limit
(cf. figure 3.3) indique la plage de ports dentres-sorties qui est dcode pour ses bus fils.
De la mme faon, la paire Memory Base et Memory Limit dfinit la plage dadresses pour
lespace mmoire dcode pour ses bus fils. Ainsi, lorsquun accs est effectu depuis son bus
pre vers lune de ces deux plages dadresses, laccs est aiguill par le pont vers lun de ses
bus fils. Dans le cas inverse, laccs est aiguill de lun des bus fils vers le bus pre.
Comme indiqu prcdemment, les accs dentres-sorties peuvent cibler diffrents espaces
dadressage (cf. sous-section 3.1.2). Ainsi, les accs pair--pair peuvent aussi bien (thorique-
69
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.
3.3.2 Mise en uvre sur plusieurs chipsets rcents

Afin didentifier les chipsets actuels qui permettent de mettre en place des transferts pair--
pair, nous avons procd exprimentalement : nous avons lanc ce type de transfert de don-
nes entre diffrents contrleurs dentres-sorties et nous avons consign les rsultats dans un
tableau. La table 4.2 numre les chipsets que nous avons considrs dans notre tude. Pour
chacun de ces chipsets, nous prcisons les modles de northbridge et de southbridge concerns,
ainsi que le modle de machine sur laquelle les exprimentations ont t faites. La table 4.3
consigne les rsultats que nous avons obtenus. Par souci de lisibilit, nous avons regroup les
machines qui prsentent des comportements similaires. Il est important de prciser que nous
70
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)
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
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].
3.3.3 Contre-mesures envisageables

Afin de matriser les transferts de donnes directs entre contrleurs dentres-sorties, nous
pouvons nous appuyer sur diffrents mcanismes matriels existants.
Il est possible dutiliser des contre-mesures matrielles implmentant le principe dI/O
MMU pour limiter les capacits dinteraction de pair--pair entre contrleurs dentres-sorties,
en particulier, ceux effectuant des transferts vers des adresses de lespace mmoire. Dans les
chipsets actuels, les composants implmentant une I/O MMU sont gnralement placs dans
le northbridge, en coupure entre le bloc form par les contrleurs dentres-sorties et la m-
moire centrale. Lagencement de ces composants dans larchitecture matrielle fait en sorte
quils voient transiter toute requte destination de la mmoire centrale. De ce fait, ils la pro-
tgent efficacement de tout accs arbitraire depuis un contrleur dentres-sorties malveillant.
En ce qui concerne les accs pair--pair, tout change dun contrleur dentres-sorties situ
dans le northbridge vers un contrleur quelconque, quil soit dans le northbridge ou dans le sou-
28
Nous rappelons que cette option permet dutiliser certains priphriques USB (un clavier, une souris, un priph-
rique 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)
prsente les claviers ou les souris USB au systme dexploitation comme tant des priphriques PS/2.
73
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
76
Chapitre 4
Application des techniques de fuzzing

sur les bus dentres-sorties
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.
4.1 IronHide : outil dinjection de fautes sur les bus dentres-sorties

Le bus PCI Express est aujourdhui la norme de connexion des contrleurs dentres-sorties
dans les architectures matrielles PC. Dans cette section, nous commenons par introduire
quelques lments sur ce standard de bus. Ces lments permettent de mieux apprhender
loutil dinjection de fautes que nous prsentons par la suite. Cet outil a fait lobjet dun article
prsent lors de la confrence SSTIC [Lone Sang et al. 12b].
4.1.1 Introduction aux bus PCI Express

Cette sous-section commence par prsenter larchitecture dun contrleur dentres-sorties
typique. Nous nous focalisons ensuite sur la couche protocolaire par laquelle se font les injec-
tions de fautes. Finalement, nous prsentons le format des paquets PCI Express changs.
4.1.1.1 Protocole PCI Express

Larchitecture des contrleurs dentres-sorties PCI Express sinspire fortement du modle
Open System Interconnection (OSI). En effet, afin de rduire la complexit de leur logique, ils sont
gnralement architecturs en couches protocolaires indpendantes (cf. figure 4.1). Chaque
couche utilise les services fournis par les couches de niveau infrieur et dfinit de nouveaux
services pour les couches de niveau suprieur. Nous distinguons trois couches protocolaires
principales : la couche transaction, la couche liaison de donnes et la couche physique.
La couche transaction est la couche la plus haute du modle en couches. Elle se charge prin-
cipalement du transport de bout en bout des donnes entre les contrleurs dentres-sorties.
cet effet, elle encapsule ces donnes au sein dun Transaction Layer Packet (TLP) et utilise les ser-
vices fournis par les couches de niveau infrieur pour acheminer le paquet jusquau contrleur
destinataire. Un TLP se compose au minimum dun en-tte dont la longueur dpend du type de
transaction. Optionnellement, il peut transporter des donnes : les requtes daccs en criture
contiennent typiquement des donnes alors que les requtes daccs en lecture nen ncessitent
pas. Finalement, il peut galement contenir un code dtecteur et correcteur derreurs repr-
sent sur la figure par le champ ECRC (pour End-to-end CRC). La couche liaison de donnes
78
4.1. IronHide : outil dinjection de fautes sur les bus dentres-sorties
Logique du
Donnes
contrleur
Couche Transaction Layer Packet (TLP) En-tte Donnes ECRC

Transaction
Couche Data Link Layer Numro de

Liaison de donnes Packet (DLLP) squence En-tte Donnes ECRC LCRC
Couche Numro de
Trame squence En-tte Donnes ECRC LCRC Trame
Physique
Couches protocolaires Format des paquets
F IGURE 4.1 Couches protocolaires PCI Express
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.
4.1.1.2 Classes de transactions PCI Express
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
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
TABLE 4.1 Transactions PCI Express
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).
4.1.1.3 Format dun Transaction Layer Packet

Un TLP se compose au minimum dun en-tte et contient optionellement des donnes et un
ECRC. La taille de cet en-tte est variable : il stend sur 12 octets ou sur 16 octets en fonction du
type de transaction. Dans la suite, nous dtaillons uniquement la partie qui leur est commune.
Le lecteur est invit se rfrer aux spcifications du standard PCI Express [Budruk et al. 03]
pour la smantique des champs spcifiques chaque type de transaction. La figure 4.2 repr-
sente un exemple de TLP. Les champs griss (marqus dun R) reprsentent des champs rser-
vs. Le standard PCI Express impose quils soient positionns zro lors de la construction
dun TLP et quils soient ignors par le contrleur dentres-sorties en rception.
+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
End Cyclic Redundancy Checking (ECRC)
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
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.
4.1.2 Contrleur dentres-sorties IronHide

Dans loptique didentifier, puis de classifier les actions malveillantes quun attaquant peut
effectuer avec un contrleur, nous avons mis au point notre propre contrleur dentres-sorties
en utilisant les technologies de logique programmable. Nous avons appel notre prototype
IronHide. Il se prsente comme un contrleur dentres-sorties classique et se connecte direc-
tement au bus PCI Express. Dans la suite, nous prsentons les caractristiques qui font sa sin-
gularit par rapport dautres contrleurs dentres-sorties bass sur des FPGA.
4.1.2.1 Caractristiques principales
Il existe aujourdhui un certain nombre de contrleurs dentres-sorties ddis lvalua-

tion de la scurit des systmes informatiques qui sont implments partir de technologies de
logique programmable tels que les FPGA [Carrier et Grand 04, Petroni et al. 04, Devine et Vissian 09,
Aumaitre et Devine 10]. Malheureusement, tous ces contrleurs se prsentent comme des cartes
dextension PCI que lon connecte aux chipsets actuels par le biais de connecteurs PCI ou PC
Card disponibles sur la carte-mre. Les protocoles de bus PCI et PCI Express tant physique-
ment incompatibles, ces contrleurs ncessitent lutilisation dun pont PCI Express-PCI intgr
au chipset pour se connecter aux bus dentres-sorties PCI Express. tant donn que nous ne
matrisons pas la manire selon laquelle les requtes PCI sont traduites sur les bus dentres-
sorties PCI Express au niveau de ce pont, le fait de rutiliser un de ces contrleurs ne nous a
pas paru une solution adapte pour tudier de faon exhaustive les attaques depuis les contr-
leurs dentres-sorties. Aussi avons-nous dcid de dvelopper notre propre contrleur pour
quil puisse se connecter directement aux bus PCI Express via un connecteur PCI Express ou
Express Card.
Avec comme objectif de couvrir au maximum les vecteurs dattaques possibles depuis les
contrleurs dentres-sorties, nous avons conu notre contrleur afin quil puisse gnrer des
requtes quelconques sur les bus PCI Express. Lmission de requtes valides va alors nous
permettre de vrifier limplmentation du standard PCI Express par les autres contrleurs
30
Prcisons que pour effectuer des accs aux adresses localises au del de 4 gigaoctets, les contrleurs doivent gn-
rer des transactions dans le format 64 bits. Le champ Address dans le TLP stend alors sur 8 octets.
81
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.
4.1.2.2 Architecture interne

La figure 4.3 prsente larchitecture interne de notre contrleur, base sur la famille de
FPGA Xilinx. Puisque ce contrleur a pour vocation de tester les ventuelles fautes dinter-
action entre contrleurs, il nous est indispensable de pouvoir envoyer des paquets PCI Express
quelconques depuis la couche protocolaire transaction. Pour cela, nous avons utilis lIP Core
Xilinx LogiCORE IP Endpoint Block Plus for PCI Express [Xilinx 11b] qui permet, entre autres, de
configurer le bloc PCI Express inclus nativement dans le FPGA et fournit une interface pour
mettre ou recevoir des TLP PCI Express. Nous avons ensuite interfac cette unit logique avec
un systme embarqu compos dun processeur, de diffrentes mmoires, dun contrleur din-
terruptions et, optionnellement, de plusieurs contrleurs de priphriques (par exemple, des
contrleurs Ethernet, des contrleurs srie RS-232). Ce systme embarqu constitue la logique
du contrleur.
Il existe deux manires pour interconnecter lIP Core PCI Express avec notre systme embar-
qu. La premire mthode consiste utiliser une autre unit logique commercialise par Xilinx,
appele Xilinx LogiCORE IP PLBv46 RC/EP Bridge for PCI Express [Xilinx 10a], unit logique
payante implmentant entirement le protocole PCI Express. Elle est capable de traiter auto-
matiquement les TLP reus depuis linterface PCI Express et fournit une interface pour mettre
quelques requtes dentres-sorties prdfinies (par exemple, des requtes daccs lespace
dadressage principal de la mmoire pour le mcanisme daccs direct la mmoire). Cette
interface est cependant trs peu flexible et ne permet pas de gnrer des requtes dentres-
sorties quelconques (en particulier, celles avec un format invalide). Nous avons donc opt pour
limplmentation dune interconnexion spcifique entre les deux composants, ce qui nous a
conduits dvelopper notre propre IP Core. Notre unit logique se prsente comme un contr-
leur de bus PCI Express que lon peut connecter un bus PLBv46 interne la carte FPGA. Elle
offre une interface pour mettre ou recevoir des paquets quelconques sur les bus PCI Express.
Ces derniers sont stocks temporairement dans une mmoire partage.
Le processeur intgr dans le systme embarqu constitue le cur de notre contrleur
et nous permet dobtenir les proprits de modularit et de polyvalence voulues pour notre
contrleur. Le logiciel quil excute traite les diffrents vnements des contrleurs de pri-
phriques que nous avons configurs dans le FPGA. Il se charge en particulier de traiter les
paquets reus par lunit logique PCI Express et implmente partiellement le protocole PCI
Express. Concrtement, lorsquun paquet est reu depuis les bus PCI Express, le pont PCIe
vers PLBv46 le stocke temporairement dans une mmoire partage avec le processeur et d-
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
Pont PCIe vers Priphriques IP Core optionnel

Couche Contrleur mmoire
Couches PLBv46 divers
protocolaires Transaction
PCI Express
implmentes
avec l'IP Core Couche Xilinx Logicore IP Endpoint
Block Plus for PCIe Bus mmoire Bus divers
Xilinx Logicore Liaison de donnes
IP Endpoint Block
Plus for PCIe Bus PCIe
Couche
Physique
DDR-2 USB RS-232 Ethernet
Architecture en couches Architecture matrielle
F IGURE 4.3 Architecture de notre contrleur dentres-sorties IronHide
83
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.
De la mme faon que les contrleurs dentres-sorties malveillants construits partir de

FPGA, le contrleur IronHide peut tre utilis pour mettre en uvre diffrentes attaques par
entres-sorties 31 . Nous lavons utilis, par exemple, pour dvelopper plusieurs preuves de
concept qui ont t prsentes lors de la confrence SSTIC [Lone Sang et al. 12b]. En compl-
ment des travaux dcrits dans ce chapitre, le lecteur intress pourra consulter lannexe C qui
dtaille plusieurs attaques utilisant le contrleur IronHide ainsi que les rsultats obtenus. Ce-
pendant, le caractre polyvalent de notre contrleur dentres-sorties nous permet denvisager
dautres cas dutilisation pour celui-ci : injection de fautes, mulation de contrleur dentres-
sorties, etc. Nous allons nous en servir principalement en tant quoutil dinjection de fautes sur
les bus dentres-sorties. Afin dautomatiser ces injections de fautes, nous mettons en uvre du
fuzzing. Il sagit dune technique de test largement utilise dans la recherche de vulnrabilits
31
En toute rigueur, IronHide ne devrait pas tre considr comme un outil dattaque. Du point de vue dun attaquant,
il devrait plutt tre considr comme un moyen de dcouvrir et de prparer des attaques par entres-sorties.
Les attaques russies pourraient ensuite tre implmentes, par exemple, dans des quipements contrefaits dans
lesquels lattaquant installerait un cheval de Troie et quil vendrait des prix attractifs.
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.
4.2 lments de fuzzing

Ces vingt dernires annes, le fuzzing sest impos comme une technique de test intres-
sante pour rvler des vulnrabilits dans les implmentations de systmes logiciels. Les ori-
gines du fuzzing 32 sont quelque peu anecdotiques. Lors dune nuit dorage, B. Miller (consi-
dr comme le pre du fuzzing) tenta de se connecter un systme distant au travers dune
connexion modem et dexcuter sur celui-ci plusieurs programmes. Les perturbations sur les
lignes tlphoniques dues lorage ont provoqu la rception de caractres alatoires sur le
terminal distant au lieu des caractres saisis. Il constata alors que ces caractres alatoires, dans
la majorit des cas, provoquaient des erreurs dans les programmes utiliss. Cette dcouverte a
donn naissance cette technique de test qui a fait lobjet, en automne 1988, de plusieurs pro-
jets dtudiants luniversit Winconsin Madison. Lobjectif de ces travaux tait de tester la
robustesse des programmes de systmes dexploitation de type Unix vis--vis dentres inva-
lides gnres alatoirement. Les rsultats de ces travaux ont t publis pour la premire fois
dans [Miller et al. 90]. La prsente section commence par rappeler les principes de cette tech-
nique de test. Nous prsentons ensuite les diffrentes phases qui la constituent et les mthodes
utilises pour slectionner les entres de test. La section 4.3 traitera des lments spcifiques
la mise en uvre de cette technique de test aux bus dentres-sorties.
4.2.1 Principes du fuzzing

Bien que les concepts sous-jacents au fuzzing soient relativement simples, il nexiste pas
dans la littrature de dfinition qui soit universellement admise. Nous prenons comme rf-
rence celle qui a t propose par P. Oehlert [Oehlert 05] : fuzzing is a highly automated testing
technique that covers numerous boundary cases using invalid data (from files, network protocols, API
calls, and other targets) as application input to better ensure the absence of exploitable vulnerabilities .
Ainsi, le fuzzing dsigne avant tout une technique de test fonctionnel. Il se distingue ce-
pendant des autres techniques par les objectifs quil vise : le test des fonctions est marginal,
lobjectif prdominant tant daboutir rapidement la dcouverte de vulnrabilits. Il consiste
ensuite injecter des fautes au niveau des entres du systme et observer ses sorties dans le
but de dtecter des ventuelles erreurs. Les entres de test sont slectionnes de faon cou-
vrir au maximum les cas limites. Il sagit, dans la plupart des cas, dune technique de test en
bote noire car aucune connaissance de la structure interne du systme nest a priori ncessaire.
La slection des entres de test peut cependant tre amliore par une connaissance du com-
portement interne du systme [Ganesh et al. 09, Godefroid et al. 12]. Dans ce cas, nous parlons
plutt dapproche en bote grise. Finalement, le fuzzing est une technique de test dans laquelle
le dpouillement des rsultats est (en partie) automatis. La mise en uvre de ce processus
repose sur des outils, des scripts, des applications ou des plates-formes de test que nous appe-
lons fuzzers. Nous distinguons deux types de fuzzers : ceux qui se basent sur des techniques de
mutation et ceux qui reposent sur la synthse. Les fuzzers par mutation crent des entres de
test partir dchantillons dentres relles du systme sous test auxquelles ils appliquent des
transformations. Pour cette raison, ils ne ncessitent pas la connaissance au pralable du for-
32
Le terme fuzzing est issu de la contraction des termes anglo-saxon fuzzy (littralement, flou) et testing.
85
mat de ces entres. A contrario, les fuzzers par synthse construisent des entres de test partir
dune modlisation de ces entres.
4.2.2 Phases du fuzzing

Quel que soit le systme auquel nous nous intressons, il est possible de distinguer plu-
sieurs phases dans la mise en uvre du fuzzing. Cette sous-section les dcrit succinctement.
1. Identification du systme sous test. Avant de mettre en uvre une technique de test quel-
conque, il est important de dfinir le systme sur lequel les tests vont porter. Cette tape
prliminaire permet gnralement didentifier les diffrentes approches qui peuvent tre
adoptes pour effectuer du fuzzing sur le systme sous test.
2. Identification des entres du systme. Une fois le systme sous test dfini, une seconde tape
consiste numrer lensemble de ses interfaces de service et en slectionner quelques
unes pour interagir avec le systme. Il est alors ncessaire didentifier le format de leurs
entres ainsi que les lments dans ces entres qui, une fois modifis, provoquent po-
tentiellement des fautes dans le systme sous test.
3. Slection des entres de test. Le test exhaustif est gnralement impossible et il est nces-
saire de slectionner de manire pertinente un sous-ensemble du domaine dentre qui
permette de couvrir lensemble des parties du systme que lon souhaite tester. En fonc-
tion de la connaissance du systme sous test, il est possible de slectionner les entres
de test de diffrentes manires. Elles sont discutes dans la sous-section 4.2.3.
4. Excution des entres de test. Ltape qui suit la slection des entres de test est lexcution
de ces entres. Elle consiste soumettre au systme sous test ces entres en esprant
quun certain nombre dentre elles dclenchent une erreur lors de leur excution.
5. Analyse des ventuelles erreurs. Enfin, lorsque nous observons des erreurs, il est essentiel
de les analyser et didentifier leurs causes afin de proposer des correctifs ou au contraire
pour tenter de les exploiter.
Dans la sous-section suivante, nous nous intressons plus particulirement aux diffrentes
approches qui peuvent tre mises en uvre dans un fuzzer pour slectionner des entres de
test.
4.2.3 Mthodes de fuzzing

La classification en fuzzers bass sur la mutation et en fuzzers bass sur la synthse dentres
de test peut tre raffine son tour en plusieurs mthodes [Sutton et al. 07] qui sont prsentes
dans cette sous-section.
4.2.3.1 Gnration dentres de test prdfinies

Les fonctions dun systme sont gnralement dcrites dans un document de rfrence qui
peut tre un cahier des charges ou, plus couramment, un document de spcification. Afin de
vrifier la conformit du systme aux exigences, ce document contient souvent un jeu dentres
de test qui permet de vrifier toutes les conditions de fonctionnement du systme. Il sagit l
dune premire faon de slectionner des entres de test. La mise en uvre de cette mthode
exige un travail considrable en amont, notamment pour intgrer les entres de test au fuz-
zer. Elle prsente lavantage de pouvoir tre utilise de faon uniforme pour vrifier plusieurs
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.
4.2.3.2 Gnration dentres de test alatoires
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.
4.2.3.3 Mutation dentres de test
La mutation dentres de test ncessite au pralable la capture dune ou plusieurs entres

valides. Celles-ci sont utilises comme entres de rfrence partir desquelles sont produites
de nouvelles entres de test qui sont obtenues par plusieurs transformations successives. Les
inversions de bits (en anglais, bit-flips), la substitution de valeurs et linsertion de donnes ala-
toires sont quelques exemples de transformations qui sont couramment effectues. La muta-
tion peut tre opre de faon manuelle. Un oprateur humain se charge alors deffectuer les
transformations sur lentre de rfrence. Cette approche est particulirement adapte pour des
systmes de petite taille et pour des tests fonctionnels rapides. La mutation peut galement tre
automatique [Crouzet et al. 06]. Un algorithme est alors charg dappliquer les transformations
la place de loprateur humain. tant donn que cette mthode de slection dentres de test
repose sur des entres de test valides et que les transformations sur celles-ci sont opres au-
tomatiquement, cette mthode est gnralement plus efficace que celles qui ont t prcdem-
ment voques. Elle ne sadapte cependant pas tout type dentres, en particulier lorsquil
existe une corrlation entre plusieurs de ses lments (par exemple, un condensat, un CRC,
etc.).
87
4.2.3.4 Synthse dentres de test partir dun modle

La synthse dentres de test partir dun modle est la mthode qui prsente le plus
davantages. Elle consiste gnrer un jeu dentres de test partir dun modle des entres du
systme. Il sagit galement de la mthode qui exige le plus de travail de prparation. En effet,
un travail de recherche est ncessaire au pralable pour comprendre la structure des entres du
systme. Celle-ci est ensuite dcrite selon une grammaire afin de rendre automatisable la g-
nration des entres de test. Au cours de cette phase, lanalyste identifie les parties des entres
qui doivent rester statiques, celles qui sont susceptibles de varier et les ventuelles relations
qui les lient. Le fuzzer analyse alors le modle tabli, gnre des entres de test et les fournit au
systme sous test. Il convient de prciser que le succs de cette mthode dpend de la capacit
de lanalyste identifier les lments dans les entres qui sont susceptibles de conduire des
erreurs.
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.
4.3 Mise en uvre du fuzzing sur les bus dentres-sorties

Un grand nombre de fuzzers peuvent tre identifis dans la littrature. La plupart dentre
eux sont spcifiques un type de systmes sous test particulier (par exemple, des programmes,
des protocoles, des bibliothques de fonctions, etc.). Il existe cependant des fuzzers plus ou
moins gnriques, tel que Peach [Eddington 12], qui peuvent tre utiliss pour diffrents types
de systmes. Malheureusement, aucun deux ne nous satisfait pleinement pour notre tude. En
effet, certains outils intressants ne sont plus jour et la prise en main dautres outils est parfois
difficile. Aussi, avons-nous dcid de crer notre propre fuzzer. Nous introduisons brivement
son architecture et nous prcisons quelques lements sur son implmentation avant de discuter
des rsultats des exprimentations que nous avons menes sur plusieurs chipsets Intel.
4.3.1 Architecture du fuzzer

La figure 4.4 prsente larchitecture du fuzzer que nous avons mis en place pour notre tude.
Il se compose de plusieurs lments : un slecteur dentres de test, un contrleur de tests, un
outil dinjection de fautes sur les bus dentres-sorties, un oracle et plusieurs agents. Cette sous-
section dtaille le rle de chacun de ses lments.
Le slecteur dentres de test est une des parties les plus importantes du fuzzer. Il se charge
de crer lensemble des entres de test que le contrleur de tests va soumettre au systme sous
test. Le contrleur de tests est galement un lment important car il permet dautomatiser
lexcution des entres de test. cet effet, il transmet squentiellement chaque entre de test
excuter loutil dinjection de fautes (dans notre cas, il sagit du contrleur dentres-sorties
IronHide) et envoie galement loracle le rsultat attendu pour ce test afin que celui-ci puisse
prononcer son verdict sur le test excut. Ce verdict se base sur la comparaison de la rponse
attendue, fournie par le contrleur de tests, la rponse renvoye par le systme sous test. Lors-
quun verdict est impossible laide de ces deux lments, loracle peut saider dinformations
complmentaires fournies par les diffrents agents dploys sur le systme sous test. nou-
veau, si un verdict nest toujours pas possible, loracle le signale un oprateur humain pour
88
4.3. Mise en uvre du fuzzing sur les bus dentres-sorties
fournisent des informations complmentaires
Agents fournit les rsultats obtenus Oracle

fournit un rsultat aendu
analysent
les composants soumet une entre de test Contrleur
matriels et d'entres de test
logiciels
produit des entres de test
Composants Slecteur
matriels & logiciels Injecteur de fautes
d'entres de test
F IGURE 4.4 Architecture du fuzzer
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
alors de sassurer que les implmentations de contrleurs dentres-sorties actuelles

ignorent effectivement ces champs en y injectant des valeurs non nulles lmission
dun TLP.
le champ EP : ce champ dans len-tte du TLP permet dindiquer que le TLP a t
empoisonn et quil nest pas valide. la rception dun tel paquet, un contrleur
est cens ignorer le paquet. Il convient alors de sassurer que le TLP est rellement
ignor lorsque ce champ est positionn.
le champ TD : ce bit TD indique si le TLP contient un ECRC. La taille du paquet total
est alors calcule laide de la longueur des donnes annonce dans le paquet auquel
se rajoutent la taille de len-tte et la taille de lECRC. Positionner ce champ alors que
le paquet ne contient pas dECRC peut ventuellement provoquer des effets de bord.
le champ Length : ce champ indique la quantit de donnes transportes dans le
TLP. Des dbordements de tampons peuvent survenir, par exemple, lorsque la lon-
gueur annonce dans le paquet est plus faible que les donnes rellement envoyes.
le champ Address : les spcifications des bus PCI Express requirent que les accs
dentres-sorties se fassent par pages (4096 octets). Par exemple, la lecture de 4096
octets de donnes partir de ladresse 0x0ff0 ncessite au minimum deux accs :
un premier de 16 octets vers ladresse 0x0ff0 (correspondant la premire page),
puis un second vers ladresse 0x1000 pour les 4080 octets restants.
3. Entres de test alatoires. Le format de certaines parties des TLP nest pas connu. Cest
le cas typiquement de certains TLP de type message. Certains champs sont laisss la
discrtion du constructeur pour vhiculer, par exemple, des messages de gestion dner-
gie ou des erreurs spcifiques leur plate-forme. Pour ces champs dont la smantique
nest pas connue, la gnration alatoire des entres de test peut tre intressante. Lide
est alors daffecter ces champs des valeurs alatoires afin de rvler, par exemple, un
bogue matriel ou une fonctionnalit cache.
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.
4.3.2 Exprimentations et rsultats

La figure 4.5 prsente lenvironnement que nous avons mis en place pour nos exprimen-
tations. Les diffrents composants qui constituent le fuzzer ont t rpartis sur deux machines
qui jouent respectivement le rle dune cible et dun moniteur. Schmatiquement, la machine
cible reprsente la machine sous test pour laquelle nous souhaitons tudier le comportement
du chipset en rponse des requtes dentres-sorties diverses. Elle contient loutil dinjection
de fautes et plusieurs agents. La machine moniteur correspond lentit qui contrle lexcution
des entres de test. Elle se charge de dfinir les entres de test, de les soumettre la machine
cible et de vrifier leurs rsultats. Elle contient galement les principaux composants du fuzzer.
Le contrleur de tests rcupre les entres gnres par le slecteur dentres de test et les
soumet loutil dinjection de fautes au travers du rseau qui est connect au systme sous test
par un bus PCI Express. Nous lavons programm pour servir de serveur mandataire (proxy)
34
Dans le cas dune carte rseau, ces fonctionnalits spcifiques peuvent correspondre, par exemple, lmission ou
la rception de trames sur le rseau, aux transferts de ces trames entre la carte rseau et la mmoire centrale, etc.
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
F IGURE 4.5 Plate-forme exprimentale
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
Chipset Northbridge Southbridge Modle de machine

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 4.2 Liste des chipsets expriments
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
Address Type (AT) - dtect - dtect

Length DoS dtect - dtect
champs rservs - dtect - dtect
Requester ID DoS dtect DoS dtect
Tag - - - -
Last DW Byte Enable (LDBE) DoS dtect DoS dtect
Memory et I/O
First DW Byte Enable (FDBE) DoS dtect DoS dtect
Address - - - -
champs rservs - dtect - dtect
Requester ID non-applicable non-applicable non-applicable non-applicable
Tag non-applicable non-applicable non-applicable non-applicable
Last DW Byte Enable non-applicable non-applicable non-applicable non-applicable
First DW Byte Enable non-applicable non-applicable non-applicable non-applicable
Configuration
Address non-applicable non-applicable non-applicable non-applicable
champs rservs non-applicable non-applicable non-applicable non-applicable
Completer ID non-applicable non-applicable non-applicable non-applicable
Register Number non-applicable non-applicable non-applicable non-applicable
Requester ID DoS dtct DoS dtect
Tag - - - -
Message
Message Code - - - -
champs spcifiques - - - -
TABLE 4.3 Quelques rsultats exprimentaux
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
recommandations pour se protger dattaques qui en abuseraient.

Finalement, notre seconde approche (cf. chapitre 4) complte la premire en permettant de
couvrir, de manire automatise et systmatique, davantage dattaques par entres-sorties sans
requrir une pr-connaissance pointue du systme informatique valu. En nous inspirant des
techniques de test et de recherche de vulnrabilits dans les systmes logiciels, nous avons es-
say dadapter les techniques de fuzzing des systmes matriels. cet effet, nous avons mis
au point un contrleur dentres-sorties spcifique en utilisant les technologies de logique pro-
grammable. Il se distingue des contrleurs FPGA existants de par le fait quil est entirement
programmable et quil est capable de gnrer tout type de trame sur les bus dentres-sorties.
Notre prototype, baptis IronHide, nous a permis dobtenir les mmes pouvoirs quun atta-
quant installant une porte drobe dans un contrleur dentres-sorties quil conoit ou dans
lequel il a dcouvert une vulnrabilit le lui permettant [Lone Sang et al. 12b]. Lanalyse des
premiers rsultats que nous avons obtenus par cette approche nous permet dores et dj de
conclure que de nombreuses plates-formes matrielles compatibles PC (notamment, les chipsets
Intel davant 2009) ne sont pas tolrantes aux fautes injectes depuis les bus dentres-sorties.
Lintgration de contre-mesures supplmentaires, notamment lAdvanced Error Reporting, dans
les plates-formes matrielles plus rcentes semblent montrer une relle volont, de la part des
fabricants de chipsets, de prendre en considration des attaques par entres-sorties.
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.
2.1 Formalisation mathmatique du modle dattaques propos

Au chapitre 2, nous avons commenc formaliser mathmatiquement le concept dattaque.
Nous avons considr une attaque comme une squence dactions lmentaires dont certaines
composantes, les attaques lmentaires, sont malveillantes. Il serait intressant de complter
ce travail de formalisation (et dinclure, par exemple, la notion dentrelacement dactions l-
mentaires, de pr- et post-condition, etc.) puis de ltendre notre modle dattaques. Cela
nous permettrait alors de construire puis didentifier, de faon non-ambigu mais surtout sys-
tmatique, lensemble des attaques possibles pour un systme informatique quelconque. Les
concepteurs de systmes pourraient galement intgrer ce modle formel au cycle de dvelop-
pement de leurs systmes et le mettre en uvre ds ltape de spcification afin de dtecter au
plus tt les ventuelles squences dattaque et de les corriger efficacement.
2.2 tude des attaques par entres-sorties pour dautres systmes

Afin de rduire les cots de dveloppement de systmes informatiques, les industriels uti-
lisent de plus en plus de composants sur tagre, mme pour des applications plus ou moins
critiques. Dans le contexte actuel de forte mondialisation, les composants logiciels et matriels
qui constituent ces systmes sont rarement produits par une seule et mme entit : les compo-
sants matriels peuvent tre assembls dans un pays, et les logiciels dvelopps par un autre
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.
2.3 Dtection et prvention des attaques par entres-sorties

Jusqu prsent, nous avons discut uniquement des utilisations offensives de notre contr-
leur dentres-sorties IronHide (cf. chapitre 4). tant donn que le comportement de notre pro-
totype peut entirement tre modifi simplement par un firmware, nous avons galement envi-
sag de lutiliser comme un composant de scurit. En particulier, il pourrait constituer un ou-
til de dtection (et ventuellement de prvention) dintrusions spcifiques aux entres-sorties.
Ceci est particulirement important vis--vis des attaques par entres-sorties, puisquelles sont
trs difficilement dtectables par logiciel, dans la mesure o elles ne font gnralement inter-
venir ni le processeur, ni la mmoire centrale.
En raison de la complexit et de la nature htroclite des attaques par entres-sorties, lap-
proche de dtection par analyse comportementale semble tre la plus approprie. Hormis les
difficults techniques pour la mise en uvre dun tel outil, un des dfis scientifiques majeurs
relever consistera tablir une mtrique qui permettrait, dune part, dlaborer un modle
de comportement stable des contrleurs dentres-sorties et qui, dautre part, distinguerait de
manire efficace les comportements dviants (correspondant ventuellement des attaques)
des comportements lgitimes. cet gard, nous pourrions fortement nous inspirer des travaux
issus du domaine de la dtection dintrusions dans les rseaux, dans lequel cette problmatique
est rcurrente.
Finalement, une fois lattaque dtecte, se pose le problme de savoir comment riposter.
Il pourrait alors tre envisag dimposer une politique de scurit prventive et de bloquer
systmatiquement tout comportement jug anormal. La modification de lensemble des pilotes
de contrleurs dentres-sorties et de priphriques serait alors invitable, afin de les rendre
tolrants aux fautes qui peuvent y tre introduites par une telle politique de scurit. Une
autre approche, moins drastique, consisterait simplement informer le systme dexploitation
qui prendrait alors les mesures ncessaires contre le contrleur suppos malveillant, comme le
dsactiver compltement par exemple.
98
Annexe A
Preuve de concept dattaque par partage

didentifiants PCI Express
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.
A.1 Description de notre plate-forme exprimentale
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
F IGURE A.1 Plate-forme exprimentale considre
A.2 Injection des donnes dans une carte Ethernet
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
A.2.0.1 Le tampon de rception dans la carte Ethernet VIA Rhine VT6102.

La carte VIA Rhine VT6102 utilise un tampon circulaire pour stocker temporairement les
donnes reues depuis le rseau. Une mmoire tampon est utilise pour chaque trame reue.
Cette mmoire tampon est libre ds que le systme dexploitation la traite. En mmoire
centrale, la zone des mmoires tampons de rception est reprsente par une liste circulaire
de descripteurs de trame (figure A.2). Un descripteur de trame est dfini comme une structure
de donnes de 16 octets dont le rle est de dcrire une mmoire tampon o va tre stocke
temporairement une trame Ethernet. Elle se compose de quatre champs. Le champ adresse
indique o se situe, dans lespace dadressage physique, la mmoire tampon dcrite par ce
descripteur. Le champ statut dcrit ltat de ce tampon. Il informe, par exemple, le systme
dexploitation si la mmoire tampon contient une trame ou non, si celle-ci est valide ou si elle
contient des erreurs, etc. Le champ longueur donne la taille des donnes stockes. Finalement,
le champ descripteur chane le descripteur de trame courant son suivant. Notons que
lallocation de la liste de descripteurs de trame ainsi que des mmoires tampons associes est
effectue par le noyau du systme dexploitation.
descripteur #0 descripteur #k descripteur #n
statut statut statut
longueur longueur longueur
adresse adresse adresse
descripteur descripteur descripteur
tampon tampon tampon

de de de
rception rception rception
#0 #k #n
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
A.2.0.2 Injecter des trames Ethernet par DMA.

Notre ide, dans cette attaque, est de nous aider de la carte FireWire prsente sur la machine
de Bob pour injecter des trames Ethernet malveillantes en mmoire centrale, directement dans
le tampon de rception de sa carte rseau. Nous allons donc imiter le fonctionnement de la
carte rseau lors de la rception de trames Ethernet.
Dans cette optique, lattaquant commence par (1) injecter des donnes dans la rgion de la
mmoire centrale utilise par la carte Ethernet. (2) Il modifie ensuite les descripteurs de trame
associs aux mmoires tampons altres afin quils dcrivent des donnes cohrentes en m-
moire. (3) Finalement, il attend que le systme dexploitation de Bob traite les trames injectes.
Typiquement, ces trames sont traites la rception dune interruption matrielle issue de la
carte rseau. Une interruption est gnre, par exemple, aprs rception dune nouvelle trame
Ethernet.
Le mode opratoire que nous dcrivons ici est appliqu pour la corruption du cache ARP
de la machine appartenant Bob. Nous prsentons ci-aprs les rsultats obtenus.
A.3 Application la corruption de cache ARP

Dans un rseau Ethernet, chaque station dispose dun identifiant physique unique corres-
pondant ladresse MAC (Media Access Control) de sa carte rseau. cet adressage physique
sajoute un adressage logique : chaque carte rseau dispose dune adresse IP (Internet Protocol)
sur laquelle repose toutes les communications. Le protocole ARP (Address Resolution Protocol)
est un protocole de type requte-rponse qui associe dynamiquement une adresse MAC une
adresse IP.
la rception dune requte ARP (ARP-REQUEST), une station met jour automatiquement
son cache ARP. Il est alors possible de modifier des entres dans la table ARP dune machine
simplement en lui envoyant des requtes ARP-REQUEST. Prcisons quil est galement possible
dobtenir les mmes rsultats en envoyant des rponses ARP-REPLY, mais cette mthode est
moins efficace 35 . Dans le cadre dattaques de type ARP-poisoning, ces rponses font videm-
ment correspondre une adresse MAC errone une adresse IP donne.
Rappelons quve souhaite prtendre tre Alice aux yeux de Bob afin dcouter leur conver-
sation. Pour cela, elle modifie lentre, dans le cache ARP de la machine de Bob, qui fait cor-
respondre ladresse IP dAlice son adresse MAC. La modification de cette entre repose sur
lexploitation de la vulnrabilit matrielle dcouverte plus tt. Afin dtre sre de son coup,
ve met en place, tout dabord, lattaque sur sa propre machine, puis la rejoue sur la machine de
Bob. Comme les machines sont identiques, elle est sre que le rejeu de lattaque sur la machine
de Bob donnera les mmes rsultats.
titre indicatif, nous donnons ci-dessous le contenu initial du cache ARP de la machine de
Bob :
$> hostname
Bob
$> arp
Address HWtype HWaddress Flags Mask Iface
Alice ether 00:50:56:8a:3b:6b C eth0
Eve ether 00:90:27:6a:58:74 C eth0
Nous donnons ci-dessous le mode opratoire suivi par ve lors de lattaque :

35
Un IDS pourrait, par exemple, facilement dtecter quune ARP-REPLY ne correspond aucune requte ARP-
REQUEST.
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
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
Preuve de concept dattaque par accs

pair--pair sur une carte graphique
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.
B.1 Architecture dune carte graphique

La figure B.1 prsente une vue simplifie de larchitecture dune carte graphique. La connais-
sance des lments qui la constituent permet de mieux apprhender le scnario dattaque que
nous dtaillons dans la suite.
Processeur
Mmoire interne
du contrleur
Moniteur graphique
RAM
Mmoire
Digital
Vido
Analog
(Framebu er)
Converter
BIOS
Vido
Graphic
Processing Registres
Unit
F IGURE B.1 Architecture simplifie dune carte graphique
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 :
La mmoire de la carte. La mmoire embarque dans la carte graphique a diffrentes fonc-

tions. Elle se dcoupe en plusieurs rgions de mmoire parmi lesquelles :
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.
B.2 Scnario dattaque considr

Dans notre scnario dattaque, nous considrons deux acteurs : une victime, que nous
nommons dans la suite Bob, et un attaquant, que nous appelons ve. Nous supposons que
la machine quutilise quotidiennement Bob possde un chipset sur lequel il est possible de
mettre en place des communications peer-to-peer. Nous faisons galement lhypothse quve
a la matrise dun contrleur dentre-sortie plac dans la machine de Bob, partir duquel elle
peut deffectuer des attaques DMA. Elle peut, par exemple, exploiter une vulnrabilit dans
la carte rseau [Duflot et al. 10] prsente dans la machine de Bob et y placer un rootkit comme
prsent dans [Triulzi 08a, Triulzi 10b, Delugr 10]. Pour rendre lattaque plus simple, nous
considrons quve commande le contrleur FireWire prsent dans la machine de Bob grce
un priphrique qui lui est connect (par exemple, un iPod modifi ou un ordinateur por-
table). Plusieurs articles rcents ont montr que ceci est bien ralisable en pratique supposi-
tion [Dornseif 04, Becher et al. 05, Boileau 06]. Nous rappelons quun contrleur FireWire au-
torise les priphriques qui lui sont connects fournir les adresses physiques vers lesquelles
effectuer les accs DMA. Cette hypothse implique donc quve possde un accs physique
la machine de Bob. Grce cet accs physique (ici, un port FireWire), ve connecte son ordi-
nateur portable la machine de Bob pour piloter le contrleur FireWire. Elle exploite ensuite
cet accs pour manipuler la mmoire vido de la carte graphique de Bob. La preuve de concept
que nous avons conue montre quve peut dans cette situation lire la mmoire vido. Dans
cet exemple, nous utilisons la lecture de la mmoire vido de Bob pour afficher distance le
contenu de lcran de Bob sur lcran dve. Nous aurions pu de la mme faon modifier ce
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
F IGURE B.2 Scnario dattaque
B.3 Rsultats obtenus

Nous avons dvelopp cette attaque en utilisant comme machine cible (Bob) une machine
de type desktop disposant dune carte-mre Intel DX58SO, laquelle embarque un chipset Intel
x58 (plus prcisment, IOH x58 / ICH10). Elle dispose aussi dune carte graphique nVidia
GeForce 9800 GT et dun contrleur FireWire de type PCI. Cest ce contrleur FireWire qui, lors
de lattaque, sera pilot par la machine de lattaquant (ve), un ordinateur portable connect
sur le port FireWire. Nous reconstituons lcran de Bob raison de deux images par secondes.
Nous considrons cela tout--fait acceptable pour rcuprer des informations affiches lcran
(par exemple, un couple identifiant-mot de passe), mais insuffisant pour rcuprer un flux en
temps rel (par exemple, la capture dun flux vido).
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
Plusieurs exemples dexprimentations

avec le contrleur IronHide
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.
C.1 Description de la plate-forme dexprimentation

La figure C.1 prsente la plate-forme que nous avons utilise pour nos exprimentations.
Elle se compose principalement de deux machines qui jouent respectivement le rle dune cible
et dun moniteur. La machine cible reprsente la machine pour laquelle nous souhaitons tudier
le comportement du chipset en rponse des requtes dentres-sorties diverses. Ces requtes
dentres-sorties sont inities par notre contrleur qui est reli lun des connecteurs dexten-
sion PCI Express ou Express Card disponibles sur la carte-mre de la machine tudie. Nous
lavons programm pour servir de serveur mandataire (proxy) PCI Express pour la machine mo-
niteur : il met tous les paquets reus depuis linterface Ethernet en provenance de la machine
moniteur vers les bus PCI Express de la machine cible et renvoie vers la machine moniteur les
rponses ventuelles. Pour cela, le logiciel embarqu dans le contrleur implmente une pile
TCP/IP et contient un serveur TCP qui relaie les paquets entre la machine moniteur et les bus
dentres-sorties. Le contrleur est configur avec une adresse IP statique (192.168.1.10)
et le serveur TCP embarqu attend de nouvelles connexions sur le port 65535. Il est no-
ter 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 ou de la machine moniteur lors de nos exprimentations. Afin dviter toute ambi-
gut, nous prcisons que les adresses rseau que nous avons utilises sont propres au contr-
leur et ne sont pas lies aux ventuelles cartes rseau de la machine cible. Les trames reues par
le contrleur sont directement traites par sa pile TCP/IP interne et ne sont pas vues par le sys-
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.
F IGURE C.1 Plate-forme dexprimentation
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.
C.2 Rsultats exprimentaux

Dans cette section, nous dtaillons quelques exprimentations que nous avons menes avec
notre contrleur. Nous pouvons les classer parmi les attaques hybrides qui dtournent des
fonctionnalits lgitimes du matriel. Elles illustrent les possibilits dattaques par entres-
sorties qui soffrent un attaquant avec un tel contrleur.
C.2.1 coute sur les bus dentres-sorties

La premire exprimentation que nous avons mise en place avec notre contrleur consiste
effectuer de lcoute passive sur les bus dentres-sorties. Nous souhaitons identifier, par cette
exprience, les diffrentes interactions qui peuvent exister entre un contrleur quelconque et
les autres composants. Avant danalyser les rsultats obtenus, nous prcisons que les bus PCI
Express sont organiss de manire hirarchique, et que les diffrents contrleurs PCI Express
sont interconnects par des liaisons point--point. La notion de bus dentres-sorties est alors
purement logique, et les contrleurs en amont dans la hirarchie (gnralement des ponts
PCI Express) se chargent de commuter les paquets entre diffrentes liaisons point--point et
donnent ainsi lillusion dtre sur un bus physique. Par consquent, nous recevons, sur linter-
36
Nous pensons que notre extension peut ventuellement tre utilise dans un autre contexte. Aussi, nous prvoyons
de diffuser les codes-sources associs et une premire version sera disponible trs prochainement.
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>
F IGURE C.2 Dtection de notre contrleur par la machine cible
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.
user@moniteur$ sudo scapy

Welcome to Scapy (2.2.0)
>>> pkts = sniff(count=0, filter=tcp and src port 65535,
... prn=lambda p:TLP(str(p[TCP].payload)).show())
[...]
###[ MemoryRequest ]### ###[ MessageRequest ]###
fmt = 3DW HDR no data fmt = 4DW HDR with data
type = MRd32 type = MsgD
rsvd0 = 0x0L rsvd0 = 0x0L
tc = 0x0L tc = 0x0L
attr = 0x0L attr = 0x0L
th = 0x0L th = 0x0L
td = 0x0L td = 0x0L
ep = 0x0L ep = 0x0L
attr2 = 0x0L attr2 = 0x0L
at = 0x0L at = 0x0L
length = 1L length = 1L
reqID = 0:0.0 reqID = 0:0.0
tag = 0x18 tag = 0x0
ldbe = 0x0L msgcode = 0x7FL
fdbe = 0xfL bfdID = 0:0.0
address32 = 0xf1e00000L vendorID = 0x8086L
rsvd3 = 0x0L specific = 0x00000080L
data = )\x00\x00\x00
F IGURE C.3 Quelques exemples de requtes reues par notre contrleur
Nous remarquons que notre contrleur reoit deux types de transactions : des transactions
111
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.
C.2.2 Non-respect de la configuration matrielle

Pour quun contrleur sur tagre puisse effectuer des accs de type DMA, il est ncessaire
que le pilote qui lui est associ positionne le bit Bus Master Enable (BME) dans la configuration
du contrleur. Le respect (ou le non-respect) de cette configuration nengage malheureusement
que le contrleur. Nous avons voulu dterminer, par cette exprimentation, si un mcanisme
dans le chipset, en labsence dune I/O MMU, est en mesure de dtecter et de parer tout accs
frauduleux initi depuis un contrleur pralablement configur par le systme dexploitation
pour ne pas pouvoir initier, de lui mme, des accs la mmoire centrale. La figure C.4 prsente
les commandes excutes sur la machine cible pour dsactiver la fonctionnalit de bus-mastering
dans le contrleur.
user@cible$ lspci -v
[...]
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
[...]
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
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.
C.2.3 Usurpation didentit sur les bus dentres-sorties

Une des techniques pour passer au travers du contrle dune I/O MMU consiste usurper
lidentit dun autre contrleur. En effet, les technologies I/O MMU se basent uniquement sur
ladresse de bus fournie dans le paquet PCI Express (champ Requester ID) pour identifier le
contrleur lorigine de laccs. Il est alors possible de modifier un contrleur de faon ce quil
mette des paquets utilisant lidentifiant dun autre contrleur et dobtenir en consquence les
mmes droits daccs lespace dadressage principal de la mmoire que le contrleur cibl.
Par cette exprimentation, nous avons voulu identifier les limites pratiques quun attaquant
peut rencontrer avec un tel moyen dattaque. La figure C.5 prsente le type de requtes que
nous mettons sur les bus dentres-sorties grce notre contrleur. Il sagit dun accs en
criture lespace dadressage principal de la mmoire dans lequel nous usurpons lidentit
du contrleur mmoire situ dans le northbridge.
Dans cet exemple, nous avons volontairement effectu un accs invalide afin que lI/O MMU
le dtecte et le rapporte au systme dexploitation. Puisque le contrleur mmoire ne dispose
pas de tables de configuration qui lui sont associes, lI/O MMU considre cet accs comme
frauduleux et le bloque. Nous nous servons de cet accs invalide pour vrifier que nous avons
effectivement usurp lidentit du contrleur mmoire. La figure C.6 prsente un extrait des
journaux systmes rapportant cet accs frauduleux lespace dadressage principal de la m-
moire. Nous remarquons que lI/O MMU accuse tort le contrleur mmoire, dont lidentifiant
de bus est 00:00.0, comme tant lorigine de laccs frauduleux. Cet identifiant correspond
bien celui que nous avons usurp avec notre contrleur dentres-sorties.
Afin dtudier limpact dune usurpation didentit sur un bus dentres-sorties, nous avons
connect notre contrleur diffrents emplacements dans le chipset, puis nous avons gnr des
accs en lecture et en criture vers lespace dadressage mmoire principal en utilisant liden-
tit dautres contrleurs. Nous avons observ quun attaquant qui utilise cette technique pour
tromper le contrle daccs dune I/O MMU reste tout de mme restreint un nombre limit
dactions malveillantes. Il peut, par exemple, crire dans les rgions de mmoire pour lesquels
le contrleur dont on usurpe lidentit dispose de permissions daccs en criture. Il peut ga-
lement initier des accs en lecture aux rgions de mmoire pour lesquels le contrleur cibl
dispose de permissions daccs en lecture. En revanche, il ne recevra pas le paquet completion
en rponse sa requte daccs, celui-ci tant achemin par le chipset au contrleur dont on
a usurp lidentit. Cela sexplique par la manire dont les diverses transactions PCI Express
sont routes par le chipset. En effet, les transactions de type memory sont routes par le chipset en
fonction de ladresse laquelle on souhaite accder. En revanche, les ventuelles rponses asso-
113
user@moniteur$ sudo scapy

Welcome to Scapy (2.2.0)
>>> ip = IP(dst=192.168.1.10)
[...]
>>> tlp = MWr32(fmt=0x2, type=0x0, reqID=0:0.0,
... address32=0x0, data=\xde\xad\xbe\xef)
>>> tlp.show2()
###[ MemoryRequest ]###
fmt = 3DW HDR with data
type = MWr32
rsvd0 = 0x0L
tc = 0x0L
rsvd1 = 0x0L
attr = 0x0L
rsvd2 = 0x0L
th = 0x0L
td = 0x0L
ep = 0x0L
attr2 = 0x0L
at = 0x0L
length = 1L
reqID = 0:0.0
tag = 0x2
ldbe = 0x0L
fdbe = 0x1L
address32 = 0x0L
rsvd3 = 0x0L
data = \xde\xad\xbe\xef
>>> send(ip/TCP(dport=65535, sport=synack.dport,
... seq=synack.ack, ack=synack.seq+1)/tlp)
.
Sent 1 packets.
F IGURE C.5 Transaction MemoryWriteRequest avec un identifiant quelconque
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.
C.2.4 Enregistreur de frappe

Dans cette exprimentation, nous avons profit des fonctionnalits de notre contrleur pour
effectuer des accs vers lespace Port I/O. Nous rappelons quil est difficile de mettre en uvre
une telle exprimentation depuis des contrleurs dentres-sorties sur tagre, ces derniers
tant gnralement restreints aux requtes daccs lespace dadressage mmoire principal.
Nous avons observ des rsultats diffrents en fonction des chipsets sur lesquels nous avons
men nos exprimentations. Par exemple, sur les chipsets supportant les accs peer-to-peer, nous
avons russi faire une image de lespace Port I/O (cf. figure C.7). En revanche, sur les autres
114
user@cible$ dmesg | grep DMAR

[...]
DMAR:[DMA Write] Request device [00:00.0] fault addr 000000000
DMAR:[fault reason 05] PTE Write access is not set
F IGURE C.6 Exemple daccs frauduleux dtect par lI/O MMU
chipsets, le northbridge ou le southbridge rpondent explicitement que la transaction nest pas

supporte. En effet, ces derniers renvoient directement un paquet completion avec le statut de
transaction positionn Unsupported Request.
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
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
Lafayette (IN, USA), aot 1995. http://cwe.mitre.org/documents/sources/

ATaxonomyofSecurityFaultsintheUNIXOperatingSystem%5BAslam95%5D.
pdf.
[Aumaitre 08] Damien Aumaitre. Voyage au coeur de la mmoire. In Actes du 6e Symposium sur
la Scurit des Technologies de lInformation et des Communications (SSTIC 08), pages 378
437, Rennes (France). Ecole Suprieure et dApplication des Transmissions (ESAT), 4-6
juin 2008. http://actes.sstic.org/SSTIC08/Voyage_Coeur_Memoire/.
[Aumaitre et Devine 10] Damien Aumaitre et Christophe Devine. Virtdbg : Un dbogueur
noyau utilisant la technologie de virtualisation matrielle VT-x. In Actes du 8e Sym-
posium sur la Scurit des Technologies de lInformation et des Communications (SSTIC 10),
pages 74133, Rennes (France). 9-11 juin 2010. http://www.sstic.org/media/
SSTIC2010/SSTIC-actes/virtdbg/.
[Aumller et al. 03] Christian Aumller, Peter Bier, Wieland Fischer, Peter Hofreiter, et Jean-
Pierre Seifert. Fault Attacks on RSA with CRT : Concrete Results and Practical Coun-
termeasures. In Burton S. Kaliski, etin K. Ko, et Christof Paar, diteurs : Procee-
dings of the 4th International Workshop on Cryptographic Hardware and Embedded Sys-
tems (CHES 02), volume 2523 de Lecture Notes in Computer Science, pages 260275,
Redwood City (CA, USA). Springer Berlin Heidelberg, 2003. ISBN 978-3-540-00409-
7. http://dx.doi.org/10.1007/3-540-36400-5_20.
[Aviienis et al. 04] Algirdas Aviienis, Jean-Claude Laprie, Brian Randell, et Carl E. Land-
wehr. Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE
Transactions on Dependable and Secure Computing (TDSC), 1(1):1133, IEEE Compu-
ter Society Press, Los Alamitos (CA, USA), janvier 2004. ISSN 1545-5971. http:
//dx.doi.org/10.1109/TDSC.2004.2.
[Bareil 06] Nicolas Bareil. Playing with ptrace() for fun and for profit. In Actes du 4e
Symposium sur la Scurit des Technologies de lInformation et des Communications (SS-
TIC 06), pages 89106, Rennes (France). Ecole Suprieure et dApplication des Trans-
missions (ESAT), 31 mai - 2 juin 2006. http://actes.sstic.org/SSTIC06/
Playing_with_ptrace/.
[Becher et al. 05] Michael Becher, Maximillian Dornseif, et Christian N. Klein. FireWire - all
your memory are belong to us. In CanSecWest/core05, Vancouver (Canada). 4-5 mai
2005. http://md.hudora.de/presentations/#firewire-cansecwest.
[Bechta Dugan et al. 90] J. Bechta Dugan, Salvatore J. Bavuso, et M.A. Boyd. Fault trees and
sequence dependencies. In Proceedings of the Annual Reliability and Maintainability Sym-
posium, pages 286293, Los Angeles (CA, USA). 23-25 janvier 1990. http://dx.doi.
org/10.1109/ARMS.1990.67971.
[Biham et Shamir 97] Eli Biham et Adi Shamir. Differential Fault Analysis of Secret Key Cryp-
tosystems. In Jr. Kaliski BurtonS., diteur : Proceedings of the 17th Annual International
Cryptology Conference on Advances in Cryptology (CRYPTO 97), volume 1294 de Lecture
Notes in Computer Science, pages 513525, Konstanz (Germany). Springer Berlin Heidel-
berg, 1997. ISBN 978-3-540-63384-6. http://dx.doi.org/10.1007/BFb0052259.
[Biondi 13] Philippe Biondi. Scapy. Page consulte en juillet 2013. http://www.secdev.
org/projects/scapy/.
[Bisbey et Hollingworth 78] Richard Bisbey et Dennis Hollingworth. Protection Analysis : Fi-
nal Report. Rapport technique numro ISI/SR-78-13, Information Sciences Institute,
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
[Dornseif 04] Maximillian Dornseif. 0wned by an iPod - hacking by Firewire. In PacSec/core04,

Tokyo (Japan). 11-12 novembre 2004. http://md.hudora.de/presentations/
#firewire-pacsec.
[Dowd et al. 06] Mark Dowd, John McDonald, et Justin Schuh. The Art of Software Security
Assessment : Identifying And Preventing Software Vulnerabilities. Addison-Wesley Profes-
sional, Boston (MA, USA), 20 novembre 2006. ISBN 978-0-321-44442-4.
[Duflot 07] Loc Duflot. Contribution la scurit des systmes dexploitation et des micro-
processeurs. Thse de doctorat, Universit de Paris XI, Paris (France), 18 oc-
tobre 2007. http://www.ssi.gouv.fr/archive/fr/sciences/fichiers/
lti/these-duflot.pdf.
[Duflot et Levillain 09] Loic Duflot et Olivier Levillain. ACPI et routine de traitement
de la SMI. In Actes du 7me Symposium sur la Scurit des Technologies de
lInformation et des Communications (SSTIC 09), pages 132168, Rennes (France).
3-5 juin 2009. http://actes.sstic.org/SSTIC09/ACPI_et_routine_de_
traitement_de_la_SMI/.
[Duflot et al. 11] Loc Duflot, Yves-Alexis Perez, et Benjamin Morin. Run-time firmware in-
tegrity verification : what if you cant trust your network card ? In CanSecWest/-
core11, Vancouver (Canada). 9-11 mars 2011. http://www.ssi.gouv.fr/IMG/
pdf/Duflot-Perez_runtime-firmware-integrity-verification.pdf.
[Duflot et al. 10] Loc Duflot, Yves-Alexis Perez, Guillaume Valadon, et Olivier Levillain. Can
you still trust your Network Card ? In CanSecWest/core10, Vancouver (Canada). 24-
26 mars 2010. http://www.ssi.gouv.fr/IMG/pdf/csw-trustnetworkcard.
pdf.
[Duran et Ntafos 84] Joe W. Duran et Simeon C. Ntafos. An Evaluation of Random Testing.
IEEE Transactions on Software Engineering, 10(4):438444, IEEE Press, Piscataway (NJ,
USA), juillet 1984. ISSN 0098-5589. http://dx.doi.org/10.1109/TSE.1984.
5010257.
[Dyer 92] Michael Dyer. The Cleanroom Approach to Quality Software Development. John Wi-
ley & Sons, Inc., New York (NY, USA), 1992. ISBN 979-0-471-54823-5.
[Ebenau et Strauss 94] Robert G. Ebenau et Susan H. Strauss. Software Inspection Process.
McGraw-Hill systems design & implementation series. McGraw-Hill, New York (NY,
USA), 1994. ISBN 978-0-070-62166-4.
[Eddington 12] Michael Eddington. Peach Fuzzing Platform. Page consulte en 2012. http:
//peachfuzzer.com.
[Eichin et Rochlis 89] Mark W. Eichin et Jon A. Rochlis. With Microscope and Tweezers : An
Analysis of the Internet Virus of November 1988. In Proceedings of the IEEE Symposium
on Research in Security and Privacy, Oakland (CA, USA). IEEE Computer Society, mai
1989. ftp://athena-dist.mit.edu/pub/virus/mit.PS.
[ErrProne 12] ErrProne. Jynx-Kit Release 2. 18 mars 2012. http://packetstormsecurity.
org/files/110942/Jynx-Kit-Release-2.html.
[EurAsia 10] EurAsia. PS3 Glitch Hack. 8 avril 2010. http://www.eurasia.nu/wiki/
index.php/PS3_Glitch_Hack.
[Fagan 76] Michael E. Fagan. Design and Code Inspections to Reduce Errors in Program De-
velopment. IBM Systems Journal, 15(3):182211, IBM Corporation, Riverton (NJ, USA),
juin 1976. ISSN 0018-8670. http://dx.doi.org/10.1147/sj.382.0258.
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
[Thevenod-Fosse 91] Pascale Thevenod-Fosse. Software Validation by Means of Statistical

Testing : Retrospect and Future Direction. In Algirdas Aviienis et Jean-Claude
Laprie, diteurs : Proceeding of the 1st IFIP International Working Conference on De-
pendable Computing for Critical Applications (DCCA), volume 4 de Dependable Com-
puting and Fault-Tolerant Systems, pages 2350, Santa Barbara (CA, USA). Springer
Vienna (Autriche), 1991. ISBN 978-3-7091-9125-5. http://dx.doi.org/10.1007/
978-3-7091-9123-1_2.
[Trefis 12] Trefis. ANALYSIS for INTEL. Rapport technique, Trefis, 100 City Hall Plaza, Boston
(MA, USA), 2 aot 2012. http://pdfs.trefis.com/6298-FHoMvURdX8S27OEB/
Intel_2012-08-02.pdf.
[Trefis Team 12] Trefis Team. Can Intel Continue To Dominate The PC Mi-
croprocessor Market ? Forbes Magazine, 31 mai 2012. http:
//www.forbes.com/sites/greatspeculations/2012/05/31/
can-intel-continue-to-dominate-the-pc-microprocessor-market/.
[Triulzi 08a] Arrigo Triulzi. Project Maux Mk.II - I 0wn the NIC, Now I want a Shell ! . In
PacSec/core08, Tokyo (Japan). 12-13 novembre 2008. http://www.alchemistowl.
org/arrigo/Papers/Arrigo-Triulzi-PACSEC08-Project-Maux-II.pdf.
[Triulzi 10b] Arrigo Triulzi. The Jedi Packet Trick takes over the Deathstar (or : Ta-
king NIC Backdoors to the Next Level ). In CanSecWest/core10, Vancouver (Ca-
nada). 24-26 mars 2010. http://www.alchemistowl.org/arrigo/Papers/
Arrigo-Triulzi-CANSEC10-Project-Maux-III.pdf.
[truff 03] truff. Infecting Loadable Kernel Modules. Phrack Magazine, 61(10), 13 aot 2003.
http://www.phrack.org/issues.html?issue=61&id=10#article.
[van de Ven 08] Arjan van de Ven. [PATCH] make /dev/kmem a config option. 10 fvrier
2008. http://lkml.org/lkml/2008/2/10/316.
[van Eck 85] Wim van Eck. Electromagnetic Radiation from Video Display Units : An Eaves-
dropping Risk ? Computers & Security, 4(4):269286, Elsevier Advanced Technology
Publication, Oxford (GB), dcembre 1985. ISSN 0167-4048. http://dx.doi.org/
10.1016/0167-4048(85)90046-X.
[van Emden 92] Maarten H van Emden. Structured Inspections of Code. Journal of Software
Testing, Verification, and Reliability, 2:133153, John Wiley & Sons, Inc., New York (NY,
USA), 1992. http://dx.doi.org/10.1002/stvr.4370020304.
[von Neumann 45] John von Neumann. First Draft of a Report on the EDVAC. Rapport
technique , Contrat numro W-670-ORD-4926, Moore School of Electrical Enginee-
ring, University of Pennsylvania, Pennsylvania (PA, USA), 30 juin 1945. http:
//dx.doi.org/10.1109/85.238389.
[Vuagnoux et Pasini 09] Martin Vuagnoux et Sylvain Pasini. Compromising Electromagnetic
Emanations of Wired and Wireless Keyboards. In Proceedings of the 18th USENIX Se-
curity Symposium (SSYM 09), pages 116, Montreal (Canada). USENIX Association,
Berkeley (CA, USA), 2009. https://www.usenix.org/legacy/event/sec09/
tech/full_papers/vuagnoux.pdf.
[Waeselynck 93] Hlne Waeselynck. Vrification de logiciels critiques par le test statistique.
Thse de doctorat, Institut National Polytechnique (INP) de Toulouse, Toulouse
(France), 19 janvier 1993. http://homepages.laas.fr/waeselyn/papers/
these_Helene_WAESELYNCK.pdf.
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

Thesis Fernand Lone Sang

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Thesis Fernand Lone Sang

Hochgeladen von

Copyright:

Verfügbare Formate

THE` SE

Presentee et soutenue par :

Chapitre 1 Actions malveillantes impactant la scurit des systmes informatiques 5

Chapitre 2 laboration dun modle dattaques 29

2.2.3 Application un modle de systme informatique . . . . . . . . . . . . . . 38

Chapitre 3 Mise en uvre dattaques par entres-sorties sur une architecture PC 49

Chapitre 4 Application des techniques de fuzzing sur les bus dentres-sorties 77

Annexe A Preuve de concept dattaque par partage didentifiants PCI Express 99

Annexe C Plusieurs exemples dexprimentations avec le contrleur IronHide 109

1.1 Arbre de la sret de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Illustration de la terminologie des bus informatiques . . . . . . . . . . . . . . . . 31

3.1 Exemple darchitecture matrielle Intel-PC (chipset Q45) . . . . . . . . . . . . . . . 51

4.1 Couches protocolaires PCI Express . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

A.1 Plate-forme exprimentale considre . . . . . . . . . . . . . . . . . . . . . . . . . 100

B.1 Architecture simplifie dune carte graphique . . . . . . . . . . . . . . . . . . . . . 105

C.1 Plate-forme dexprimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

3.1 Access Control Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.1 Transactions PCI Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

sources matrielles et logicielles qui y sont associes.

2 Prsentation de nos travaux

Actions malveillantes impactant la

1.1 Scurit des systmes informatiques

1.1.1 Concepts et terminologie des systmes [Laprie 04]

1.1.2 Sret de fonctionnement

1.1.2.1 Attributs de la sret de fonctionnement

F IGURE 1.1 Arbre de la sret de fonctionnement

1.1.2.2 Entraves la sret de fonctionnement

F IGURE 1.2 Propagation des erreurs dans un systme de systmes

1.1.2.3 Moyens pour la sret de fonctionnement

Le dveloppement dun systme sr de fonctionnement passe par lutilisation combine

1.1.3 Scurit des systmes informatiques [Deswarte 03]

1.1.3.4 Autres facettes de la scurit

mission informatique dans un environnement donn. Un systme informatique peut alors d-

1.2 Classification des attaques sur les systmes informatiques

1.2.1 Attaques agissant au niveau des systmes logiciels

1.2.1.1 Abus dune fonctionnalit logicielle lgitime

Abus dune fonctionnalit

Abus dune fonctionnalit

Canaux de fuite Analyse des canaux de fuite

F IGURE 1.3 Classification des attaques sur les systmes informatiques

de modules dextension au sein du noyau de systme dexploitation. Cela limite fortement

1.2.1.2 Exploitation dune fonctionnalit logicielle vulnrable

bits a provoqu une exception matrielle correspondant un dbordement arithmtique car

1.2.2 Attaques agissant au niveau des systmes matriels

1.2.2.1 Abus dune fonctionnalit matrielle lgitime

1.2.2.2 Exploitation dune fonctionnalit matrielle vulnrable

1.2.2.3 Modification de la configuration matrielle

Le fonctionnement dun systme matriel repose en partie sur sa configuration matrielle.

1.2.3 Attaques agissant au niveau des canaux de communication

1.2.3.1 Destruction de messages

1.2.3.2 Modification de messages

1.2.3.3 Captation de messages

1.2.3.4 Insertion de messages

Ce vecteur dattaque consiste insrer des messages dans un canal de communication. La

1.2.4 Attaques agissant au niveau des canaux auxiliaires

1.2.4.1 Analyse des canaux de fuite

Attaque par analyse de la consommation lectrique. La consommation lectrique dun sys-

Attaque par analyse du rayonnement lectromagntique. Dans un circuit lectronique, le

Attaque par analyse acoustique. Les composants mcaniques et lectroniques mettent un

1.2.4.2 Injection de fautes par les canaux auxiliaires.

Modification de la frquence dhorloge. De la mme faon que pour la tension lectrique,

Modification de la temprature. Les constructeurs de composants lectroniques dfinissent

1.3 Mthodes et techniques pour llimination des fautes

F IGURE 1.4 Classification des techniques de vrification