Évaluation des techniques d'intégrité de flux de contrôle au niveau binaire

La corruption de mémoire est un gros problème dans les logiciels qui peut mener à des attaques sur les systèmes informatiques. Un des moyens d'attaque courants s'appelle le détournement de flux de contrôle, où un attaquant prend le contrôle de l'exécution du programme. Pour lutter contre ces attaques, on utilise une technique appelée Intégrité du Flux de Contrôle (CFI). CFI s'assure qu'un programme suit seulement les chemins d'exécution valides comme prévu par ses développeurs. Il y a deux types principaux de CFI : le CFI au niveau source, qui fonctionne avec le code original, et le CFI au niveau binaire, qui opère sur les programmes compilés.

Cet article se concentre sur l'évaluation de l'efficacité des techniques de CFI au niveau binaire par rapport à leurs homologues au niveau source. On discute de la manière d'évaluer ces techniques et des défis que cela implique.

#Contexte

#Intégrité du Flux de Contrôle

CFI est conçu pour protéger les programmes contre le détournement de leurs chemins prévus. Quand un programme s'exécute, il ne devrait sauter qu'à des emplacements cibles spécifiques que le programmeur définit. Si un attaquant essaie de rediriger le flux du programme vers un emplacement non prévu, CFI devrait bloquer cela.

CFI repose sur l'analyse du programme pour créer un graphe de flux de contrôle (CFG), qui montre les chemins d'exécution valides. Au moment de l'exécution, CFI vérifie que le programme suit ce graphe.

#Importance de la Sécurité Mémoire

Les programmes écrits dans des langages comme C et C++ ont souvent des vulnérabilités qui peuvent être exploitées à cause de problèmes de sécurité mémoire. Des techniques comme les Canaris de Pile, la Randomisation de l'Agencement d'Adresse (ASLR) et la Prévention de l'Exécution de Données (DEP) sont en place pour aider à protéger contre ces vulnérabilités. Cependant, les attaquants trouvent encore des moyens de contourner ces défenses, surtout en utilisant des méthodes comme les Attaques par réutilisation de code (CRA).

Les CRA impliquent l'utilisation de code existant dans un programme pour exécuter des actions malveillantes au lieu de faire tourner du nouveau code. Pour lutter contre cela, CFI devient un mécanisme de défense vital, surtout au niveau binaire, où le code source n'est pas disponible pour analyse.

#CFI au Niveau Binaire vs. CFI au Niveau Source

Le CFI au niveau binaire est nécessaire pour les programmes distribués sans leur code source. Cependant, récupérer avec précision les informations d'un programme à partir de binaires est un défi. On a besoin de détails spécifiques, comme les comptes et types d'arguments de fonction, qui peuvent ne pas être disponibles après compilation. Ce manque d'informations précises peut mener à des inexactitudes dans l'efficacité du CFI au niveau binaire.

Dans ce travail, on développe un Cadre d'évaluation pour comparer l'efficacité de différentes techniques de CFI au niveau binaire et voir comment elles se comparent aux techniques au niveau source.

#Notre Cadre

On a créé un cadre modulaire appelé Binary-CFI pour mesurer l'efficacité de diverses techniques de CFI au niveau binaire basées sur les types. Le cadre aide à rassembler les informations nécessaires à l'analyse des programmes à partir d'outils au niveau source et binaire.

#Métriques d'Évaluation

Pour évaluer les techniques de CFI au niveau binaire, on a introduit de nouvelles métriques pour déterminer combien de cibles valides sont atteintes et combien de cibles incorrectes sont acceptées. On s'est concentré sur les vrais positifs (cibles correctement identifiées), faux positifs (cibles incorrectement identifiées), vrais négatifs (cibles correctement rejetées) et faux négatifs (cibles correctes manquées).

Les nouvelles métriques nous aident à comprendre à quel point les techniques de CFI au niveau binaire performent par rapport à leurs homologues au niveau source.

#Méthodologie

#Collecte d'Informations

Pour évaluer l'efficacité des techniques de CFI au niveau binaire, on devait collecter des données des analyses au niveau source et binaire. On a utilisé le compilateur LLVM pour recueillir des informations lors du processus de compilation du code source. Pour l'analyse au niveau binaire, on a utilisé l'outil d'ingénierie inverse IDA Pro pour extraire les informations pertinentes sur le programme.

#Techniques de CFI en Évaluation

On s'est concentré sur quatre politiques de CFI au niveau binaire différentes :

1. TypeArmor - Cette politique est la plus permissive, ne considérant que le nombre d'arguments sans tenir compte de leurs types.
2. IFCC - Cette politique considère les comptes d'arguments et leurs types de base tout en ignorant les types de pointeurs.
3. MCFI - Une politique plus stricte qui fait la distinction entre différents types de pointeurs et fait correspondre les comptes et types d'arguments.
4. CFI - Cette politique considère les arguments et leurs types ainsi que les types de retour selon des règles spécifiques.

#Banques de Tests

On a évalué notre cadre en utilisant plusieurs benchmarks, y compris des programmes de la suite SPEC et de grandes applications du monde réel comme Nginx, Node.js et PostgreSQL. Ces applications ont fourni un bon mélange de scénarios pour évaluer la performance des techniques de CFI.

#Résultats

#Configurations de Benchmark

On a mis en place deux configurations de benchmark pour les tests :

1. Scénario Idéal - Ici, on inclut des symboles de débogage pour aider à guider l'analyse.
2. Scénario Pratique - Dans ce cas, les symboles de débogage sont retirés, ce qui met à l'épreuve les cadres d'analyse binaire.

#Métriques de Performance

Après avoir appliqué les politiques de CFI au niveau binaire dans les deux configurations, on a comparé les métriques pour comprendre à quel point chaque politique était efficace pour identifier des cibles valides et minimiser des cibles incorrectes.

#Observations

1. TypeArmor était la politique la plus relaxée, permettant le plus grand nombre de cibles.
2. MCFI a montré une approche plus stricte avec un nombre de cibles plus bas, indiquant une sélection plus soigneuse des cibles valides.
3. Les techniques de CFI au niveau binaire ont eu beaucoup de mal par rapport aux techniques au niveau source, particulièrement quand les symboles de débogage étaient absents.

#Défis de l'Analyse Binaire

Le CFI au niveau binaire repose beaucoup sur l'exactitude des informations récupérées des binaires. Malheureusement, comme on l'a vu dans nos expériences, les outils actuels échouent souvent à récupérer des informations précises au niveau binaire.

Par exemple, détecter les types d'arguments de fonction et d'autres données connexes peut entraîner des taux d'erreur élevés. L'exactitude de la détection des comptes d'arguments et des types de retour est particulièrement problématique lorsque les symboles de débogage sont retirés.

#Implications des Erreurs

Les inexactitudes observées soulignent des problèmes significatifs dans la performance des techniques de CFI au niveau binaire. Si les informations utilisées pour prendre des décisions sur le flux de contrôle valide sont incorrectes, la politique CFI pourrait permettre des chemins non sûrs ou rejeter des chemins sûrs, menant potentiellement à des vulnérabilités de sécurité.

#Conclusion

Dans ce travail, on a développé un cadre pour évaluer l'efficacité des techniques de CFI au niveau binaire. Bien que CFI offre une protection essentielle contre les attaques de détournement de flux de contrôle, il est crucial de comprendre les nuances et les limitations des mises en œuvre au niveau binaire.

Nos résultats indiquent que bien qu'il existe des approches prometteuses pour améliorer CFI au niveau binaire, des défis importants demeurent. L'imprécision dans la récupération d'informations à partir de binaires continue de miner les avantages sécuritaires que CFI vise à fournir.

#Travaux Futurs

Pour aller de l'avant, il faut plus de recherche pour améliorer l'exactitude des outils d'analyse binaire et explorer des moyens d'améliorer les politiques de CFI. En abordant ces défis, on peut mieux protéger les programmes contre les attaques de détournement de flux de contrôle et améliorer la sécurité globale des logiciels.