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 se bloque ou plante de manière spectaculaire, la seule façon de comprendre ce qui s'est passé est de... vidage de la mémoire du noyau et analyse subséquenteCes fichiers de vidage capturent l'état interne du système au moment de la panne et constituent la matière première pour le débogage d'erreurs complexes, l'enquête sur les incidents de sécurité ou la réalisation d'examens médico-légaux.

Bien que cela puisse paraître très technique, l'analyse d'un vidage mémoire n'est pas réservée aux développeurs de noyau. Les administrateurs système, les ingénieurs de support et même les auditeurs de sécurité peuvent en tirer profit s'ils en maîtrisent les principes de base. outils appropriés, types de vidages et techniques d'interprétation de baseNous aborderons l'intégralité de ce processus sous Windows, Unix/Linux et BSD, en utilisant des 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 de la mémoire du noyau (souvent appelé Vidage mémoire du noyau ou simplement vidage mémoireUn fichier RDS (Record Data File) est un fichier contenant une copie, totale ou partielle, de la mémoire au moment où le système subit une défaillance critique, telle qu'une panne. Panique du noyau sous Unix/Linux ou un écran bleu de la mort (BSOD) sous Windows.

En pratique, une sauvegarde de ce type permet d'économiser structures internes du noyau, piles d'appels, contexte du processus et pilotes chargésGrâce à cela, après la catastrophe, une analyse « post-mortem » peut être effectuée, très similaire au débogage d'un système en production, mais sans la pression d'avoir à intervenir directement sur une machine en production pendant sa panne.

Les raisons d'analyser en profondeur les vidages du noyau sont variées : de Déboguer des bugs apparemment aléatoires et des plantages intermittents...voire enquêter pour savoir si un système a été manipulé de manière malveillante ou si un plantage a pu laisser des traces d'informations sensibles sur le disque.

Outre les dumps complets du noyau, il est possible d'extraire des dumps de processus individuels (le classique). fichiers de vidage de mémoire), qui sont très utiles lorsque ce que nous voulons est limiter un problème à une application spécifique ou examiner l'impact sur la confidentialité d'un service comme un client de messagerie électronique ou 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 lesquels utiliser. De quel type de fichier de vidage avons-nous besoin 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-fichier contient des informations très spécifiques mais importantes : 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 retracer l'intégralité du problème s'il provient d'un thread éloigné de celui qui s'exécutait au moment du plantage. 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. Ceux-ci sont particulièrement utiles dans analyse de bas niveau, enquêtes numériques et 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 tirer parti des dumps sous Windows, la première chose à faire est de configurer correctement les options. démarrage et repriseDans le Panneau de configuration, dans les propriétés système avancées, vous pouvez choisir le type de vidage que vous souhaitez générer en cas de panne : par exemple, le « Petit vidage mémoire (256 Ko) » et le chemin où il sera stocké.

Le système a également besoin d'un fichier d'échange sur le volume de démarrage d'au moins quelques mégaoctets Pour générer le fichier de vidage mémoire, il faut, dans les versions récentes de Windows, créer un nouveau fichier à chaque plantage. Un historique est conservé dans le dossier configuré, ce qui facilite la consultation des incidents passés.

Une fois générés, il existe plusieurs façons de vérifier l'exactitude des fichiers de vidage. Un outil classique est : Dumpchk.exequi permet de vérifier l'intégrité de base du fichier et d'imprimer un résumé. Pour une analyse plus poussée, les outils suivants sont utilisés : Outils de débogage pour Windowsqui incluent 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 comme C:\Program Files\Debugging Tools for WindowsÀ partir de là, nous pouvons ouvrir une invite de commandes et charger un fichier de vidage avec WinDbg ou KD en utilisant le paramètre -z pour spécifier le fichier :

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

Le chemin du symbole peut pointer vers un serveur de symboles avec cache local, 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é avec WinDbg ou KD, l'analyse d'un vidage mémoire suite à un plantage du noyau est assez similaire à une session de débogage post-mortem. La première commande exécutée par presque tous les utilisateurs est : !analyser, qui lance une analyse automatique 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, le commandement .bugcheck Il réimprime le code d'erreur et les paramètres associés, qui peuvent ensuite être comparés avec le Référence du code de vérification d'erreur Consultez la documentation Microsoft pour connaître la signification exacte de chaque valeur et ses 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 vous le souhaitez, nous pouvons simplifier le processus de chargement des déchets en créant un fichier de commandes Il devrait recevoir le chemin d'accès au fichier de vidage et lancer KD ou WinDbg avec les paramètres appropriés. Ainsi, il vous suffit d'écrire une courte commande indiquant l'emplacement du fichier, et le script se charge du reste.

Utilisation de WinDbg pour les analyses approfondies du noyau

Pour les vidages mémoire en mode noyau, WinDbg offre également la possibilité de travailler avec plusieurs fichiers et sessions. Les vidages peuvent être ouverts depuis la ligne de commande avec -zou depuis l'interface graphique, en utilisant le menu Fichier > Ouvrir un fichier de 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 le fichier de vidage sur incident », 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 une commande. g (Go) dans certains scénarios, ou lancer directement les premières commandes d'analyse.

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 Sauvegardez une copie de la mémoire lorsqu'un événement catastrophique se produit., ce que nous savons comme vidage de base ou vidage mémoire suite à un incident du noyau.

Bien que leur utilisation principale reste le développement du noyau et des pilotes, ces fichiers de vidage présentent un aspect de sécurité évident. Un plantage peut être provoqué par erreurs de programmation, mais aussi actions malveillantes tentatives infructueuses de manipulation des composants du système ou exploitation maladroite de conditions de concurrence.

Dans un système Unix bien configuré, les pannes quotidiennes sont rares, mais lorsqu'elles surviennent, il est judicieux de prévoir un plan de sauvegarde. infrastructure de vidage telle que Kdump, LKCD ou autres solutions qui permettent de capturer la mémoire système. Cependant, il est nécessaire de mettre en balance la valeur diagnostique du vidage et le risque qu'il contienne des données hautement sensibles.

L'un des outils les plus complets et les plus répandus pour ce type d'analyse sous Linux est crashInitialement développé par Red Hat, cet utilitaire est devenu un standard de facto pour l'examen des vidages de 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 des 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 des adresses mémoire à des fonctions, des structures et des 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 de décompresser manuellement vmlinuz, le processus n'est pas toujours simple et, en pratique, il est généralement beaucoup plus pratique d'utiliser une autre méthode. Recompilez le noyau pour obtenir à la fois vmlinux et vmlinuz En parallèle, dans les environnements d'administration critiques, il est recommandé de maintenir le vmlinux correspondant à chaque version de noyau déployée, précisément pour ces cas de figure.

Une fois les conditions requises remplies, provoquer un plantage à partir d'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 à partir de laquelle vous pouvez… parcourir les structures du noyau, lister les processus, visualiser les piles d'appels et extraire des informations médico-légalesCeux qui souhaitent approfondir le sujet peuvent consulter une documentation spécialisée, telle que le célèbre livre blanc technique sur les incidents de sécurité.

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 à rechercher 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

Une alternative très puissante dans le monde médico-légal est LiME (Extracteur de mémoire Linux)LiME est un module noyau conçu spécifiquement 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 aurons un fichier dont la taille correspond à la mémoire physique du système source. Il s'agit d'un un dump RAM complet que nous pouvons analyser avec des outils d'analyse forensique, voire avec des chaînes de caractères ou d'autres utilitaires. comme première étape pour repérer les chaînes 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 l'analyse sur des applications spécifiques telles qu'un client de messagerie (par exemple, Skype) ou un client de messagerie électronique (tel que Thunderbird), où il est relativement facile de trouver mots de passe en clair, jetons de session ou données de contact si les chaînes de mémoire sont explorées.

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. Mais du point de vue de la sécurité, le problème se pose lorsque Les fichiers de vidage sont générés régulièrement et stockés dans des emplacements accessibles aux autres utilisateurs.soit sur le système lui-même, soit 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, quels sont leurs droits d'accès et s'il en existe. processus automatisé qui laisse des copies de mémoire accessibles aux 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 installé à l'aide de symboles, nous pouvons maintenant examiner les fichiers de vidage avec kgdb Comme indiqué dans la documentation officielle. Il se peut 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 permettra de résoudre 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 à une bonne analyse des modifications récentes du 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 aboutit généralement à la documentation technique, les bases de connaissances, les forums spécialisés, voire le 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 facilite la compréhension du problème. contexte dans lequel un BUG() ou un WARN() est déclenché déterminé.

Sous Windows, la documentation Microsoft, sa base de connaissances (KB) et les forums techniques fournissent des explications détaillées sur Codes d'erreur, recommandations de résolution et schémas d'erreur connusEn combinant ces informations avec les rapports !analyze -v, il est possible d'élaborer un plan d'atténuation raisonnable.

La véritable valeur d'un fichier de vidage mémoire apparaît lorsque toutes ces informations sont recoupées avec une solide connaissance du système d'exploitation et de l'environnement spécifique dans lequel la panne s'est produiteC’est la seule façon de proposer des solutions durables et, surtout, d’empêcher que le même problème ne se reproduise à l’avenir avec des conséquences plus graves.

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