L'expérience acquise sur le fuzzing d'équipements avioniques dans le cadre de notre travail, nous a poussé à développer notre propre framework de fuzzing. La raison à cela est que nous souhaitions laisser à l'utilisateur la possibilité : (1) de spéci er des formats de données de façon plus exible que ce qui est permis au travers des autres frameworks (comme sulley ou Peach), et (2) d'e ectuer des transformations de données plus élaborées. En outre, développer un nouveau framework fut considéré comme la solution la plus adaptée pour expérimenter de nouveaux concepts. De ce choix découle également une liberté totale quant à son évolution. fuddly est cette tentative visant à construire sur des concepts existants et à mettre en uvre nos idées, tout en restant compatible avec nos contraintes : pas de disponibilité du code source des cibles, architectures non-x86 (voire exotiques), moyens d'observabilité spéci ques à l'avionique. 1
Une vue d'ensemble de fuddly est donnée en section 2. La modélisation des données est ensuite abordée en section 3, avant d'introduire les manipulations permises sur ces données en section 4. L'automatisation du processus de fuzzing est alors présentée en section 5. En n, les perspectives d'évolution envisagées sont examinées en section 6.
Notre framework de fuzzing et de manipulation de données est disponible sous licence GPL à l'adresse https://github.com/k0retux/fuddly. Il est écrit en python (compatible avec la version 2.7 jusqu'à la version 3.4) et peut être utilisé directement depuis un interpréteur python (comme ipython2 ), ou bien depuis un shell dédié (simpli ant certaines opérations). Ses principales caractéristiques sont de permettre à l'utilisateur :
La représentation des données est e ectuée dans fuddly au travers de la description d'un graphe orienté acyclique, dont les n uds terminaux décrivent les di érentes parties d'un format de données, et les arcs (qui peuvent être de natures di érentes) capturent sa structure. Ce graphe intègre à la fois les informations syntaxiques et sémantiques sur le format de données. Dans la suite, nous appelons cette description de graphe un modèle de données . Une donnée particulière est alors appelée une instance de ce modèle. Le choix de cette modélisation permet de représenter avec exibilité des formats de données de nature très di érentes. Par exibilité , nous entendons d'une part la possibilité de modéliser de façon plus ou moins ne les di érentes parties d'un format (par exemple une modélisation ne sur des parties jugées plus complexe à traiter par la cible, et une modélisation grossière sur le reste), et d'autre part un niveau d'expressivité important.
À partir de ce modèle, nous pouvons générer des données et absorber des données existantes (projection d'une donnée existante dans le modèle de données). La génération de données autorise la création de données conformes au modèle si l'on souhaite interagir de façon correcte avec la cible ; ou la création de données dégénérées a n d'éprouver la robustesse de la cible. L'absorption des données peut servir à générer des données à partir de données existantes lorsque la modélisation n'est pas assez ne pour générer des données su samment correctes par elles-mêmes ; ou encore de comprendre les sorties de la cible, a n d'y répondre de façon adéquate ou non.
La génération de données revient à parcourir le graphe qui modélise le format de données. Après chaque parcours, une donnée est produite et chaque parcours fait évoluer le graphe, au choix, de façon déterministe ou arbitraire. Le parcours du graphe peut également être accompagné d'altération sur les n uds (cf. section 4). Di érents types de n uds ont été dé nis pour la modélisation des données :
La structure d'un format de données est capturée par les liaisons entre les n uds du graphe. Di érents type de liens se distinguent :
En outre, à chacun de ces n uds peut être associé des con gurations alternatives (un n ud terminal peut être changé dynamiquement en un n ud non-terminal ou encore en générateur) qui peuvent être choisies dynamiquement, et même au cours du parcours du graphe. Cette fonctionnalité permet de capturer di érents aspects d'un format de données au sein d'un même modèle, tout en o rant la possibilité de ne travailler que sur un seul aspect à la fois. Elle peut s'avérer utile également pour l'absorption. En e et, cette opération peut réclamer une modélisation di érente de certains aspects du format de données par rapport à la stratégie de génération. Les con gurations alternatives des n uds rendent possible l'agrégation de ces di érences au sein d'un même modèle.
En n, il est également possible d'associer (statiquement et dynamiquement) une sémantique aux n uds du graphe ou des méta-informations quelconques, rendant possible des altérations plus évoluées sur le modèle (cf. section 4).
fuddly dé nit des primitives pour la manipulation des données modélisées. Certaines facilitent la recherche (sémantique ou syntaxique) au sein de cette donnée, d'autres servent à sa modi cation (aussi bien dans sa structure que dans son contenu), tout en laissant le choix à l'utilisateur de préserver les contraintes du modèle. Par exemple, la simple modi cation du contenu d'un chier dans une archive ZIP, modélisée dans fuddly, se résume à la modi cation d'un n ud du graphe qui représente l'archive. L'ensemble des contraintes associées est ensuite recalculé automatiquement par fuddly (comme par exemple les champs compressed_size, crc, les o sets des chiers suivants, etc.).
Les manipulations sur une donnée peuvent être mises en uvre au sein d'entités, appelées disrupteurs , briques de base dans l'automatisation du fuzzing. Un certain nombre de disrupteurs génériques, implémentés dans fuddly, sont applicables à n'importe quel modèle de données (ex : disrupteurs qui altèrent les n uds à variables typées ; itèrent sur les con gurations alternatives des n uds ; tronquent les données ; autorisent l'appel à des outils externes pour modi er les données ; etc.). D'autres sont par contre spéci ques à un modèle en particulier.
Les disrupteurs génériques implémentés peuvent être paramétrés pour e ectuer des modi cations suivant di érents critères (chemin dans le graphe, propriétés syntaxiques ou sémantiques, etc.). L'ordre du parcours peut également être a ecté par des méta-informations éventuellement renseignées dans le modèle, comme le niveau d'intérêt des n uds (capturant l'intuition de l'évaluateur, quant à l'impact sur la cible, qu'entraînerait la modi cation de ces n uds). Parmi ces disrupteurs, certains conservent un état d'exécution d'un appel sur l'autre. Ils prennent en entrée, lors du premier appel, une donnée modélisée, et fournissent ensuite après chaque appel une nouvelle donnée issue de celle-ci. D'autres disrupteurs ne conservent aucun état. À partir d'une donnée fournie en entrée, ils produisent une nouvelle donnée unique.
En n, concernant les disrupteurs à état, leur implémentation peut s'appuyer sur une infrastructure de parcours des données modélisées. Cette infrastructure met en uvre un algorithme paramétrable de parcours de graphe. À chaque étape de ce parcours l'algorithme fait appel à un objet visiteur-consommateur (fourni préalablement en paramètre). Ce dernier dispose alors de la possibilité de consulter le n ud sur lequel il est appelé, d'e ectuer autant de modi cations qu'il le souhaite (chaque modi cation entraînant la génération d'une nouvelle donnée), avant de redonner la main à l'algorithme de parcours. Cet algorithme pourra alors réévaluer le parcours du graphe suivant les modi cations engendrées (par exemple, si la modi cation a altéré un n ud non-terminal, alors que l'algorithme venait de parcourir tous les n uds ls, il peut décider de parcourir à nouveau les n uds ls qui sont à présent peut être di érents).
L'automatisation du processus de fuzzing s'e ectue dans fuddly à deux niveaux. D'une part, les disrupteurs peuvent être chaînés entre eux, qu'ils soient génériques ou spéci ques, ou encore avec ou sans état. fuddly se charge de dérouler les opérations dans l'ordre demandés et d'alimenter les disrupteurs au besoin. D'autre part, le processus de fuzzing peut être implémenté au sein d'un opérateur virtuel, depuis lequel est réalisée la plani cation des opérations à e ectuer sur la cible (type de données à envoyer, type de modi cations à appliquer avant l'envoi, etc.). L'opérateur est par défaut rappelé après chaque émission de données vers la cible, mais il peut également fournir un lot d'instructions à exécuter avant d'être rappelé. Cette approche autorise la stimulation simultanée d'une cible sur des entrées di érentes, chacune assujettie à un protocole spéci que. Avant de décider de la marche à suivre, l'opérateur peut s'appuyer sur l'infrastructure de monitoring3 de fuddly, pour déterminer l'état de la cible, ainsi que pour récupérer ses réponses.
Dans ce papier, nous n'avons fait qu'e eurer les points saillants de fuddly. Bien que les fonctionnalités o ertes par ce framework soient totalement utilisables, fuddly reste un terrain d'expérimentation, et au-delà de l'implémentation de nouveaux modèles de données, de nombreuses évolutions sont prévues, notamment :