• Aucun résultat trouvé

3.3 Définition de l’outil d’injection d’attaque

3.3.3 Définition des opérateurs d’attaque

Dans l’état de l’art présenté au Chapitre 2, deux études autour de l’injection de faute par mutation de code proposaient un ensemble d’opérateurs pour effec-tuer ces mutations. Ces opérateurs ont été définis pour représenter les fautes lo-gicielles les plus fréquentes [Duraes 2006], ou les vulnérabilités lolo-gicielles les plus fréquentes [Cerveira 2017]. A notre connaissance, il n’existe pas d’étude équiva-lente pour définir des opérateurs représentatifs de code malveillant (opérateurs d’at-taque). C’est ce que nous cherchons à définir à travers cette partie. En particulier, la définition de ces opérateurs d’attaque se base sur trois stratégies de mutation de code appeléesCrashMe,Substitution d’instruction(s) bien formée(s), etMotif d’at-taque. Elles permettent d’effectuer des modifications de différents niveaux, que ce soit pour couvrir un large nombre de modifications possibles, ce qui peut entraîner des exécutions invalides, ou pour générer du code malveillant bien formé qui aura plus de chance d’être exécuté correctement.

Ces trois stratégies sont implémentées au travers des 12 types d’opérateurs d’at-taques détaillés dans la Table 3.3. Ces opérateurs sont définis par une action ( Mo-dification, Ajout ou Suppression), appliquée à une cible (Instruction, Saut, Appel de fonction, Registre, ou Valeur mémoire). Certaines combinaisons ne sont pas re-présentées car elles n’ont pas toutes un sens (par exemple, on ne peut pas Ajouter

un Registre).

3.3.3.1 Stratégie 1 : CrashMe

La stratégie CrashMe est la plus générique. Elle consiste à remplacer du code par un code aléatoire. Cette stratégie est inspirée du principe des attaques de type CrashMe, qui cherchent à exécuter du code aléatoire afin par exemple de

Table 3.3 – Types d’opérateurs d’attaque

Opérateur Stratégie

asso-ciée Détail

Modification

d’instruc-tion aléatoire (MIA) CrashMe Remplace l’instruction courante parune valeur aléatoire Modification

d’instruc-tion (MI) Substitutiond’instruction(s) bien formée(s)

Remplace l’instruction courante par une autre instruction

Modification de saut

(MS) Motif d’attaque Remplace l’instruction de saut cou-rante par une autre instruction de saut Modification d’appel

de fonction (MF) Motif d’attaque Remplace l’appel de fonction courantpar un autre appel de fonction Modification d’un

re-gistre (MR) Motif d’attaque Remplace la valeur d’un registre parune valeur aléatoire Modification d’une

va-leur mémoire (MV) Motif d’attaque Remplace la valeur d’une cas mémoirepar une valeur aléatoire Ajout d’une instruction

(AI) Motif d’attaque Insère une instruction

Ajout d’un saut (AS) Motif d’attaque Insère une instruction de saut Ajout d’un appel de

fonction (AF) Motif d’attaque Insère un appel de fonction Suppression d’une

ins-truction (SI) Motif d’attaque Remplace une instruction par unNOP Suppression d’un saut

(SS) Motif d’attaque Remplace une instruction de saut parunNOP

Suppression d’un appel

3.3. Définition de l’outil d’injection d’attaque 63

découvrir des vulnérabilités, ou provoquer des dénis de service, comme présenté dans [Dessiatnikoff 2012]. Cette stratégie est implémentée à travers l’opérateur d’at-taque MIA (cf Table 3.3), qui remplace une instruction par une valeur aléatoire de la même taille que l’instruction remplacée. Pour l’architecture PowerPC utilisée dans ces travaux, une instruction est codée sur une taille fixe de 32 bits. Cet opérateur est facile à implémenter et est applicable à n’importe quel emplacement dans le code ciblé. Ce type de modification aléatoire permet de couvrir un très grand nombre de modifications possibles, notamment celles utilisant des instructions incorrectes. Par contre, il est plus difficile d’émuler des scénarios d’attaque tels que l’exfiltration ou la falsification de données. En général, cet opérateur va plutôt provoquer des défaillances dans l’application, donc des dénis de service. Les deux autres stratégies proposées dans l’outil cherchent à spécifier des mutations plus à même de provoquer d’autres cas de scénarios d’attaque.

3.3.3.2 Stratégie 2 : Substitution d’instruction(s) bien formée(s)

La seconde stratégie se base sur un dictionnaire d’instructions bien formées, construit au préalable. Ce dictionnaire peut par exemple être une concaténation du binaire de l’application cible, d’autres applications, et/ou du code de l’OS. Le prin-cipe de cette stratégie est de remplacer des instructions par du code bien formé, sé-lectionné dans ce dictionnaire. L’application de cette stratégie permet de garder une couverture assez large tout en limitant le nombre de cas de défaillances générées. Les mutations ne cherchent pas à représenter directement une modification malveillante du code, mais peuvent provoquer des modifications qui vont engendrer un comporte-ment différent par rapport à l’application originale. Comme les instructions insérées sont bien formées, les applications mutantes ont plus de chance de s’exécuter sans provoquer de défaillance, qu’avec l’utilisation de la stratégie CrashMe. L’opérateur associé à cette stratégie est l’opérateur MI de la Table 3.3.

3.3.3.3 Stratégie 3 : Motif d’attaque

La dernière stratégie cherche à spécifier de façon plus précise un code malveillant. Son principe est de représenter les actions unitaires d’un attaquant qui chercherait à faire une modification malveillante d’une application avionique. Pour définir les opérateurs associés à cette stratégie, nous avons donc implémenté plusieurs scéna-rios d’attaque sur une application avionique générique (utilisée notamment comme exemple lors de formations au développement d’une application avionique), et ex-trait les opérations élémentaires réalisées pour développer ces scénarios. Plus préci-sément, ces scénarios cherchaient à modifier les communications (contenu, en-tête ou configuration), modifier les processus (période ou code exécuté), et exfiltrer des in-formations (emplacement de la configuration, ports de communication). Les actions unitaires extraites de ces scénarios ont été généralisées sous la forme d’une action (Modification, Ajout ou Suppression) appliquée à une cible (Instruction, Saut, Ap-pel de fonction, Registre, ou Valeur mémoire). Ils ont donc permis de définir les 10

opérateurs d’attaque MS, MF, MR, MV, AI, AS, AF, SI, SS, SF de la Table 3.3. L’utilisation de ces opérateurs permet de générer des applications mutantes qui in-cluent du code représentatif d’un code malveillant. Cependant, l’implémentation de ces opérateurs est plus difficile que pour les deux stratégies précédentes. Il faudra par exemple spécifier les types de paramètres à utiliser pour chaque opérateur, et les intervalles de valeur appropriés pour chacun.