Memóriakiírás és kernel elemzés Windows és Unix rendszereken

Informatec Digital » Erőforrás » Memóriakiírás és kernel elemzés Windows és Unix rendszereken

Amikor egy operációs rendszer pánikba esik vagy összeomlik, az egyetlen módja annak, hogy megértsük, mi történt, egy kernel memóriakép elemzése . Ezek a memóriaképek rögzítik a rendszer belső állapotát a hiba pillanatában, és elengedhetetlenek az összetett hibák hibakereséséhez, a biztonsági incidensek kivizsgálásához vagy a kriminalisztikai vizsgálatok elvégzéséhez.

Bár ez nagyon „alacsony szintűnek” tűnhet, a memóriakép-elemzés nem kizárólag a kernelfejlesztők sajátja. Rendszergazdák, támogató mérnökök és még biztonsági auditorok is profitálhatnak belőle, ha ismerik a megfelelő eszközöket, a különböző típusú memóriaképeket és az alapvető értelmezési technikákat . Mindezt végigvezetjük Windows, Unix/Linux és BSD rendszereken, olyan eszközök használatával, mint a WinDbg, a crash, a kgdb és a LiME.

Mi az a kernel memória kiírás és miért érdemes elemezni?

A kernel memóriakép (gyakran Kernel Crash Dump-nak vagy egyszerűen crash dump-nak nevezik ) egy olyan fájl, amely a memória teljes vagy részleges másolatát tartalmazza abban az időpontban, amikor a rendszer kritikus hibát szenved, például kernel pánik esetén Unix/Linux rendszerben vagy kék képernyő esetén (BSOD) Windows rendszerben.

A gyakorlatban egy ilyen típusú dump elmenti a belső kernel struktúrákat, a hívásvermeket, a folyamatkontextust és a betöltött illesztőprogramokat . Ennek köszönhetően a katasztrófa után egy utólagos elemzés végezhető el, amely nagyon hasonlít egy élő rendszer hibakereséséhez, de anélkül, hogy a termelési gép meghibásodása közben nyomást gyakorolnánk rá.

A kernel dumpok mélyreható vizsgálatának okai változatosak lehetnek: a látszólag véletlenszerű hibák és időszakos összeomlások hibakeresésétől kezdve egészen addig, hogy kivizsgáljuk, vajon a rendszert rosszindulatúan manipulálták-e, vagy hogy egy összeomlás hagyott-e érzékeny információk nyomait a lemezen.

A teljes memóriaképek mellett lehetőség van egyedi folyamatokról is másolatot készíteni (a klasszikus memóriaképek ), amelyek nagyon hasznosak, ha egy problémát egy adott alkalmazásra szeretnénk korlátozni, vagy ha ellenőrizni szeretnénk egy szolgáltatás, például egy e-mail vagy üzenetküldő kliens bizalmasságára gyakorolt ​​​​hatását.

A memóriaképek típusai Windows rendszerben és azok hasznossága

Windows rendszereken maga az operációs rendszer különböző típusú memóriaképeket generálhat STOP hiba esetén. Mindegyik típus más részletességi szintet tartalmaz, ezért kulcsfontosságú tudni, hogy milyen típusú memóriaképre van szükség a probléma és a lemezterület korlátai alapján.

Az egyik leggyakoribb formátum a felhasználói környezetekben és számos szerveren a kis memóriakép (minidump)Ez az, amelyik a legkevesebb helyet foglalja el, és általában itt található: %SystemRoot%\Minidump, a stílus fájljaival MiniHHNNÉÉ-01.dmp.

Ez a mini dump nagyon specifikus, de fontos információkat tartalmaz: a STOP hibakódot és paramétereit , a hiba idején betöltött illesztőprogramok listáját, a leállított processzor kontextusát (PRCB), az érintett folyamat és szál kontextusait (EPROCESS és ETHREAD struktúrák), valamint az adott szál kernel módú hívásvermét.

Ezeknek az alapvető struktúráknak köszönhetően még egy minidump segítségével is gyakran azonosítható, hogy melyik illesztőprogram vagy modul okozza az összeomlásokat, bár nem mindig lehetséges a teljes nyomvonalat követni, ha a probléma távol származik attól a száltól, amely az összeomlás idején futott, és a rendelkezésre álló kontextusinformációk korlátozottak.

A Windows képes kernel memóriaképeket és sokkal nagyobb teljes memóriaképeket is létrehozni, amelyek a fizikai memória egy részét vagy egészét tartalmazzák. Ezek különösen hasznosak alacsony szintű elemzéshez, kriminalisztikai vizsgálatokhoz, valamint illesztőprogramok vagy maga a rendszer speciális hibakereséséhez.

Memóriadumpok konfigurálása és megnyitása Windows rendszerben WinDbg és KD segítségével

A Windows rendszerben a rendszermemória-fájlok előnyeinek kihasználásához az első lépés az indítási és helyreállítási beállítások megfelelő konfigurálása . A Vezérlőpulton, a speciális rendszertulajdonságok között kiválaszthatja a hiba esetén létrehozni kívánt memóriakép típusát: például egy „Kis memóriakép (256 KB)”, és a tárolási elérési utat.

A rendszernek legalább néhány megabájtos lapozófájlra is szüksége van a rendszerindító köteten a memóriakép írásához. A Windows modern verzióiban minden összeomlás új fájlt hoz létre, és a beállított mappában tárolódik az előzmények, lehetővé téve a korábbi incidensek egyszerű áttekintését.

A létrehozás után számos módon ellenőrizhető a memóriaképek helyessége. Egy klasszikus segédprogram a Dumpchk.exe , amely lehetővé teszi a fájl alapvető integritásának ellenőrzését és az összegző információk kinyomtatását. A fejlettebb elemzéshez a Windows hibakereső eszközeit használják , beleértve a WinDbg-t (grafikus felület) és a KD-t (parancssori verzió).

A hibakereső csomag Microsoft webhelyéről történő telepítése után az eszközök jellemzően egy olyan mappában találhatók, mint például a C:\Program Files\Debugging Tools for Windows . Innen megnyithat egy parancssort, és betölthet egy memóriaképfájlt a WinDbg vagy a KD segítségével, a fájlt a -z paraméterrel megadva .

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

A szimbólumútvonal mutathat egy helyi gyorsítótárral rendelkező szimbólumkiszolgálóra , például:

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

Míg a bináris útvonal általában valami ilyesmi C:\Windows\I386 vagy a mappa, ahová a memóriaképet generáló verziónak megfelelő rendszer futtatható fájljait másoltuk. Ez azért fontos, mert A minidumpok nem tartalmazzák az összes bináris fájlt, csak hivatkozásokat tartalmaz rájuk, így a hibakeresőnek meg kell találnia őket.

A kernel összeomlási memóriaképének alapvető elemzése Windows rendszerben

Miután a memóriakép betöltődött a WinDbg vagy a KD segítségével, a kernel összeomlási memóriaképének elemzése meglehetősen hasonló egy utólagos hibakeresési munkamenethez. Az első parancs, amit szinte mindenki futtat, az `!analyze` , amely elindít egy automatizált elemzést és létrehoz egy kezdeti jelentést.

A parancs !analyze -show mutassa meg a hibakereső kód és paramétereiMíg !analyze -v Sokkal részletesebb kimenetet produkál: gyanús modult, hívásvermet, kontextuális információkat és sok esetben javaslatokat a lehetséges okokra vagy diagnosztikai lépésekre.

Az elemzés kiegészítéseként a .bugcheck parancs újra kinyomtatja a hibakódot és a hozzá tartozó paramétereket, amelyeket össze lehet hasonlítani a Microsoft hibaellenőrzési kódjának referenciájával, hogy megtudjuk az egyes értékek pontos jelentését és a tipikus okokat.

A parancs lm N T (modulok listázása) lehetővé teszi a következők megtekintését: A betöltött modulok listája elérési útjukkal, címükkel és állapotukkal együttEz segít megerősíteni, hogy az automatikus elemzés által azonosított illesztőprogram valóban megtalálható-e a memóriában, és ha igen, milyen verziójú. Ez a lista különösen hasznos, ha harmadik féltől származó illesztőprogramokra vagy biztonsági összetevőkre gyanakszunk, amelyek kölcsönhatásba lépnek a kernellel.

Szükség esetén egyszerűsíthetjük a memóriaképek betöltését egy kötegelt fájl létrehozásával , amely megkapja a memóriakép elérési útját, és a megfelelő paraméterekkel elindítja a KD-t vagy a WinDbg-t. Így csak egy rövid parancsot kell írnunk, amely csak a fájl helyét tartalmazza, és a szkript minden másról gondoskodik.

WinDbg használata mély kernel dumpokhoz

Kernel módú memóriaképek esetén a WinDbg lehetővé teszi több fájl és munkamenet kezelését is. A memóriaképek megnyithatók a parancssorból a -z kapcsolóval , vagy a grafikus felületről a Fájl > Memóriakép megnyitása menüvel, illetve a Ctrl+D billentyűparancs használatával.

Ha a WinDbg már meg van nyitva passzív módban, egyszerűen jelölje ki a fájlt a „Megnyitási memóriakép megnyitása” párbeszédpanelen, adja meg az elérési utat, vagy böngésszen a lemezen. A betöltés után bizonyos esetekben elindíthatja a munkamenetet egy „g” (Go) paranccsal, vagy közvetlenül elindíthatja a kezdeti elemzési parancsokat.

A klasszikus mellett !analyzeCélszerű megismerkedni a hibakereső parancs referencia szakaszEz leírja az összes elérhető parancsot a belső struktúrák olvasására, a memória vizsgálatára, a veremelemzésre és sok másra. Ezen technikák közül sok alkalmazható mind élő munkamenetekben, mind offline memóriaképekben.

A WinDbg lehetővé teszi a következőkkel való munkát is: több párhuzamos dumpTöbb -z paramétert is hozzáadhatunk a parancssorhoz, mindegyiket egy másik fájlnévvel követve, vagy új célokat is hozzáadhatunk a következő paranccsal: .opendumpTöbb célhely hibakeresése hasznos az ismétlődő hibák vagy láncolt incidensek összehasonlításához.

Bizonyos környezetekben a memóriaképeket CAB fájlokba csomagolják a helytakarékosság vagy az átvitel megkönnyítése érdekében. A WinDbg közvetlenül megnyithat egy .cab egy kiírással belül, mind a -z, mind a .opendumpbár majd olvasni fog Csak az egyik kiírt fájlt fogja kicsomagolni, a többit nem. ami mehetne ugyanabba a csomagba.

Összeomlási memóriaképek Unix és Linux rendszeren: segédprogram, eszközök és követelmények

Unix és GNU/Linux rendszerekben a filozófia hasonló, de az eszközök ökoszisztémája jelentősen eltér. A legtöbb Unix-szerű kernel lehetővé teszi a memória másolatának mentését katasztrofális esemény bekövetkeztekor , ezt nevezzük memóriakiírásnak vagy kernel összeomlási kiírásnak.

Bár elsődleges felhasználási területük továbbra is a kernel és a driver fejlesztése, ezeknek a memóriaképeknek egyértelmű biztonsági vonatkozása van. Összeomlást okozhatnak programozási hibák, de sikertelen rosszindulatú műveletek, rendszerösszetevők manipulálására tett kísérletek vagy ügyetlenül kihasznált versenyhelyzetek is.

Egy jól konfigurált Unix rendszerben a napi összeomlások ritkák, de amikor mégis előfordulnak, célszerű egy olyan memóriakép-infrastruktúra, mint például a Kdump, az LKCD vagy más olyan megoldások, amelyek lehetővé teszik a rendszermemória rögzítését. Azonban kulcsfontosságú mérlegelni a memóriakép diagnosztikai értékét a benne rejlő rendkívül érzékeny adatok kockázatával szemben.

Az ilyen típusú elemzésekhez Linuxon az egyik legátfogóbb és legszélesebb körben használt eszköz a crash , amelyet eredetileg a Red Hat fejlesztett ki. Ez a segédprogram gyakorlatilag de facto szabvánnyá vált a kernel dumpok vizsgálatára és a futó rendszerek elemzésére is.

A rendszer összeomlása a következő módokon hathat a rendszer élő memóriájára: /dev/mem vagy Red Hat és származékos disztribúciókban az adott eszköz használatával /dev/crashEnnek ellenére bevett gyakorlat, hogy az eszközt egy olyan mechanizmusok által generált dump fájllal táplálják, mint például a Kdump, makedumpfile, Lemezkiírás vagy architektúra-specifikus dump-ok, mint például s390/s390x vagy xendump virtualizált környezetekben.

Az összeomlás szerepe és a vmlinux fontossága Linuxban

A crash segédprogramot részben azért hozták létre, hogy leküzdje a használat korlátait gdb közvetlenül a /proc/kcoreTöbbek között a memória pszeudo-képhez való hozzáférés korlátozott lehet, és ezen felül bizonyos kernel-fordítási beállítások megnehezítik a belső struktúrák megfelelő értelmezését, ha csak a tömörített futtatható bináris fájl áll rendelkezésünkre.

Ahhoz, hogy az összeomlás megfelelően működjön, két kulcsfontosságú elemre van szükség: egy lefordított vmlinux fájlra hibakeresési szimbólumokkal (általában olyan flagekkel, mint a -g), és magára a kernel dump-ra. Ez a kombináció lehetővé teszi az eszköz számára, hogy a memóriacímeket függvényekhez, struktúrákhoz és kódsorokhoz rendelje.

Fontos különbséget tenni vmlinux és vmlinuzA legtöbb rendszeren csak a vmlinux látható, amely a kernel tömörített, indítható verziója. Az összeomláshoz szimbolikusan kicsomagolt vmlinux szükséges; enélkül egy memóriakép betöltésekor vagy /dev/mem típusú hibákkal fogunk találkozni nem található a betöltött kernel — kérjük, adja meg a névlista argumentumot.

Bár a vmlinuz manuális kibontása lehetséges, a folyamat nem mindig egyszerű, és a gyakorlatban gyakran sokkal kényelmesebb a kernel újrafordítása, hogy egyszerre szerezzük be a vmlinuxot és a vmlinuzt. Komoly adminisztrációs környezetekben bevált gyakorlat, hogy minden egyes telepített kernelverzióhoz külön vmlinuz csomagot tartsunk fenn, kifejezetten ezekre a helyzetekre.

Miután a követelmények teljesültek, a crash parancs futtatása egy memóriaképen viszonylag egyszerű: megadod a megfelelő vmlinuxot és a memóriaképfájlt, és az eszköz megnyit egy interaktív munkamenetet, amelyből felfedezheted a kernel struktúráit, listázhatod a folyamatokat, megtekintheted a hívásvermeket és kinyerhetsz forenzikus információkat . Azok, akik mélyebben szeretnének beleásni magukat, speciális dokumentációkat tekinthetnek meg, például a jól ismert összeomlási technikai tanulmányt.

A /dev/mem korlátai és az első megközelítések Linuxban

Mielőtt konkrét eszközökhöz folyamodtak volna, sok rendszergazda történelmileg megpróbált memóriaképet szerezni. közvetlenül a készülékről leolvasva /dev/memEz a megközelítés egyszerűnek tűnt: használjon egy eszközt, például memdump (ami az eszközt a STDOUT kimenetre írja) vagy innen húz dd if=/dev/mem of=volcado.mem.

A modern kernelek azonban olyan fordítási lehetőségeket kínálnak, mint például CONFIG_STRICT_DEVMEMamelyek jelentősen korlátozzák a felhasználói térből a hozzáférést /dev/memA tipikus eredmény az, hogy az olvasás egy kis blokk (pl. 1 MB) után megszakad, vagy a legrosszabb esetben az interakcióban fellépő hiba a következővel végződhet: kernel pánik azonnali és a gép újraindítása.

Ez a védelem biztonsági szempontból tökéletesen érthető, de arra kényszerít minket, hogy más módszereket keressünk a megbízható és teljes körű adatmentés érdekében anélkül, hogy teljes mértékben olyan általános eszközökre hagyatkoznánk, amelyek már nem olyan könnyen hozzáférhetők, mint korábban.

Ezért a jelenlegi trend az, hogy specifikus modulokra vagy integrált összeomlási memóriakép-infrastruktúrákra támaszkodnak, ahelyett, hogy egyszerűen csak megpróbálnák „memóriát kaparni” olyan felhasználói térbeli eszközökkel, amelyeket nem a modern kernel védelmi szabályzatokkal való együttélésre terveztek.

LiME Forensics: Memóriakinyerés Linuxban és Androidon

A forenzikus világban egy nagyon hatékony alternatíva a LiME (Linux Memory Extractor) , egy kernel modul, amelyet kifejezetten az illékony memória szabályozott módon és a /dev/mem könyvtárat érintő korlátozások nélkül történő rögzítésére terveztek. A LiME a kernel térben fut, így sokkal közvetlenebbül fér hozzá a RAM-hoz.

A LiME a forráskódjával együtt kerül terjesztésre, és a következőre fordul: használatban lévő kernel fejlécekA fordítási folyamat egy modult generál .ko a betöltésre kerülő kernel verziójára jellemző. Lefordítás után olyan eszközökkel ellenőrizhetjük, mint például file hogy megbizonyosodjunk arról, hogy az architektúránknak megfelelő ELF modul helyesen lett generálva.

A LiME használatához egyszerűen töltse be a modult a következővel: insmod root felhasználótól, és adja át neki a megfelelő opciókat, például egy hálózati memóriakép célállomás TCP és nyers formátum használatával:

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

Ezzel párhuzamosan, azon a gépen, amelyik fogadja a kiíratást, figyeljük a konfigurált portot egy olyan eszközzel, mint a nca kimenet átirányítása egy fájlba:

nc <IP_origen> 4444 > volcado.mem

Néhány perc múlva, a RAM mennyiségétől és a hálózati teljesítménytől függően, egy olyan fájllal fogunk rendelkezni, amelynek mérete megegyezik a forrásrendszer fizikai memóriájával. Ez egy teljes RAM-memória, amelyet forenzikus eszközökkel, vagy akár karakterláncokkal vagy más segédprogramokkal is elemezhetünk első lépésként az érdekes karakterláncok megtalálásához.

Folyamatkiírások és adatkitettség kockázatai

Egy teljes kernel dump rendkívül informatív, de túlzott is lehet, ha csak egy adott folyamatra vagyunk kíváncsiak. Ebben az esetben sok értelme van a következőkhöz folyamodni... egyedi folyamatleírások olyan eszközök használatával, mint gcore Unix/Linux alatt.

Ezek a folyamatonkénti memóriaképek sokkal kisebbek és könnyebben kezelhetők, és lehetővé teszik, hogy az elemzést adott alkalmazásokra, például üzenetküldő kliensre (pl. Skype) vagy e-mail kliensre (pl. Thunderbird) összpontosítsa, ahol viszonylag könnyű egyszerű szöveges jelszavakat, munkamenet-tokeneket vagy kapcsolattartási adatokat találni a memória-sztringek feltárásával.

Fejlesztési szempontból ezek a memóriaképek segítenek a programozási hibák, memóriaszivárgások vagy inkonzisztens állapotok megtalálásában egy szolgáltatásban. Biztonsági szempontból azonban probléma akkor merül fel, amikor ezeket a memóriaképeket rutinszerűen generálják, és más felhasználók számára is hozzáférhető helyeken tárolják , akár magán a rendszeren, akár megosztott hálózati erőforrásokon.

Ha egy felhasználó például ütemez egy feladatot cron Azzal, hogy a támadó rendszeresen rögzíti az érzékeny folyamatok memóriaképeit, és egy globálisan olvasható könyvtárban tárolja azokat, hatalmas ajtót nyit a kritikus információk kiszivárgásának. Számos auditálási forgatókönyvben ezen fájlok elemzése lehetővé teszi a támadó számára a helyreállítást. hitelesítő adatok, névjegyzékek, kommunikációs előzmények és egyéb személyes adatok viszonylag kis erőfeszítéssel.

Ezért egy Unix rendszer komolyabb auditja során célszerű néhány percet szánni annak ellenőrzésére, hogy keletkeznek-e (teljes vagy részleges) memóriaképek, hol tárolódnak ezek, milyen jogosultságokkal rendelkeznek, és van-e olyan automatizált folyamat, amely a memóriamásolatokat jogosulatlan felhasználók számára elérhetővé teszi.

A FreeBSD-ben található dumpok utólagos elemzése kgdb segítségével

A BSD világában, és különösen a FreeBSD-ben, a poszt mortem elemzés megközelítése magában foglalja Engedélyezze a rendszer összeomlási memóriaképeit, és legyen egy hibakeresési szimbólumokkal lefordított kernel.Ezt a kernel konfigurációs könyvtárából lehet vezérelni, általában a /usr/src/sys/<arq>/conf.

A megfelelő konfigurációs fájlban a szimbólumgenerálás egy ilyen sorral engedélyezhető:

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

A konfiguráció módosítása után a kernelt újra kell fordítani. Néhány objektum újragenerálásra kerül (például trap.o) a build fájlok változása miatt. A cél egy olyan kernel létrehozása, amely a következővel rendelkezik: ugyanaz a kód, mint amelyikben problémásak vannak, de hozzáadva a szükséges hibakeresési információkatCélszerű a régi és az új méreteket a következő parancs használatával összehasonlítani: size hogy megbizonyosodjunk arról, hogy nem történtek váratlan változások a bináris fájlban.

Miután a szimbólumokkal ellátott kernel telepítése megtörtént, a hivatalos dokumentációban leírtak szerint megvizsgálhatjuk a dumpokat a kgdb segítségével . Nem minden szimbólum teljes, és egyes függvények sorszámok vagy argumentuminformációk nélkül jelenhetnek meg, de a legtöbb esetben a részletesség szintje elegendő a probléma nyomon követéséhez.

Nincs abszolút garancia arra, hogy az elemzés minden incidenst megold, de a gyakorlatban ez a stratégia a forgatókönyvek nagy százalékában meglehetősen jól működik , különösen akkor, ha a hibajelentéseket a rendszer legutóbbi módosításainak alapos áttekintésével kombinálják.

A kernelhibák elemzésének és dokumentálásának ajánlott gyakorlatai

Az operációs rendszertől függetlenül a kernel dump elemzése általában technikai dokumentációra, tudásbázisokra, speciális fórumokra vagy akár magára a kernel forráskódjára hivatkozik az üzenetek, hibakódok és ismeretlen szimbólumok értelmezéséhez.

Linux alatt nagyon hasznos a hivatalos forráskódfára, a beépített dokumentációra és a közösségi forrásokra támaszkodni. Sok kernel hibaüzenet visszakövethető a pontos fájlig, ahonnan származik, ami segít megérteni azt a kontextust, amelyben egy adott BUG() vagy WARN() aktiválódik.

Windows rendszerben a Microsoft dokumentációja, a tudásbázisa (KB) és a technikai fórumok részletes magyarázatokat tartalmaznak a hibakódokról, a hibaelhárítási javaslatokról és az ismert hibamintákról . Ezen információk és az !analyze -v jelentéseinek kombinálása lehetővé teszi egy észszerű kockázatcsökkentési terv kidolgozását.

Egy hibamemória valódi értéke akkor mutatkozik meg, amikor az összes információt összevetjük az operációs rendszer és a hiba helyszínének alapos ismeretével . Csak így lehet tartós megoldásokat kidolgozni, és mindenekelőtt megakadályozni, hogy ugyanaz a probléma a jövőben súlyosabb következményekkel járjon.

A kernel dump elemzés végső soron a tudomány és a szakértelem keveréke: megfelelő eszközöket, előzetes konfigurációt (szimbólumok, dump opciók, biztonságos tárolás), valamint jelentős tapasztalatot igényel a verem-, struktúrák- és hibakódolvasásban. Ezen technikák elsajátítása nemcsak az összetett incidensek hibakeresését teszi lehetővé, hanem a kezelt rendszerek biztonságának és ellenálló képességének drámai növelését is.