Le gestionnaire des interruptions

Les kprobes

Kprobes est un mécanisme développé par les chercheurs d’IBM et a été introduit à la version du noyau Linux 2.6.9. Ce mécanisme permet l’exécution d’un gestionnaire du code arbitraire à n’importe quel point, durant l’exécution du noyau. Depuis que les gestionnaires des sondes sont écrits dans les modules du noyau, le privilège root s’avère indisponible pour exploiter ce service. Ce mécanisme est extrêmement utile pour le débogage de certaines parties spécifiques du noyau. De cette manière, le débogage sera effectué sans avoir besoin de recompiler et de redémarrer le système. Ceci présente un gain considérable de temps et du coût du développement. En plus, kprobes offre un meilleur support pour la traçabilité du noyau et une meilleure évaluation de ses performances (Ramaswamy, 2008). Kprobes faisait partie de l’outil Dprobes qui est un outil de traçage de haut niveau. Ce mécanisme constitue une interface qui permet l’insertion dynamique des points d’instrumentation dans le noyau lors de son exécution. Le principe de kprobes consiste à associer un événement à une adresse dans le code du noyau.

Une fois l’exécution atteint cette adresse, l’événement sera déclenché. Kprobes permet d’associer une fonction à un événement. Cette fonction s’exécute à chaque déclenchement de l’événement qui lui est associé. kprobes présente trois types de points de traçage du noyau : les kprobes ordinaires, les kretprobes et les jprobes. Les kprobes ordinaires s’insèrent dans n’importe quelle routine du noyau et elles peuvent associer deux fonctions pour chaque évènement. La première fonction est exécutée avant l’instruction, qui se situe à l’adresse du point d’instrumentation, elle est appelée pre_handler. La deuxième fonction est exécutée après cette instruction, cette fonction est appelée post_handler. Quand les deux fonctions sont appelées, une structure de type pt_regs, contenant une copie de l’état de tous les registres au moment où l’événement est déclenché, leur est passée. Ce type de structure change de contenu quand l’architecture change. La spécificité des kretprobes est que ce type de kprobes est enregistré aux points de retour des fonctions. Les jprobes, à l’inverse des kretprobes, ont la possibilité de s’associer aux points d’entrée des fonctions du noyau. Ceci a pour but de collecter les arguments de ces fonctions. Plusieurs outils récents, de traçage noyau, utilisent les kprobes tels que : Ftrace, LTTng et SystemTap (Fahem, 2012).

Cycle de vie d’un processus

Chaque processus a son propre cycle de vie tel que la création, l’exécution, la terminaison et la suppression. Ces phases seront répétées des millions de fois tant que le système est en cours d’exécution. Le processus père déclenche un appel système fork () pour créer un processus fils. Quand un appel système fork () est exécuté, il obtient un descripteur du processus fils crée et détermine son id. Il copie les valeurs de descripteur du processus père au processus fils. L’espace d’adresse du processus père n’est pas entièrement copié. L’appel système exec() copie le nouveau programme à l’espace d’adresse du processus fils. Puisque les deux processus père et fils partagent le même espace d’adresse, une écriture des données du nouveau programme cause une exception de défaut de page. À ce stade, le noyau attribue la nouvelle page physique au processus fils. Après la terminaison de l’exécution du programme, le processus fils se termine avec un appel système exit(). Cet appel système libère la plupart des structures de données du processus fils et notifie le processus père de sa terminaison par un signal. Le processus à cet état est appelé processus zombie. Le processus fils ne sera pas complètement éliminé jusqu’à ce que le processus père soit notifié de la terminaison de tous ses fils. Ceci est accompli à l’aide de l’appel système wait(). Une fois qu’il sera notifié de la terminaison de tous ses fils il supprime toute la structure de données du processus fils et libère le descripteur de processus (Ciliendo et Kunimasa, 2007).

Le gestionnaire des interruptions

La gestion des interruptions est une des tâches les plus prioritaires d’un système d’exploitation. Les interruptions sont générées par les périphériques d’entrées/sorties du système. Le gestionnaire d’interruption informe le noyau Linux de l’interception d’un événement comme la saisie au clavier, arrivée de trame Ethernet et autres. Il indique au noyau d’interrompre l’exécution des processus et d’effectuer la gestion des interruptions aussi rapidement que possible parce que certains dispositifs nécessitent une réactivité rapide. Cela est essentiel pour la stabilité du système. Quand un signal d’interruption est intercepté, par le noyau, ce dernier doit passer du processus en cours d’exécution à un nouveau processus pour gérer cette interruption. Cela signifie que les interruptions provoquent le changement de contexte. Un grand nombre d’interruptions pourraient causer une dégradation des performances du système. Il existe deux types d’interruptions dans les implémentations Linux. Le premier type est les interruptions matérielles. Une interruption matérielle est générée pour les dispositifs qui exigent une réactivité (E / S disque interruption, interruption de la carte réseau, clavier interruption, interruption de la souris). Les informations des interruptions matérielles sont localisées sous /proc/interrupts. Le deuxième type est les interruptions logicielles. Une interruption logicielle est utilisée pour des tâches dont le traitement peut être différé (c.à.d comme les opérations TCP / IP, les opérations du protocole SCSI, etc.). Dans un environnement multiprocesseur, les interruptions sont gérées par chaque processeur. Cette approche améliore la performance du système (Ciliendo et Kunimasa, 2007).

Les méthodes d’injection en espace noyau

Utilisation des modules noyaux Cette méthode est utilisée pour l’insertion des modules noyaux dans l’espace noyau. Elle nécessite que le support LKM par le noyau soit activé (Lacombe, Raynal et Nicomette, 2007). Ce support permet l’insertion et la suppression des modules noyaux en cours d’exécution, ce qui permet aux utilisateurs de modifier les fonctionnalités du noyau sans avoir besoin de recompiler et de redémarrer le système. Au début de sa création, cette technique avait pour but de faciliter la manipulation des pilotes de périphériques, des pilotes du système de fichier, les appels systèmes, etc. Les modules noyaux sont insérés, en utilisant la commande insmod qui est un utilitaire qui insère les modules noyaux, peu importe sa localisation ou l’utilisation de la commande modprobe. Cette dernière nécessite que les modules à insérer soient localisés dans le répertoire / lib/modules. Les attaquants ont bénéficié de cette simplicité d’utilisation du support LKM pour cacher leurs activités malicieuses, mais avant ça ils doivent obtenir le privilège root. La nécessité de localisation des modules noyaux dans le répertoire /lib/modules constitue le point faible de l’utilisation de l’utilitaire modprobe. Ces modules seront facilement détectés. Pour cette raison, les attaquants préfèrent l’utilisation de l’utilitaire de l’insmod.

D’autres utilitaires du support LKM peuvent divulguer des informations importantes sur le système. Lsmod liste les modules noyaux en cours d’exécution sur un système (Vandeven, 2014). Accès à la mémoire noyau via le périphérique virtuel /dev/kmem et via dev/mem Cette méthode consiste à utiliser le fichier spécial /dev/kmem pour l’injection des rootkits noyaux. Ce fichier pointe vers une image de l’espace mémoire du kernel en cours d’exécution. Un attaquant peut modifier en utilisant cette technique le noyau en cours d’exécution une fois que le support /dev/kmem est activé (Vandeven, 2014). Ce genre de technique ne persiste pas lors d’un redémarrage du système. Cette technique peut être efficace dans des systèmes où leurs redémarrages sont peu fréquents comme les serveurs. Un des exemples de rootkits le plus connu, qui utilise cette technique, est le rootkit SuckIT (Super user control kit). Ce rootkit remplace la référence à la table des appels systèmes par une autre qui pointe vers une nouvelle table qui contient les appels systèmes contenant le code malicieux. La table originale des appels système reste chargée en mémoire sans subir aucune modification. Cette approche rend la détection de ce genre de rootkit très difficile (Shah et Giffin, 2008). L’utilisation d’accès à la mémoire physique dev/mem, pour charger le rootkit, est similaire à celui de /dev/kmem. Mais ce fichier spécial représente non seulement la mémoire du noyau, mais il représente aussi l’image entière de la mémoire physique (Lineberry, 2009; Vandeven, 2014).

Table des matières

INTRODUCTION
1.1 Contexte
1.2 Définition du problème
1.2.1 Étape 1
a) Quels sont les mécanismes liés au noyau, au rootkit et à l’apprentissage automatique?
b) Quelles sont les méthodes d’analyse et les approches de détections des rootkits?
1.2.2 Étape 2 : Comment sélectionner la méthode d’analyse et de détection de rootkits adéquate à l’outil LTTng ?
1.2.3 Étape 3 : Quel serait l’algorithme d’apprentissage le plus efficace dans la détection des attaques spécifiées par les expérimentations?
1.3 Questions de recherche
1.4 Méthodologie de recherche
1.5 Organisation du rapport
CHAPITRE 1 LES ASPECTS FONDAMENTAUX LIÉS À LA DÉTECTION DES ROOTKITS
1.1 Introduction
1.2 Le système d’exploitation Linux
1.2.1 Le noyau Linux
1.2.2 Les modules du noyau Linux
1.2.3 Les appels systèmes
1.2.4 Les kprobes
1.2.5 La gestion des processus sous Linux
1.2.6 Le gestionnaire des interruptions
1.2.7 L’architecture mémoire Linux
1.2.8 Les systèmes de fichiers Linux
1.2.9 Les mesures de performances Linux
1.2.10 Le traçage
1.3 Les rootkits
1.3.1 C’est quoi un rootkit
1.3.2 La notion du ring
1.3.3 Le cycle de vie d’un rootkit
1.3.4 Les classes des rootkits
1.3.5 Les méthodes d’injection en espace noyau
1.3.6 Les méthodes du détournement
1.3.7 Méthodes de communication avec un rootkit
1.4 Les machines d’apprentissage
1.4.1 Les types d’apprentissages
1.4.2 L’apprentissage supervisé
1.4.3 Les mesures d’évaluation et de la classification
1.4.4 Évaluation des algorithmes d’apprentissages supervisés
1.4.5 La sélection des caractéristiques d’un vecteur d’entrée
1.4.6 Les méthodes de comparaison entre différents algorithmes de classifications
1.5 Conclusion
CHAPITRE 2 REVUE DE LITTÉRATURE SUR LES MÉTHODES D’ANALYSE ET DE DÉTECTION DES ROOTKITS
2.1 Introduction
2.2 Méthodes d’analyse
2.2.1 Analyse statique
2.2.2 Analyse dynamique
2.3 Méthodes de détection
2.3.1 Détection basée sur les signatures
2.3.2 Détection basée sur le comportement
2.3.3 Détection basée sur la vérification d’intégrité
2.3.4 Détection basée sur le crossview
2.3.5 Détection basée sur la sémantique
2.3.6 Détection basée sur les heuristiques
2.4 Conclusion
CHAPITRE 3 APPROCHES D’ANALYSE ET DE DÉTECTION DES ROOTKITS BASÉES SUR LTTNG
3.1 Introduction
3.2 Méthode d’analyse
3.3 Les approches de détection
3.3.1 Détection par algorithmes d’apprentissage automatique
3.3.2 Détection par extension du traceur LTTng
3.4 Champs d’application des approches de détection proposées
3.5 Conclusion
CHAPITRE 4 EXPÉRIMENTATION ET VALIDATION DE L’APPROCHE BASÉE SUR L’APPRENTISSAGE AUTOMATIQUE
4.1 Introduction
4.2 Les choix techniques utilisés dans les expérimentations proposées
4.2.1 Expérimentation basée sur l’attaque par la modification des appels systèmes du Suterusu
4.2.2 Expérimentation basé sur l’attaque par le détournement des appels systèmes du Kbeast
4.2.3 Expérimentation basée sur l’attaque par la dissimulation de processus du Suterusu
4.2.4 La validation du choix de l’algorithme le plus adéquat sur les multiples ensembles de données
4.3 Conclusion et perspectives
4.4 Limite de cette recherche
CONCLUSION GÉNÉRALE
BIBLIOGRAPHIE

Télécharger le rapport complet