Gestion de la campagne d’injection

La campagne d’injection est gérée automatiquement à l’aide d’un script GDB, tel que l’exemple donné dans le Listing 4.2.

Ce script correspond à la première version d’instrumentation proposée dans la Section 4.1.3, basée sur des points d’arrêt GDB. L’utilisation de la 2ème version d’instrumentation, basée sur l’insertion d’un code d’instrumentation, permet de simplifier grandement ce script de campagne d’injection d’attaque, puisqu’il n’y a plus qu’un point d’arrêt GDB utilisé pour l’observation.

Ce script est généré automatiquement à l’aide d’un script python, en fonction de la configuration de l’outil. Pour le script présenté ici, les éléments de confi-guration utilisés sont le point d’entrée de l’application, et les points d’observa-tion pour le moniteur de SDA (le service GET_TIME avec l’ID n°1 et le service SEND_QUEUING_MESSAGE avec l’ID n°2). La procédure de restauration et redémarrage du calculateur est enregistrée dans une fonction GDB appelée res-tore_and_restart_module.

Ce script se décompose en trois phases, détaillées par la suite : 1) la déclaration des points d’arrêt, 2) le lancement de la boucle sur les attaques de la liste d’attaques, et 3) la gestion des points d’arrêts pendant une exécution. La suite de la section détaille également la fonctionretrieve_and_inject_attack, utilisée pour injecter une attaque, puis donne un exemple de fichier de log généré à l’aide de ce script.

4.2.4.1 Déclaration des points d’arrêt (lignes 1-7)

Dans un premier temps, le script déclare les points d’arrêt nécessaires pour injecter l’attaque et enregistrer les informations d’observation de l’application. Dans cet exemple, trois points d’arrêt sont déclarés : le point d’entrée de l’application, qui indique le moment où l’attaque sera injectée (APP_ENTRY_POINT), et deux points d’observation pour le moniteur de SDA (les deux services API ARINC 653

1 # 1. Définition des points d'arrêt pour l'observation 2 # APP_ENTRY_POINT 3 b *0x30000000 4 # GET_TIME 5 b *0x10000000 6 # SEND_QUEUING_MESSAGE 7 b *0x20000000 8 # 2. Initialisation

9 # VARIABLES LOCALES POUR LA CAMPAGNE D'INJECTION 10 set $MAX_COUNTER = 4

11 set $current_counter = -1

12 # CONTINUE JUSQU'À ATTEINDRE UN PREMIER POINT D'ARRÊT 13 continue

14 # BOUCLE POUR LANCER LES ATTAQUES AUTOMATIQUEMENT 15 while ($current_counter < $MAX_COUNTER)

16 # 3. Gestion des points d'arrêt

17 if $pc==0x10000000||$pc==0x20000000||$pc==0x30000000||$pc==$addr_attack

18 # RESTAURER ET REDÉMARRER LE CALCULATEUR 19 if $tbl >= $max_duration_tbl

20 set logging off

21 clear *$addr_attack

22 restore_and_restart_module

23 end

24 # APP_ENTRY_POINT (INJECTION DE L'ATTAQUE)

25 if $pc == 0x30000000 26 retrieve_and_inject_attack 27 end 28 # GET_TIME 29 if $pc == 0x10000000 30 printf "1,0x%x\n",$tbl 31 end 32 # SEND_QUEUING_MESSAGE 33 if $pc == 0x20000000 34 printf "2,0x%x\n",$tbl 35 end 36 # EXÉCUTION DE L'ATTAQUE 37 if $pc == $addr_attack 38 printf "ATTACK_LAUNCHED,0x%x\n",$tbl 39 end 40 # CRASH DE L'APPLICATION 41 else

42 # RESTAURER ET REDÉMARRER LE CALCULATEUR

43 set logging off

44 clear *$addr_attack

45 restore_and_restart_module

46 end 47 continue 48 end

4.2. Implémentation de l’outil d’injection 85

dans un fichier de configuration dédié.

4.2.4.2 Lancement de la boucle sur la liste d’attaques (lignes 8-15)

Le nombre d’attaques à lancer est récupéré directement depuis la liste d’attaques et stocké dans une variable $M AX_COU N T ER. Le script déclare également un compteur d’attaque courant, et exécute une boucle sur l’ensemble des attaques de la liste à l’aide de ces deux variables. L’instruction continue de la ligne 13 permet au script de continuer l’exécution de la cible, jusqu’à atteindre un premier point d’arrêt.

4.2.4.3 Gestion des points d’arrêt (lignes 16-48)

Lorsqu’un point d’arrêt est atteint, le script reprend la main. C’est donc la partie de gestion des points d’arrêt qui va s’exécuter. Dans un premier temps, le script vérifie que le point d’arrêt atteint est bien un point prévu (ligne 17). Si ce n’est pas le cas, c’est que l’application a rencontré une exception et ne peut plus continuer son exécution correctement. Le script passe donc à l’attaque suivante (lignes 40-46). Si c’est un point d’arrêt prévu, le script vérifie d’abord la durée de l’expérimen-tation (lignes 18-23). Si la durée maximale définie dans la configuration est atteinte, le script lance la prochaine expérimentation (la prochaine attaque sur la liste).

Sinon, l’expérimentation courante continue, et le script effectue un traitement en fonction du point d’arrêt atteint. Celui-ci est reconnu à l’aide du pointeur d’instruction courante enregistré dans le registre $pc. Si l’on est au point d’en-trée de l’application (lignes 24-27), l’attaque est injectée à l’aide de la fonction

retrieve_and_inject_attack. Si c’est un point d’observation (lignes 28-35), l’infor-mation correspondante est enregistrée avec la valeur du registre$tbl, qui correspond à une valeur d’horloge interne au calculateur. Enfin, un dernier point d’observation (lignes 36-39) permet d’indiquer, dans le fichier de logs, que le code injecté est exécuté.

Enfin, le script redonne la main à la cible avec l’instructioncontinue (ligne 47).

4.2.4.4 Injection de l’attaque (fonction retrieve_and_inject_attack,

ligne 26)

La fonction d’injection de l’attaque génère d’abord un script GDB correspondant à l’attaque courante, en fonction du compteur $current_counter, puis l’exécute. Le code suivant est un exemple d’un tel script GDB :

1 set $current_counter = $current_counter + 1 2 set $addr_attack = 0x40000000

3 b* $addr_attack

4 AI 0x40000000

5 set logging file data_AI-0x40000000.txt

La première ligne met à jour le compteur d’attaques. La deuxième ligne indique l’adresse à laquelle l’attaque est injectée, tandis que la troisième place un point d’arrêt à cet emplacement. Cette adresse est utilisée pour enregistrer un log lorsque le code d’attaque est atteint. La mutation de l’application est réalisée par la ligne 4 (sur cet exemple, l’opérateur AI est utilisé avec un seul paramètre). Enfin, les deux dernières lignes permettent de configurer le fichier de logs correspondant à cette attaque.

4.2.4.5 Fichiers de log générés

Un fichier de logs est généré pour chaque expérimentation réalisée pendant la campagne d’injection. Chaque ligne du fichier correspond à un enregistrement, soit relevé par un point d’observation (ici, ID n°1 et ID n°2), soit par l’exécution du code malveillant (tagATTACK_LAUNCHED). Dans tous les cas, une seule attaque est injectée par expérimentation. S’il y a plusieurs fois le tag ATTACK_LAUNCHED

dans un même fichier de logs, cela signifie que le code malveillant injecté au démar-rage de l’application a été exécuté plusieurs fois pendant une même expérimenta-tion. L’exemple suivant est un extrait de fichier de logs généré suivant le script de campagne décrit dans cette section :

2,0x14b444d2 1,0x14b449da 1,0x14b44fe6 2,0x14b4535d ATTACK_LAUNCHED,0x14b45563 1,0x14b46e06 2,0x14b470cb 2,0x14b47441