Analisi del dump di memoria e del kernel su sistemi Windows e Unix.

Informatec Digital » Risorse » Analisi del dump di memoria e del kernel su sistemi Windows e Unix.

Quando un sistema operativo va in crash o si blocca in modo spettacolare, l'unico modo per capire cosa è successo è... dump della memoria del kernel e successiva analisiQuesti dump catturano lo stato interno del sistema al momento del guasto e costituiscono la materia prima per il debug di errori complessi, l'indagine su incidenti di sicurezza o lo svolgimento di analisi forensi.

Sebbene possa sembrare un'attività di basso livello, l'analisi di un dump di memoria non è una prerogativa esclusiva degli sviluppatori del kernel. Anche gli amministratori di sistema, i tecnici dell'assistenza e persino i revisori della sicurezza possono trarne vantaggio, a patto che ne conoscano i principi di base. strumenti appropriati, tipologie di dump e tecniche di interpretazione di baseTratteremo l'intero percorso in Windows, Unix/Linux e BSD, utilizzando strumenti come WinDbg, crash, kgdb e LiME.

Che cos'è un dump della memoria del kernel e perché vale la pena analizzarlo?

Un dump della memoria del kernel (spesso chiamato Kernel Crash Dump o semplicemente crash dump) è un file che contiene una copia, totale o parziale, della memoria nel momento in cui il sistema subisce un errore critico, come ad esempio un panico del kernel in Unix/Linux o una schermata blu di errore (BSOD) in Windows.

In pratica, un dump di questo tipo salva strutture interne del kernel, stack di chiamate, contesto di processo e driver caricatiGrazie a ciò, dopo il disastro è possibile effettuare un'analisi "post-mortem", molto simile al debug di un sistema in funzione, ma senza la pressione di dover intervenire su una macchina di produzione mentre è in avaria.

Le ragioni per approfondire i dump del kernel sono molteplici: da eseguire il debug di bug apparentemente casuali e arresti anomali intermittenti...persino indagando se un sistema sia stato manipolato in modo doloso o se un arresto anomalo possa aver lasciato tracce di informazioni sensibili sul disco.

Oltre ai dump completi del kernel, esiste la possibilità di estrarre dump di singoli processi (il classico dump della memoria), che sono molto utili quando ciò che vogliamo è limitare un problema a un'applicazione specifica o valutare l'impatto sulla riservatezza di un servizio come un client di posta elettronica o di messaggistica.

Tipi di dump di memoria in Windows e la loro utilità

Sui sistemi Windows, il sistema operativo stesso può generare diversi tipi di dump quando si verifica un errore STOP. Ogni tipo include un diverso livello di dettaglio, quindi è fondamentale sapere quale utilizzare. Di che tipo di dump abbiamo bisogno in base al problema e ai limiti di spazio su disco?.

Uno dei formati più comuni negli ambienti utente e in molti server è il piccolo dump di memoria (minidump)È quello che occupa meno spazio e di solito si trova in %SystemRoot%\Minidump, con file dello stile MiniMMDDYY-01.dmp.

Questo mini dump contiene informazioni molto specifiche ma importanti: il Codice di errore STOP e relativi parametril'elenco dei driver caricati al momento dell'errore, il contesto del processore che si è arrestato (PRCB), i contesti del processo e del thread coinvolti (strutture EPROCESS e ETHREAD) e lo stack di chiamate in modalità kernel di quel thread.

Grazie a queste strutture di base, anche con un minidump è spesso possibile identificare quale driver o modulo sta causando i crash, sebbene non sarà sempre possibile risalire all'intera origine del problema se questo si trova lontano dal thread in esecuzione al momento del crash. Le informazioni contestuali disponibili sono limitate.

Windows può anche generare dump della memoria del kernel e dump completi molto più grandi che contengono porzioni o tutta la memoria fisica. Questi sono particolarmente utili in Analisi di basso livello, indagini forensi e debug avanzato dei driver o del sistema stesso.

Configurare e aprire i dump di memoria in Windows con WinDbg e KD

Per sfruttare i dump in Windows, la prima cosa da fare è configurare correttamente le opzioni. avvio e ripristinoDal Pannello di controllo, nelle proprietà di sistema avanzate, è possibile scegliere il tipo di dump da generare in caso di errore: ad esempio, il "Dump di memoria ridotto (256 KB)" e il percorso in cui verrà salvato.

Il sistema necessita anche di un file di paging sul volume di avvio di almeno qualche megabyte al fine di scrivere il dump. Nelle versioni moderne di Windows, ogni arresto anomalo crea un nuovo file e la cronologia viene mantenuta nella cartella configurata, consentendo una facile revisione degli incidenti passati.

Una volta generati, esistono diversi modi per verificare che i dump siano corretti. Uno strumento classico è Dumpchk.exeche consente di verificare l'integrità di base del file e di stampare informazioni di riepilogo. Per analisi più avanzate, si utilizzano i seguenti strumenti: Strumenti di debug per Windowsche includono WinDbg (interfaccia grafica) e KD (versione a riga di comando).

Dopo aver installato il pacchetto di debug dal sito Web di Microsoft, gli strumenti si trovano solitamente in una cartella come C:\Programmi\Strumenti di debug per WindowsDa lì possiamo aprire il prompt dei comandi e caricare un dump con WinDbg o KD utilizzando il parametro -z per specificare il file:

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

Il percorso del simbolo può puntare a un server di simboli con cache locale, ad esempio:

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

Mentre il percorso binario è solitamente qualcosa del tipo C:\Windows\I386 o la cartella in cui abbiamo copiato gli eseguibili di sistema corrispondenti alla versione che ha generato il dump. Questo è importante perché I minidump non includono tutti i file binari, solo riferimenti ad essi, quindi il debugger deve essere in grado di trovarli.

Analisi di base di un dump di arresto anomalo del kernel in Windows

Una volta caricato il dump con WinDbg o KD, l'analisi di un dump di crash del kernel è abbastanza simile a una sessione di debug post-mortem. Il primo comando che quasi tutti eseguono è !analizzareche avvia un'analisi automatica e genera un rapporto iniziale.

Il comando !analyze -show mostra il codice di controllo degli errori e relativi parametrimentre !analyze -v Produce un output molto più dettagliato: modulo sospetto, stack di chiamate, informazioni contestuali e, in molti casi, suggerimenti su possibili cause o passaggi diagnostici.

A complemento di tale analisi, il comando .controllo bug Ristampa il codice di errore e i parametri associati, che possono quindi essere confrontati con il Riferimento al codice di controllo bug Da Microsoft per apprendere il significato esatto di ciascun valore e le cause tipiche.

Il comando lm N T (elenco moduli) consente di visualizzare il Elenco dei moduli caricati con percorso, indirizzo e stato.Questo aiuta a confermare se il driver identificato dall'analisi automatizzata è effettivamente presente in memoria e quale sia la sua versione. Questo elenco è particolarmente utile quando si sospetta la presenza di driver di terze parti o componenti di sicurezza che interagiscono con il kernel.

Se lo desideriamo, possiamo semplificare il processo di caricamento del dump creando un file batch Dovrebbe ricevere il percorso del file di dump e avviare KD o WinDbg con i parametri appropriati. In questo modo, è sufficiente scrivere un breve comando che includa il percorso del file e lo script si occuperà di tutto il resto.

Utilizzo di WinDbg per dump approfonditi del kernel.

Per i dump di memoria in modalità kernel, WinDbg offre anche la possibilità di lavorare con più file e sessioni. I dump possono essere aperti dalla riga di comando con -zoppure dall'interfaccia grafica, utilizzando il menu File > Apri dump di memoria o la scorciatoia da tastiera Ctrl + D.

Se WinDbg è già aperto in modalità passiva, è sufficiente selezionare il file nella finestra di dialogo "Apri dump di arresto anomalo", specificando il percorso o navigando sul disco. Una volta caricato, possiamo avviare la sessione con un comando g (Vai) in determinati scenari, oppure avviare direttamente i primi comandi di analisi.

Oltre al classico !analyzeÈ consigliabile familiarizzare con il sezione di riferimento dei comandi del debuggerQuesto documento descrive tutti i comandi disponibili per leggere le strutture interne, esaminare la memoria, interpretare gli stack e molto altro. Molte di queste tecniche sono applicabili sia alle sessioni live che ai dump offline.

WinDbg ti permette anche di lavorare con più dump paralleliPossiamo aggiungere più parametri -z sulla riga di comando, ciascuno seguito da un nome file diverso, oppure aggiungere nuovi target utilizzando il comando .opendumpIl debug di più destinazioni è utile per confrontare errori ricorrenti o incidenti concatenati.

In alcuni ambienti, i dump di memoria vengono impacchettati in file CAB per risparmiare spazio o facilitare la trasmissione. WinDbg può aprire direttamente un .cab con un dump all'interno, sia usando -z che con .opendumpanche se leggerà Verrà estratto solo uno dei file scaricati e non verranno estratti gli altri. che potrebbero essere inclusi nello stesso pacchetto.

Dump di arresto anomalo in Unix e Linux: utilità, strumenti e requisiti

Nei sistemi Unix e GNU/Linux la filosofia è simile, ma l'ecosistema degli strumenti differisce considerevolmente. La maggior parte dei kernel di tipo Unix offre la possibilità di salvare una copia della memoria quando si verifica un evento catastrofico, quello che sappiamo come discarica principale o dump di arresto anomalo del kernel.

Sebbene il loro utilizzo principale rimanga lo sviluppo del kernel e dei driver, questi dump hanno un chiaro aspetto di sicurezza. Un crash può essere causato da errori di programmazione, ma anche azioni dolose Tentativi falliti di manipolare i componenti del sistema o sfruttamento maldestro di condizioni di gara.

In un sistema Unix ben configurato, i crash giornalieri non sono frequenti, ma quando si verificano, è consigliabile avere un piano di backup. infrastrutture di smaltimento come Kdump, LKCD o altre soluzioni che consentono di acquisire la memoria di sistema. Tuttavia, è necessario valutare sia il valore diagnostico del dump sia il rischio che contenga dati altamente sensibili.

Uno degli strumenti più completi e diffusi per questo tipo di analisi in Linux è schiantoInizialmente sviluppata da Red Hat, questa utility è diventata uno standard di fatto per l'esame dei dump del kernel e l'analisi dei sistemi in esecuzione.

Il crash può agire sulla memoria live del sistema attraverso /dev/mem oppure, nelle distribuzioni Red Hat e derivate, utilizzando il dispositivo specifico /dev/crashTuttavia, è prassi comune alimentare lo strumento con un file di dump generato da meccanismi quali Kdump, crea file di dump, Diskdump o dump specifici dell'architettura come s390/s390x o xendump in ambienti virtualizzati.

Il ruolo di crash e l'importanza di vmlinux in Linux

L'utilità crash è stata creata, in parte, per superare le limitazioni dell'utilizzo gdb direttamente su /proc/kcoreTra le altre cose, l'accesso a quella pseudo-immagine di memoria potrebbe essere limitato e, inoltre, alcune opzioni di compilazione del kernel rendono difficile interpretare correttamente le strutture interne se si dispone solo del binario eseguibile compresso.

Affinché crash funzioni correttamente, sono necessari due elementi chiave: un file vmlinux compilato con simboli di debug (di solito con flag come -g) e il dump del kernel stesso. Questa combinazione consente allo strumento di mappare gli indirizzi di memoria a funzioni, strutture e righe di codice.

È importante distinguere tra vmlinux e vmlinuzNella maggior parte dei sistemi è visibile solo vmlinux, che è una versione compressa e avviabile del kernel. Crash richiede il vmlinux decompresso simbolicamente; senza di esso, quando si tenta di caricare un dump o /dev/mem Ci imbatteremo in errori del tipo Impossibile trovare il kernel avviato: inserire l'argomento namelist.

Sebbene sia possibile decomprimere manualmente vmlinuz, il processo non è sempre banale e, in pratica, è solitamente molto più conveniente. Ricompila il kernel per ottenere sia vmlinux che vmlinuz in parallelo. In ambienti amministrativi seri, è buona norma mantenere il vmlinux corrispondente a ciascuna versione del kernel distribuita proprio per questi casi.

Una volta soddisfatti i requisiti, il crash di un dump è relativamente semplice: si specifica il vmlinux e il file di dump appropriati e lo strumento apre una sessione interattiva da cui è possibile attraversa le strutture del kernel, elenca i processi, visualizza gli stack di chiamate ed estrai informazioni forensiChi desidera approfondire ulteriormente l'argomento può consultare documentazione specializzata, come ad esempio il noto white paper tecnico sui crash.

Limitazioni di /dev/mem e primi approcci in Linux

Prima di ricorrere a strumenti specifici, molti amministratori hanno storicamente tentato di ottenere un dump della memoria. lettura diretta dal dispositivo /dev/memQuesto approccio sembrava semplice: utilizzare uno strumento come mem dump (che scarica quel dispositivo su STDOUT) o preleva da dd if=/dev/mem of=volcado.mem.

Tuttavia, i kernel moderni offrono opzioni di compilazione come CONFIG_STRICT_DEVMEMche limitano severamente l'accesso dallo spazio utente a /dev/memIl risultato tipico è che la lettura viene interrotta dopo un piccolo blocco (ad esempio, 1 MB) o, nel caso peggiore, un bug in tale interazione può terminare in un panico del kernel Riavvio immediato della macchina.

Questa protezione ha perfettamente senso dal punto di vista della sicurezza, ma ci costringe a cercare Altri modi per ottenere un dump affidabile e completo senza fare affidamento esclusivamente su dispositivi generici che non sono più accessibili come un tempo.

Pertanto, la tendenza attuale è quella di affidarsi a moduli specifici o infrastrutture integrate per il dump degli arresti anomali, invece di tentare semplicemente di "estrarre dati dalla memoria" con strumenti in spazio utente che non sono progettati per coesistere con le moderne politiche di protezione del kernel.

LiME Forensics: Estrazione della memoria in Linux e Android

Un'alternativa molto potente nel mondo forense è LiME (Linux Memory Extractor)LiME è un modulo del kernel progettato specificamente per acquisire memoria volatile in modo controllato e senza le restrizioni che interessano /dev/mem. LiME viene eseguito nello spazio del kernel, quindi può accedere alla RAM in modo molto più diretto.

LiME viene distribuito con il suo codice sorgente e compila contro il intestazioni del kernel in usoIl processo di compilazione genera un modulo .ko specifico per la versione del kernel in cui verrà caricato. Una volta compilato, possiamo verificarlo con strumenti come file per garantire che il modulo ELF corrispondente alla nostra architettura sia stato generato correttamente.

Per utilizzare LiME, è sufficiente caricare il modulo con insmod dalla radice e passargli le opzioni appropriate, ad esempio specificando un destinazione del dump di rete tramite TCP e formato raw:

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

In parallelo, sulla macchina che riceverà il dump, ci mettiamo in ascolto sulla porta configurata utilizzando uno strumento come ncreindirizzamento dell'output a un file:

nc <IP_origen> 4444 > volcado.mem

Dopo alcuni minuti, a seconda della quantità di RAM e delle prestazioni di rete, avremo un file le cui dimensioni corrispondono alla memoria fisica del sistema sorgente. Questo è un un dump completo della RAM che possiamo analizzare con strumenti forensi o anche con stringhe o altre utilità come primo passo per individuare catene interessanti.

Rischi di dump di processo e di esposizione dei dati

Un dump completo del kernel è estremamente informativo, ma può anche risultare eccessivo quando siamo interessati solo a un processo specifico. In tal caso, ha molto più senso ricorrere a... dump di processo individuali utilizzando strumenti come gcore in Unix/Linux.

Questi dump per processo sono molto più piccoli e gestibili e consentono di concentrare l'analisi su applicazioni specifiche come un client di messaggistica (ad esempio, Skype) o un client di posta elettronica (come Thunderbird), dove è relativamente facile trovare password in chiaro, token di sessione o dati di contatto se vengono esplorate le stringhe di memoria.

Dal punto di vista dello sviluppo, questi core dump aiutano a individuare errori di programmazione, perdite di memoria o stati incoerenti in un servizio. Ma dal punto di vista della sicurezza, il problema sorge quando I dump vengono generati regolarmente e archiviati in posizioni accessibili ad altri utenti.sia sul sistema stesso sia su risorse di rete condivise.

Se un utente pianifica, ad esempio, un'attività cron Catturando periodicamente dump di processi sensibili e lasciandoli in una directory accessibile a tutti, un attaccante apre un'enorme porta all'esposizione di informazioni critiche. In molti scenari di audit, l'analisi di questi file consente a un attaccante di recuperare credenziali, elenchi di contatti, cronologia delle comunicazioni e altri dati privati con uno sforzo relativamente basso.

Pertanto, in qualsiasi audit serio di un sistema Unix, è consigliabile dedicare qualche minuto a verificare se vengono generati dump (completi o parziali), dove vengono memorizzati, quali permessi hanno e se ci sono processo automatizzato che lascia copie di memoria accessibili a utenti non autorizzati.

Analisi post-mortem dei dump in FreeBSD con kgdb

Nel mondo BSD, e in particolare in FreeBSD, l'approccio all'analisi post-mortem prevede Abilita i dump di arresto anomalo sul sistema e fai in modo che il kernel sia compilato con simboli di debug.Questo è controllato dalla directory di configurazione del kernel, solitamente in /usr/src/sys/<arq>/conf.

Nel file di configurazione corrispondente, la generazione dei simboli può essere abilitata con una riga come questa:

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

Dopo aver modificato la configurazione, il kernel deve essere ricompilato. Alcuni oggetti verranno rigenerati (come trap.o) a causa della modifica nei file di build. L'obiettivo è ottenere un kernel con il lo stesso codice di quello che presenta problemi, ma con l'aggiunta delle informazioni di debug necessarieÈ consigliabile confrontare le vecchie e le nuove dimensioni utilizzando il comando size per garantire che non vi siano state modifiche impreviste nel file binario.

Una volta installato il kernel utilizzando i simboli, possiamo ora esaminare i dump con kgdb come descritto nella documentazione ufficiale. Non tutti i simboli potrebbero essere completi e alcune funzioni potrebbero apparire senza numeri di riga o informazioni sugli argomenti, ma nella maggior parte dei casi il livello di dettaglio è sufficiente per individuare il problema.

Non vi è alcuna garanzia assoluta che l'analisi risolverà tutti gli incidenti, ma, in pratica, Questa strategia funziona piuttosto bene in un'alta percentuale di casi.soprattutto quando i dump di arresto anomalo vengono combinati con un'attenta analisi delle recenti modifiche al sistema.

Procedure ottimali per l'analisi e la documentazione degli errori del kernel

Indipendentemente dal sistema operativo, l'analisi del dump del kernel di solito porta a documentazione tecnica, basi di conoscenza, forum specializzati o persino il codice sorgente del kernel stesso per interpretare messaggi, codici di errore e simboli sconosciuti.

In Linux, è molto utile fare affidamento sul codice sorgente ufficiale, sulla documentazione integrata e sulle risorse della community. Molti messaggi di errore del kernel possono essere ricondotti al file esatto da cui hanno origine, il che aiuta a comprendere il problema. contesto in cui viene attivato un BUG() o un WARN() preciso.

In Windows, la documentazione Microsoft, la sua knowledge base (KB) e i forum tecnici forniscono spiegazioni dettagliate di Codici di errore, suggerimenti per la risoluzione e schemi di errore notiCombinando queste informazioni con i report di !analyze -v, è possibile elaborare un piano di mitigazione adeguato.

Il vero valore di un crash dump emerge quando tutte queste informazioni vengono confrontate con solida conoscenza del sistema operativo e dell'ambiente specifico in cui si è verificato il guastoSolo in questo modo si possono proporre soluzioni durature e, soprattutto, evitare che lo stesso problema si ripresenti in futuro con conseguenze più gravi.

L'analisi del dump della memoria del kernel è, in definitiva, una combinazione di scienza e abilità: richiede strumenti appropriati, una configurazione preliminare (simboli, opzioni di dump, archiviazione sicura) e una buona dose di esperienza nella lettura di stack, strutture e codici di errore. Padroneggiare queste tecniche consente non solo di eseguire il debug di incidenti complessi, ma anche per aumentare drasticamente il livello di sicurezza e resilienza dei sistemi che gestiamo.