L'audit de programmes en C et C++ s'automatise souvent. Des outils existent, mais ils ont des approches très différentes : de l'utilisation de grep à celle d'outils plus proches du langage analysé, la qualité des analyses (et le prix des outils) varie fortement. La possibilité d'étendre ces outils pose aussi problème. Si l'on veut une base libre, gratuite, proche du langage et extensible, pourquoi ne pas réutiliser directement un compilateur ? Le système de plugins intégré à la suite de compilateurs GCC (disposant de parseurs C, C++, mais aussi Objective C, Java, ... ainsi que de diverses représentations internes) nous permet de concevoir nos propres analyses statiques.Cet article se veut une introduction à l'architecture de GCC et au développement de petits analyseurs facilitant la vie lors d'un audit de code.
1. Introduction
Pour analyser un code source, l'idée la plus simple est de le considérer comme une suite de lignes de texte. La recherche de motifs vulnérables s'effectue par une expression régulière. Une commande comme grep '\bgets *(' *.c souffre néanmoins de nombreux inconvénients : pas de gestion des commentaires (/* pas d'appel à gets() */), ni des chaînes littérales (char tab[] = "gets()";), etc.
Une approche plus fine consiste à faire une analyse lexicale du code source : les espaces et les commentaires sont ignorés, puis le code source devient une suite de tokens groupés en catégories (identifiant de variables, mot-clé, etc.). Des outils comme Flawfinder [FLAWFINDER] ou RATS [RATS] se servent de cette représentation pour leur recherche de motifs. Mais des limites se font aussi sentir : il manque les analyses syntaxique et sémantique du code source, qui peuvent être fournies par un compilateur.
L'utilisation d'un compilateur et notamment de l'AST...
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première
