Analyse de la mémoire et du noyau sur les systèmes Windows et Unix

Informatec Digital » Ressources » Analyse de la mémoire et du noyau sur les systèmes Windows et Unix

Lorsqu'un système d'exploitation subit un plantage, la seule façon de comprendre ce qui s'est passé est d'obtenir un vidage mémoire du noyau et de l'analyser . Ces vidages capturent l'état interne du système au moment de la panne et sont essentiels pour le débogage d'erreurs complexes, les enquêtes sur les incidents de sécurité et les analyses forensiques.

Bien que cela puisse paraître technique, l'analyse des vidages mémoire n'est pas réservée aux développeurs du noyau. Les administrateurs système, les ingénieurs de support et même les auditeurs de sécurité peuvent en tirer profit s'ils maîtrisent les outils adéquats, les différents types de vidages et les techniques d'interprétation de base . Nous vous guiderons pas à pas dans ce processus sous Windows, Unix/Linux et BSD, à l'aide d'outils tels que WinDbg, crash, kgdb et LiME.

Qu'est-ce qu'un vidage de mémoire du noyau et pourquoi est-il important de l'analyser ?

Un vidage mémoire du noyau (souvent appelé vidage de plantage du noyau ou simplement vidage de plantage ) est un fichier qui contient une copie, complète ou partielle, de la mémoire au moment où le système subit une panne critique, comme un kernel panic sous Unix/Linux ou un écran bleu de la mort (BSOD) sous Windows.

En pratique, un dump de ce type sauvegarde les structures internes du noyau, les piles d'appels, le contexte du processus et les pilotes chargés . Grâce à cela, après un incident, une analyse post-mortem peut être effectuée, très similaire au débogage d'un système en production, mais sans la contrainte d'avoir à intervenir directement sur une machine défaillante.

Les raisons qui poussent à analyser en profondeur les vidages du noyau sont variées : du débogage de bogues apparemment aléatoires et de plantages intermittents , à la recherche de preuves de manipulation malveillante d’un système ou de traces d’informations sensibles laissées par un plantage sur le disque suite à un plantage.

En plus des vidages mémoire complets, il est possible de réaliser des vidages de processus individuels (les vidages mémoire classiques ), qui sont très utiles lorsque l'on souhaite limiter un problème à une application spécifique ou vérifier l'impact sur la confidentialité d'un service tel qu'un client de messagerie électronique ou de messagerie instantanée.

Types de vidages mémoire sous Windows et leur utilité

Sur les systèmes Windows, le système d'exploitation peut générer différents types de fichiers de vidage mémoire en cas d'erreur STOP. Chaque type contient un niveau de détail différent ; il est donc essentiel de savoir quel type de fichier est nécessaire en fonction du problème et des limitations d'espace disque.

L'un des formats les plus courants dans les environnements utilisateurs et sur de nombreux serveurs est le petit vidage mémoire (minidump)C'est celui qui occupe le moins d'espace et qui est généralement situé dans %SystemRoot%\Minidump, avec des fichiers du style MiniMMDDYY-01.dmp.

Ce mini-vidage contient des informations très spécifiques mais importantes : le code d’erreur STOP et ses paramètres , la liste des pilotes chargés au moment de la panne, le contexte du processeur qui s’est arrêté (PRCB), les contextes du processus et du thread impliqués (structures EPROCESS et ETHREAD) et la pile d’appels en mode noyau de ce thread.

Grâce à ces structures de base, même avec un minidump, il est souvent possible d'identifier quel pilote ou module est à l'origine des plantages, bien qu'il ne soit pas toujours possible de suivre toute la piste si le problème provient d'un thread éloigné de celui qui était en cours d'exécution au moment du plantage et que les informations contextuelles disponibles sont limitées.

Windows peut également générer des vidages mémoire du noyau et des vidages complets beaucoup plus volumineux contenant une partie ou la totalité de la mémoire physique. Ces derniers sont particulièrement utiles pour l'analyse de bas niveau, les enquêtes numériques et le débogage avancé des pilotes ou du système lui-même.

Configurer et ouvrir des fichiers de vidage mémoire sous Windows avec WinDbg et KD

Pour exploiter les vidages système sous Windows, la première étape consiste à configurer correctement les options de démarrage et de récupération . Dans le Panneau de configuration, sous Propriétés système avancées, vous pouvez choisir le type de vidage à générer en cas de panne : par exemple, un « Vidage mémoire réduit (256 Ko) », ainsi que le chemin d’accès où il sera enregistré.

Le système requiert également un fichier d'échange d'au moins quelques mégaoctets sur le volume de démarrage pour l'écriture du fichier de vidage. Dans les versions récentes de Windows, chaque plantage crée un nouveau fichier, et un historique est conservé dans le dossier configuré, ce qui facilite la consultation des incidents passés.

Une fois générés, les fichiers de vidage peuvent être validés de plusieurs manières. L'utilitaire classique Dumpchk.exe permet de vérifier l'intégrité de base du fichier et d'afficher un résumé. Pour une analyse plus poussée, on utilise les outils de débogage Windows , notamment WinDbg (interface graphique) et KD (version en ligne de commande).

Après avoir installé le package de débogage depuis le site web de Microsoft, les outils se trouvent généralement dans un dossier tel que C:\Program Files\Debugging Tools for Windows . À partir de là, vous pouvez ouvrir une invite de commandes et charger un fichier de vidage mémoire à l'aide de WinDbg ou KD, en spécifiant le fichier avec le paramètre -z .

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

Le chemin d'accès aux symboles peut pointer vers un serveur de symboles avec mise en cache locale , par exemple :

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

Alors que le chemin binaire ressemble généralement à ceci : C:\Windows\I386 ou le dossier où nous avons copié les exécutables système correspondant à la version qui a généré le vidage. Ceci est important car Les minidumps n'incluent pas tous les fichiers binaires., seulement des références à ces éléments, le débogueur doit donc pouvoir les trouver.

Analyse de base d'un fichier de vidage mémoire suite à un incident du noyau sous Windows

Une fois le fichier de vidage chargé à l'aide de WinDbg ou KD, son analyse s'apparente à une session de débogage post-mortem. La première commande exécutée par la plupart des utilisateurs est `!analyze` , qui lance une analyse automatisée et génère un rapport initial.

La commande !analyze -show montre le Le code de vérification des bogues et ses paramètres, pendant que !analyze -v Il produit un résultat beaucoup plus détaillé : module suspect, pile d’appels, informations contextuelles et, dans de nombreux cas, suggestions sur les causes possibles ou les étapes de diagnostic.

Pour compléter cette analyse, la commande .bugcheck affiche à nouveau le code d'erreur et les paramètres associés, qui peuvent être comparés à la référence des codes de vérification des bogues de Microsoft pour déterminer la signification exacte de chaque valeur et les causes typiques.

La commande lm N T (liste des modules) vous permet de voir le Liste des modules chargés avec leur chemin d'accès, leurs adresses et leur étatCela permet de confirmer si le pilote identifié par l'analyse automatisée est bien présent en mémoire et d'en déterminer la version. Cette liste est particulièrement utile lorsque l'on soupçonne des pilotes tiers ou des composants de sécurité interagissant avec le noyau.

Si nécessaire, nous pouvons simplifier le chargement des fichiers de vidage en créant un fichier batch qui reçoit le chemin d'accès au fichier et lance KD ou WinDbg avec les paramètres appropriés. Ainsi, il suffit d'écrire une courte commande indiquant simplement l'emplacement du fichier, le script se chargeant du reste.

Utilisation de WinDbg pour les analyses approfondies du noyau

Pour les vidages mémoire en mode noyau, WinDbg permet également de travailler avec plusieurs fichiers et sessions. Les vidages peuvent être ouverts en ligne de commande avec l'option -z , ou via l'interface graphique en utilisant le menu Fichier > Ouvrir un vidage mémoire ou le raccourci clavier Ctrl+D.

Si WinDbg est déjà ouvert en mode passif, sélectionnez simplement le fichier dans la boîte de dialogue « Ouvrir un fichier de vidage mémoire », en spécifiant le chemin d'accès ou en parcourant le disque. Une fois le fichier chargé, vous pouvez démarrer la session avec la commande « g » (Go) dans certains cas, ou lancer directement les commandes d'analyse initiales.

En plus du classique !analyzeIl est conseillé de se familiariser avec section de référence des commandes du débogueurCe document décrit toutes les commandes disponibles pour lire les structures internes, examiner la mémoire, interpréter les piles d'exécution, et bien plus encore. Nombre de ces techniques sont applicables aussi bien aux sessions en direct qu'aux sauvegardes hors ligne.

WinDbg vous permet également de travailler avec vidages parallèles multiplesNous pouvons ajouter plusieurs paramètres -z sur la ligne de commande, chacun suivi d'un nom de fichier différent, ou ajouter de nouvelles cibles à l'aide de la commande .opendumpLe débogage de plusieurs destinations est utile pour comparer les pannes récurrentes ou les incidents enchaînés.

Dans certains environnements, les vidages mémoire sont compressés dans des fichiers CAB pour économiser de l'espace ou faciliter leur transmission. WinDbg peut ouvrir directement un tel fichier. .cab avec un vidage à l'intérieur, à la fois en utilisant -z et avec .opendumpbien qu'il lise Il n'extraira qu'un seul des fichiers extraits et n'extraira pas les autres. qui pourrait être inclus dans le même colis.

Fichiers de vidage mémoire sous Unix et Linux : utilitaires, outils et exigences

Sous Unix et GNU/Linux, la philosophie est similaire, mais l'écosystème d'outils diffère considérablement. La plupart des noyaux de type Unix offrent la possibilité de sauvegarder une copie de la mémoire en cas d'incident grave ; on parle alors de vidage mémoire (ou core dump ).

Bien que leur utilisation principale demeure le développement du noyau et des pilotes, ces fichiers de vidage mémoire présentent un intérêt évident en matière de sécurité. Un plantage peut être causé par des erreurs de programmation, mais aussi par des actions malveillantes ratées, des tentatives de manipulation des composants du système ou des exploitations maladroites de conditions de concurrence.

Sur un système Unix bien configuré, les plantages quotidiens sont rares. Toutefois, lorsqu'ils surviennent, il est conseillé de disposer d'une infrastructure de vidage mémoire, comme Kdump, LKCD ou d'autres solutions permettant de capturer la mémoire système. Il est cependant crucial de bien évaluer l'intérêt diagnostique du vidage par rapport au risque qu'il contienne des données hautement sensibles.

L'un des outils les plus complets et les plus utilisés pour ce type d'analyse sous Linux est crash , initialement développé par Red Hat. Cet utilitaire est devenu un standard de facto pour l'examen des vidages mémoire du noyau et l'analyse des systèmes en cours d'exécution.

Un crash peut nuire à la mémoire vive du système via /dev/mem ou, dans Red Hat et les distributions dérivées, en utilisant le périphérique spécifique /dev/crashIl est néanmoins courant d'alimenter l'outil avec un fichier de vidage généré par des mécanismes tels que Kdump, créer un fichier de dump, vidage de disque ou des dumps spécifiques à l'architecture comme s390/s390x ou xendump dans des environnements virtualisés.

Le rôle des plantages et l'importance de vmlinux sous Linux

L'utilitaire de gestion des plantages a été créé, en partie, pour pallier les limitations de son utilisation. gdb directement sur /proc/kcoreEntre autres, l'accès à cette pseudo-image mémoire peut être restreint et, de plus, certaines options de compilation du noyau rendent difficile l'interprétation correcte des structures internes si nous ne disposons que du binaire exécutable compressé.

Pour que crash fonctionne correctement, deux éléments clés sont nécessaires : un fichier vmlinux compilé avec les symboles de débogage (généralement avec des options comme -g) et le vidage du noyau lui-même. Cette combinaison permet à l’outil d’associer les adresses mémoire aux fonctions, structures et lignes de code.

Il est important de distinguer entre vmlinux et vmlinuzSur la plupart des systèmes, seul vmlinux est visible ; il s’agit d’une version compressée et amorçable du noyau. Crash nécessite la décompression symbolique de vmlinux ; sans cela, lors de la tentative de chargement d’un fichier de vidage ou /dev/mem Nous rencontrerons des erreurs du type Noyau de démarrage introuvable — veuillez saisir l'argument namelist.

Bien qu'il soit possible d'extraire manuellement vmlinuz, le processus n'est pas toujours simple et, en pratique, il est souvent bien plus pratique de recompiler le noyau pour obtenir simultanément vmlinux et vmlinuz. Dans les environnements d'administration critiques, il est recommandé de maintenir un paquet vmlinuz distinct pour chaque version de noyau déployée, spécifiquement pour ce type de situation.

Une fois les prérequis remplis, l'exécution de crash sur un fichier de vidage est relativement simple : il suffit de spécifier la version vmlinux et le fichier de vidage appropriés, et l'outil ouvre une session interactive permettant d'explorer la structure du noyau, de lister les processus, de visualiser les piles d'appels et d'extraire des informations d'analyse forensique . Les utilisateurs souhaitant approfondir le sujet peuvent consulter la documentation spécialisée, notamment le livre blanc technique de crash.

Limitations de /dev/mem et premières approches sous Linux

Avant d'avoir recours à des outils spécifiques, de nombreux administrateurs ont historiquement essayé d'obtenir un dump mémoire. lecture directe depuis l'appareil /dev/memCette approche semblait simple : utiliser un outil comme vidage mémoire (qui affiche les données de ce périphérique sur la sortie standard) ou extraites de dd if=/dev/mem of=volcado.mem.

Cependant, les noyaux modernes offrent des options de compilation telles que : CONFIG_STRICT_DEVMEMqui limitent fortement l'accès depuis l'espace utilisateur à /dev/memLe résultat typique est que la lecture est interrompue après un petit bloc (par exemple, 1 Mo) ou, dans le pire des cas, un bug dans cette interaction peut entraîner une erreur. Panique du noyau redémarrage immédiat et de la machine.

Cette protection est parfaitement logique du point de vue de la sécurité, mais elle nous oblige à chercher d'autres moyens d'obtenir une sauvegarde fiable et complète sans dépendre entièrement d'appareils génériques qui ne sont plus aussi accessibles qu'auparavant.

C’est pourquoi la tendance actuelle est de s’appuyer sur des modules spécifiques ou des infrastructures intégrées de vidage mémoire, au lieu de simplement essayer de « récupérer des données en mémoire » avec des outils en espace utilisateur qui ne sont pas conçus pour coexister avec les politiques modernes de protection du noyau.

Analyse forensique LiME : Extraction de mémoire sous Linux et Android

LiME (Linux Memory Extractor) est une alternative très puissante dans le domaine de l'analyse forensique. Ce module noyau est conçu précisément pour capturer la mémoire volatile de manière contrôlée et sans les restrictions qui affectent /dev/mem. LiME s'exécute dans l'espace noyau, ce qui lui permet d'accéder à la RAM beaucoup plus directement.

LiME est distribué avec son code source et se compile par rapport à En-têtes du noyau utilisésLe processus de compilation génère un module .ko spécifique à la version du noyau dans laquelle il sera chargé. Une fois compilé, nous pouvons le vérifier avec des outils tels que file pour s'assurer que le module ELF correspondant à notre architecture a été correctement généré.

Pour utiliser LiME, il suffit de charger le module avec insmod à partir de la racine et lui transmettre les options appropriées, par exemple en spécifiant un Destination de la capture réseau utilisant TCP et un format brut:

insmod lime-3.x.y.ko "path=tcp:4444 format=raw"

En parallèle, sur la machine qui recevra le vidage, nous écoutons sur le port configuré à l'aide d'un outil comme ncrediriger la sortie vers un fichier :

nc <IP_origen> 4444 > volcado.mem

Après quelques minutes, en fonction de la quantité de RAM et des performances du réseau, nous obtiendrons un fichier dont la taille correspondra à la mémoire physique du système source. Il s'agit d'un dump RAM complet que nous pourrons analyser avec des outils d'analyse forensique, voire avec des utilitaires comme strings, afin de repérer des chaînes de caractères intéressantes.

Risques liés aux vidages de données et à l'exposition des données

Un vidage complet du noyau est extrêmement instructif, mais peut aussi s'avérer superflu lorsqu'on ne s'intéresse qu'à un processus spécifique. Dans ce cas, il est judicieux d'utiliser… dumps de processus individuels en utilisant des outils comme gcore sous Unix/Linux.

Ces fichiers de vidage par processus sont beaucoup plus petits et plus faciles à gérer, et vous permettent de concentrer votre analyse sur des applications spécifiques telles qu'un client de messagerie (par exemple, Skype) ou un client de messagerie électronique (par exemple, Thunderbird), où il est relativement facile de trouver des mots de passe en clair, des jetons de session ou des données de contact en explorant les chaînes de mémoire.

Du point de vue du développement, ces fichiers de vidage mémoire permettent de localiser les erreurs de programmation, les fuites de mémoire ou les états incohérents d'un service. Toutefois, du point de vue de la sécurité, le problème survient lorsque ces fichiers sont générés régulièrement et stockés à des emplacements accessibles à d'autres utilisateurs , que ce soit sur le système lui-même ou sur des ressources réseau partagées.

Si un utilisateur planifie, par exemple, une tâche cron En capturant périodiquement des copies de processus sensibles et en les laissant dans un répertoire accessible à tous, un attaquant ouvre une brèche importante vers la divulgation d'informations critiques. Dans de nombreux scénarios d'audit, l'analyse de ces fichiers permet à un attaquant de récupérer des données. identifiants, listes de contacts, historiques de communication et autres données privées avec un effort relativement faible.

Par conséquent, lors de tout audit sérieux d'un système Unix, il est conseillé de consacrer quelques minutes à vérifier si des dumps (complets ou partiels) sont générés, où ils sont stockés, quelles permissions ils possèdent et s'il existe un processus automatisé qui laisse des copies en mémoire à la portée d'utilisateurs non autorisés.

Analyse post-mortem des vidages mémoire sous FreeBSD avec kgdb

Dans l'univers BSD, et plus particulièrement dans FreeBSD, l'approche de l'analyse post-mortem implique Activez les vidages sur incident sur le système et assurez-vous que le noyau est compilé avec les symboles de débogage.Ceci est contrôlé depuis le répertoire de configuration du noyau, généralement dans /usr/src/sys/<arq>/conf.

Dans le fichier de configuration correspondant, la génération de symboles peut être activée avec une ligne comme celle-ci :

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols

Après modification de la configuration, le noyau doit être recompilé. Certains objets seront régénérés (tels que trap.o) en raison de la modification des fichiers de compilation. L'objectif est d'obtenir un noyau avec le même code que celui qui pose problème, mais avec l'ajout des informations de débogage nécessairesIl est conseillé de comparer les anciennes et les nouvelles tailles à l'aide de la commande size pour s'assurer qu'aucun changement inattendu n'est survenu dans le fichier binaire.

Une fois le noyau avec ses symboles installé, nous pouvons examiner les fichiers de vidage avec kgdb , comme indiqué dans la documentation officielle. Il est possible que certains symboles soient incomplets et que certaines fonctions apparaissent sans numéro de ligne ni information sur leurs arguments, mais dans la plupart des cas, le niveau de détail est suffisant pour identifier le problème.

Il n'existe aucune garantie absolue que l'analyse résolve tous les incidents, mais en pratique, cette stratégie fonctionne assez bien dans un pourcentage élevé de scénarios , surtout lorsque les fichiers de vidage mémoire sont combinés à un examen approfondi des modifications récentes apportées au système.

Meilleures pratiques pour l'analyse et la documentation des erreurs du noyau

Quel que soit le système d'exploitation, l'analyse des vidages du noyau finit généralement par se référer à la documentation technique, aux bases de connaissances, aux forums spécialisés, voire au code source du noyau lui-même pour interpréter les messages, les codes d'erreur et les symboles inconnus.

Sous Linux, il est très utile de se référer à l'arborescence du code source officiel, à la documentation intégrée et aux ressources de la communauté. De nombreux messages d'erreur du noyau peuvent être rattachés au fichier exact dont ils proviennent, ce qui permet de comprendre le contexte dans lequel un BUG() ou un WARN() particulier est déclenché.

Sous Windows, la documentation Microsoft, sa base de connaissances (KB) et les forums techniques fournissent des explications détaillées des codes d'erreur, des recommandations de dépannage et des schémas d'erreurs connus . En combinant ces informations avec les rapports de la commande !analyze -v, il est possible d'élaborer un plan d'atténuation adapté.

La véritable valeur d'un fichier de vidage mémoire se révèle lorsque toutes ces informations sont recoupées avec une solide compréhension du système d'exploitation et de l'environnement spécifique où la panne s'est produite . Ce n'est qu'ainsi que des solutions durables peuvent être élaborées et, surtout, que le même problème peut être empêché de se reproduire à l'avenir, avec des conséquences plus graves.

L'analyse des vidages de noyau est un savant mélange de science et de savoir-faire : elle requiert des outils adaptés, une configuration préalable (symboles, options de vidage, stockage sécurisé) et une solide expérience de la lecture des piles d'appels, des structures et des codes d'erreur. La maîtrise de ces techniques nous permet non seulement de déboguer des incidents complexes, mais aussi d'améliorer considérablement la sécurité et la résilience des systèmes que nous gérons.