BitLocker vs DumpFile

BitLocker vs DumpFile

  • Comments 6
  • Likes

Jakoś tak siedząc i leniwie rozmyślając o wnętrznościach systemu, doszedłem nagle do dość interesującego wniosku. Po kolei, to mniej więcej szło tak:

  • BitLocker szyfruje każdy sektor dysku, więc odczytanie danych poprzez dostęp offline (sięgając do dysku wyłączonego komputera) nie jest w normalnych warunkach możliwe.
  • Plik DMP (zawierający zrzut pamięci podczas Blue Screena) tworzony jest w bardzo specjalny sposób:
  • System wczytuje sterowniki dysku twardego dwukrotnie – raz do normalnej pracy a drugi raz, z przedrostkiem dump_ tylko po to, aby ich użyć w czasie BSOD. Dzięki temu, te drugie nie są w normalnej pracy używane, co zwiększa szansę, że pozostaną nienaruszone przez crash systemu.
  • System zapamiętuje mapę sektorów dysku, w których leży pagefile.sys i też trzyma ją tylko na wypadek wystąpienia BSOD. Dzięki temu, w chwili awarii, dostęp do pliku wymiany możliwy jest z pominięciem wszystkich normalnych warstw stosu systemu plików i można coś zapisać na poziomie konkretnych sektorów. Oczywistą wadą jest to, że jakakolwiek modyfikacja położenia pagefile.sys dezaktualizuje taką mapę i wtedy "dłubanie" bezpośrednio po sektorach ma pełne prawo zakończyć się katastrofą. Między innymi dlatego, na żywym systemie z pagefile.sys nie można nic zrobić, z defragmentacją włącznie, mimo że dla innych otwartych plików nie jest ona wielkim problemem.
  • W momencie wystąpienia BSOD, system weryfikuje sumy kontrolne dla "zapasowych" sterowników oraz dla mapy sektorów i zaczyna zrzut pamięci. W efekcie, zrzut tworzony jest wewnątrz pagefile.sys a nie jako plik na dysku. Do pliku zostanie skopiowany przez SMSS i WerFault.exe dopiero po restarcie, gdy system będzie nieco stabilniejszy niż w czasie crashu.

I tu pojawiła się mi się piłeczka taka, jaka pojawiała się Pomysłowemu Dobromirowi. Przecież to rozwiązanie oznacza, że dane w pagefile.sys zapisywane są z pominięciem całego stosu! A więc i bez pośrednictwa fvevol.sys, który dla każdej innej informacji zapisywanej na dysku zajmuje się jej zaszyfrowaniem. Czy to oznacza, że zawartość RAM zapisywana jest w czasie BSOD bez szyfrowania?

Takie pytania sprawiają, że można zmienić plany na sobotni wieczór. Po szybkich konsultacjach z Paulą Januszkiewicz zadziałaliśmy dwutorowo. Paula doświadczalnie zaczęła badać co z zawartości pamięci RAM fizycznie znajdzie się w dumpie leżącym na dysku chronionym BitLockerem a ja zacząłem zabawę z WinDbg.

Wyniki pozwalają spać spokojnie. Ani bezpośrednie doświadczenia ani próby zrozumienia co w systemie się dzieje nie dają powodów do niepokoju. Jednym z elementów BitLockera jest sterownik dumpfve.sys wczytywany również drugi raz jako dump_dumpfve.sys Sterownik ten nawet w chwili totalnej katastrofy, jaką zwykle jest BSOD zadba, aby wszystko zostało zaszyfrowane. Korzyści są oczywiste: dane są skutecznie chronione. A konsekwencje mniej pozytywne? Zwiększa się ilość elementów, od których zależy poprawne zapisanie zrzutu pamięci, co może oznaczać, że zwiększy się również ilość przypadków, gdy system nie podejmie się jego wykonania aby nie uszkodzić danych na dysku.

dump01

Prawdę mówiąc, takie podejście mnie uspokaja. W zrzucanej na dysk pamięci są przecież klucze szyfrujące i dostanie się do nich mocno naraziłoby bezpieczeństwo całego rozwiązania. W każdym razie BitLocker po raz kolejny się obronił i po raz kolejny jasno pokazał, że ludzie, którzy go zaprojektowali, przemyśleli sobie naprawdę wiele scenariuszy.

Na koniec będzie zagadka i zadanie domowe:

  • Zagadka: dumpfve.sys wczytywany jest dwukrotnie. Do czego służy kopia w dump_dumpfve.sys już wiadomo. A jego oryginalna postać? Nagród nie przewiduję, ale gratulacje – już tak.
  • Zadanie domowe: Jak w analogicznej sytuacji (zrzut pamięci na zaszyfrowany dysk) zachowają się inne niż BitLocker rozwiązania szyfrujące? Ktoś używa i ma ochotę sprawdzić czy jest równie bezpiecznie?

Autor: Grzegorz Tworek [MVP]

Comments
  • W pierwszej chwili pomyślałem, że własnie do zabezpieczenia przed np BSOD, bo w końcu jego nazwa to: Full Volume Encryption Crashdump Hibernate Filter Driver. Skoro jednak do tego celu głównie używa dump_dumpfve.sys to stawiałbym na pomost do współpracy między innymi dostawcami systemów szyfrowania (firmy trzecie), co mogłoby mieć związek z zadaniem domowym :)

  • Jest wykorzystywany podczas hibernacji?

  • Odpowiedź Komodo jest trafna. Gratujuję i Tobie (nie byłeś pierwszy, na facebooku Marcin Jurko też dobrze odpowiedział).

    A co do odpowiedzi Tobiasza... hmm... choć to teoretycznie możliwe, to nie kojarzę takiego zastosowania. Ale się przyjrzę :)

  • @Komodo - gratki i ode mnie :)

    @Grzegorz - spróbuje odkopać, miałem gdzieś przed oczami kilkanaście miesięcy temu artykuł o tym... (choć tam chyba były tylko rozważania teoretyczne, a nie przykład praktycznego zastosowania...)

  • To musial byc mily wieczor :) Ciekaw jestem, gdzie organizujecie te 'undergroundowe' spotkania, chetnie bym kiedys wpadl na 'jointa' z windbg ;)

  • A bo to w obecnych czasach potrzebne jest jakieś konkretne miejsce...? ;)

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment