Conclusion

Un logiciel est sensible `a des attaques par d´etournement de flot d’ex´ecution, les binaires associ´es `a ces logiciels peuvent ˆetre prot´eg´es, mais de mani`ere insuffisante. Ce chapitre pr´esente les concepts manipul´es dans cette th`ese permettant d’arriver `

a cet ´etat des lieux. Un logiciel a ´et´e d´efini, et les diff´erents mod`eles d’ex´ecution ont ´et´e pr´esent´es. Ces descriptions ont permis d’expliquer le fonctionnement des attaques par d´etournement d’ex´ecution. Ce chapitre d´efinit aussi ce que sont les gadgets, ´el´ements qui constituent ces attaques. La construction des attaques et des moyens de s’en pr´evenir ont ´et´e pr´esent´es ainsi que les limitations induites.

Ce chapitre nous a permis de voir que de nombreuses protections sont dis-ponibles pour prot´eger un logiciel contre du d´etournement de flot d’ex´ecution. Un point qui ressort de cette pr´esentation est qu’il est difficile de construire des ´el´ements de comparaison qui permettent `a la conception d’un logiciel de faire des choix ´eclair´es propres `a des besoins sp´ecifiques. Bien que la plupart des solutions proposent des chiffres comparables pour la perte de performance, les chiffres donn´es pour le gain de s´ecurit´e sont difficilement quantifiable.

De plus, les protections pr´esent´ees apparaissent tardivement dans le processus de conception d’un logiciel. Des protections vont ˆetre d´eploy´ees directement sur un binaire produit, comme [Aba+09], d’autres n´ecessitent un compilateur particulier, comme Gfree [Ona+10]. Lors de la conception d’un logiciel, il est donc difficile d’´evaluer pr´ecis´ement l’interaction que peuvent avoir deux protections, ou s’il peut ˆetre int´eressant de porter des principes sp´ecifiques d’une protection d’un

1.9. CONCLUSION 41

compilateur `a un autre.

Le point qui nous manque pour ´etudier l’impact des diff´erentes ´etapes de la conception sur la sensibilit´e d’un logiciel est une ou plusieurs m´etriques permettant de facilement comparer un grand nombre de logiciels. L’intervention humaine n’est pas une option qui permet de facilement passer `a l’´echelle. De mˆeme, comme montr´e pour les am´eliorations d’attaques de l’outil Q en section 1.8.2, l’utilisation d’attaques existantes sur des logiciels d´efinis, souvent des Common Vulnerabilities and Exposures (CVE)⁵, n’est pas id´eale. En effet, cette approche est trop r´eactive et ne mesure l’efficacit´e d’une protection que contre des attaques sp´ecifiques et connues.

Dans cette th`ese, plusieurs ´el´ements sont propos´es pour palier `a ces manques. Le chapitre 2 pr´esente les diff´erentes m´etriques qui sont mises en place pour comparer les diff´erents ´el´ements qui influent sur la sensibilit´e potentielle d’un logiciel face aux attaques par d´etournement de flot d’ex´ecution. Dans ce chapitre, des ´el´ements mis en avant ici sont r´eutilis´es pour permettre de confirmer les r´esultats pr´esents dans la litt´erature. L’´evaluation des m´etriques et leur utilisation dans la conception amont d’un logiciel sont faites respectivement dans les chapitres 3 et 4.

Chapitre

2

Analyse et mise en

place de m´etriques

2.1 Analyse d’un corpus existant

La conception d’un syst`eme utilise souvent des ´el´ements quantitatifs et quali-tatifs permettant de comparer sur diff´erents axes les solutions `a disposition. Les diverses contraintes des syst`emes en mati`ere de performances impliqueront des choix d’architecture mat´erielle, de langages ou de biblioth`eques diff´erents. Lors de l’´etude des performances d’un logiciel, plusieurs suites de logiciels de test permettant d’´evaluer l’apport d’une technologie ou d’une ´evolution sont disponibles. On trouve par exemple le SPEC CPU2000 [Hen00], son ´evolution SPEC CPU2006 [Hen06]. Ces deux suites sont assez populaires et servent d’´etalon pour comparer deux solutions en termes de performance.

D’un autre cˆot´e, pour la s´ecurit´e d’une application, ce type de suites logicielles n’existe pas pour le moment. Nous avons vu au chapitre pr´ec´edent que la mesure d’efficacit´e d’une protection est souvent faite au cas par cas par les cr´eateurs de protections, comme explicit´e en section 1.8. Des suites de benchmarks non d´edi´ees `a la s´ecurit´e sont parfois utilis´ees. De mani`ere g´en´erale, les outils et m´ethodes utilis´es sont bien diff´erents d’une protection `a l’autre.

La m´etrique commun´ement utilis´ee pour d´eterminer les efforts de production r´ealis´es est le d´enombrement des gadgets dans un logiciel prot´eg´e. La mani`ere avec laquelle ce d´enombrement est effectu´e varie d’une protection `a une autre. Deux outils ´

emergent, le premier est ROPgadget [Sal12], le second est Q [SAB11]. Certains pr´ef`erent utiliser des solutions internes, parfois manuelles. Le point principal qui distingue les m´ethodes d’´evaluation est l’ensemble de binaires sur lequel les protections sont ´evalu´ees. Certains appliquent leurs mesures sur des logiciels pour

leur exposition `a des attaquants, comme nginx ou zip. Il est fr´equent que seuls des ensembles limit´es soient test´es.

Pour comparer diff´erents outils utilis´es lors du processus de conception d’un logiciel s´ecuris´e, il fallait donc ´etendre ce qui existe, comme par exemple [Bur+17] pour la comparaison des techniques de CFI. Le but est d’avoir une m´ethodologie et des m´etriques uniformis´ees permettant de facilement passer `a l’´echelle. L’in-tervention humaine doit ˆetre limit´ee au maximum. Une m´etrique `a ´eviter, par exemple, estnous n’arrivons pas `a construire une chaˆıne d’attaque sur les binaires prot´eg´es . Elle peut donner un indice dans un contexte particulier, mais n’aide pas forc´ement `a bˆatir une confiance dans la protection fournie, et ne passe pas `a l’´echelle ´egalement.

Ce chapitre et le suivant, en page 71, montrent que le processus de compilation est complexe. La comparaison de diff´erents processus et des param`etres qui influent dessus de mani`ere exhaustive est jug´ee trop coˆuteuse `a mettre en œuvre. Le choix a ´et´e fait de partir sur une analyse des binaires pour d´eterminer la sensibilit´e d’un logiciel. Un logiciel va donc pr´esenter plusieurs sensibilit´es aux attaques par d´etournement de flot d’ex´ecution en fonction des binaires choisis. Cette approche pr´esente un avantage pr´esent´e en section 2.2.1, la disponibilit´e des binaires sur des distributions GNU/Linux. Cette approche permet aussi d’´etendre le champ d’´etudes assez rapidement, puisque seuls des binaires, avec une description de leur provenance, est n´ecessaire pour am´eliorer la pertinence statistique de l’´etude. Cette approche statistique, d´evelopp´ee dans ce chapitre, sur l’´etude des binaires permet de cerner des m´etriques de sensibilit´e utiles.