Etienne Louboutin

Introduction  et résumé des travaux

La sécurité d’un logiciel peut être prise en compte dès la conception. Cette approche, appelée security by design, permet d’agir au plus tôt de la conception pour influer sur l’architecture d’un logiciel. Les protections contre les attaques par détournement de flot d’exécution, comme le return oriented programming, ne sont pas pensées pour changer la manière de concevoir un logiciel, mais permettent de protéger un logiciel soit lors de sa compilation soit en travaillant directement sur le binaire produit.

Dans cette thèse, nous proposons des métriques permettant à un développeur d’évaluer la sensibilité d’un logiciel face aux attaques par détournement de flot d’exécution. Pour aider le développement, les métriques définies permettent d’identifier les paramètres de production de binaires d’un logiciel qui entrainent une sensibilité accrue à ces attaques. L’utilisation de ces métriques sont illustrées dans cette thèse en étudiant l’influence de compilateurs et de leurs options, de langages et architectures matérielles.

État de l’art et contexte des travaux de thèse

Les premières attaques basées sur de la réutilisation de code étaient appelées return-to-libc et détournaient le flot d’exécution pour appeler des fonctions présentes dans la bibliothèque standard C pour réaliser l’attaque. En 2007, Shacham   publie une généralisation de ces attaques n’utilisant pas d’appels de fonction explicites, nommées a posteriori ROP. Cet article montre aussi la capacité de ces attaques à être Turing-complet.

En 2012, la même équipe revient sur le sujet   en précisant les concepts, et comment réaliser ces attaques, les mettre en œuvre, analyser un programme pour chercher ce qui est in- téressant. Cette généralisation arrive à la fois sur les architectures SPARC et x86. Ils montrent aussi que la bibliothèque standard C est suffisante pour monter des attaques à but quelconque.

Actions en lien avec la  Détection, et la protection contre ce type d’attaques

Quelques solutions ont été mises en places pour se protéger de ce type d’attaque, que j’ai analysées.

Control Flow Integrity: Certains groupes ont commencé à travailler sur les manières possibles de garantir que le flot d’exécution d’un programme soit celui attendu. Une publication de chez Microsoft [1] met en place une première protection qui garantit que le flot d’exécution n’a pas été détourné. La protection mise en place permet de protéger certains types de redirection, protégeant ainsi les appels de fonction indirects. C’est une protection limitée contre le changement de flot, qui ne protège pas contre la plupart des formes de ROP. Leur solution à l’avantage d’être transparente, en n’impliquant une surcharge d’opération presque nulle, et ne nécessite qu’une légère modification du compilateur.

Code Pointer Integrity: Un autre groupe a travaillé [3] sur une vérification à la fois statique et dynamique de tous les pointeurs présents dans un code, pour déterminer s’ils ont besoin d’être protégés, comme par exemple les pointeurs sur fonction, utilisés dans tous les call, jump, ret. Les pointeurs génériques (void \* et char \*) ont besoin d’une analyse supplémentaire pour déterminer si le pointeur a besoin d’être protégé. La protection se base sur une séparation supplémentaire de la mémoire en garantissant une zone mémoire considérée comme protégée, dans laquelle les pointeurs nécessaires seront placés, et dont la valeur sera vérifiée lors de l’exécution.  Cette solution est mise en place avec une modification du compilateur et des sources non modifiées. La diminution des performances d’exécution est d’environ 1% avec une protection d’un nombre de pointeur faibles (call, jump, ret) et de 3% à 10% avec une protection plus élevée. Dans les deux cas, les attaques utilisant du ROP basique sont rendues impossibles.

PICON: Une solution différente, propsée par l’ANSSI [2], utilise un moniteur externe au programme pour surveiller l’ensemble des appels et sorties de fonctions dans un programme. Chacune des entrées et sorties envoie un signal, reçu par le moniteur qui vérifie la correspondance avec les derniers signaux reçus. Cette technique n’a qu’un faible impact sur les performances tant que seuls les call et ret sont protégés. Lorsque les jump sont protégés aussi, les performances chutent. Leur outil n’a aussi été testé que sur des programmes non « multi threadés ».

 

Objectifs généraux et actions futures

Un séminaire de  sensibilisation auprès du  personnel à Thalès Cholet a été réalisée.

Un travail d’approfondissement des solutions de protection contre le ROP est prévu pour le mois suivant.

Les objectifs principaux pour l’instant définis comportent l’analyse statique d’un système comportant un ou plusieurs logiciels et du matériel pour remonter des informations sur la facilité de réaliser une attaque ROP sur ledit système.

L’établissement d’un modèle comportemental d’un système et un analyseur pour détecter une exécution anormale afin d’en remonter des informations fait aussi partie de mes objectifs.