Suspend to RAM, šifrovaný disk a coldboot útok

18.1.2012 01:24 | Přečteno: 3169× | Linux | | poslední úprava: 18.1.2012 01:28

Jako správný paranoik mám (až na /boot) šifrovaný celý disk - a taky rád používám suspend to RAM. Tady už místní paranoici asi čuchají problém - uspaný počítač je totiž snad to nejlepší, co si útočník plánující coldboot útok může přát. cryptsetup má už delší dobu funkci "luksSuspend", která klíče zahodí. Z pochopitelných důvodů to nejde jednoduše použít na připojený root. I když... Po pár hodinách hraní můžu prohlásit obligátní "jde to, ale dře to!".

Co budeme potřebovat

• Zdrojáky jádra (já použil 3.2.1)
• Tarball s potřebnými zdrojáky
• initramfs s plnohodnotným bashem a binárkou /bin/cryptsetup, (pokud nemáte, je tu)
• Pevné nervy a dost odvahy

Jak to funguje

Z tarballu nám vypadne jeden prográmek v C, dva shell skripty a jeden patch. Celé představení se spouští skriptem "cryptsleep", ve kterém je zároveň i pár konfiguračních voleb (já vím, /etc...):

• USE_TTY: číslo terminálu na kterém se bude zadávat heslo k disku - POZOR! - měl by být nepoužívaný
• X_TTY: číslo terminálu na kterém běží Xka (po odemčení disku se na něj přepne pokud se nepodaří zjistit z jakého terminálu byl skript spuštěný)
• MOUNTPOINT: adresář kam se rozbalí ramfs, v případě potřeby se vytvoří
• INITRAMFS: soubor s ramdiskem (zagzipovaný cpio archiv) - já používám přímo initramfs vlastní výroby
• LIBDIR: cesta k souborům cryptsleep-bin a cryptsleep-script

Pokud se vám nechce číst zdroják - tenhle skript vytvoří mountpoint, připojí do něj ramfs, nakopíruje cryptsleep-bin a cryptsleep-script, o kterých ještě bude řeč, spustí cryptsleep-bin a uklidí po sobě. Já vím, mohl jsem to napsat v C všechno, ale nebyla chuť :)

cryptsleep-bin je bastl v C, který: změní terminál na vybraný, přesune /proc, /sys a /dev do ramfs, chrootne do ramfs, v chrootu spustí cryptsleep-script a přesune filesystémy zase zpátky.

cryptsleep-script zavolá luksSuspend, uspí systém do RAM, po probuzení si řekne o heslo a zavolá luksResume. V tomhle skriptu je potřeba upravit název pod kterým máme v device mapperu root!

Jak to rozchodit?

Instalace by měla být jednoduchá - upravit cryptsleep-script a cryptsleep, zkompilovat cryptsleep-bin: gcc cryptsleep.c -o cryptsleep-bin, opatchovat a zkompilovat jádro. cryptsleep-script a cryptsleep-bin nakopírovat do $LIBDIR.

Proč je potřeba patchovat?

Ve chvíli kdy zavoláme luksSuspend dojde ke smazání šifrovacích klíčů k disku a jakákoliv disková operace se zablokuje. Co se stane s jádrem které chytře zavolá před uspáním sync() je asi jasné. Pro jistotu se sync() volá i těsně před spuštěním skriptu z cryptsetup-bin. Druhý problém je v tom, že jakmile se zavolá luksSuspend začnou všechny procesy sahající na disk tuhnout ve stavu "Disk wait". A kernel před suspendem volá freeze na jednotlivé procesy - a pokud některý čeká na IO je zle. Moc jsem nevěděl co s tím, zkusil jsem mrazák vyhodit a překvapivě to funguje (to neznamená, že vám to fungovat bude taky!). Jestli to budete chtít taky zkusit, hodně štěstí!

TODO

• odprasit kód
• zjednodušit konfiguraci, vrazit ji mimo binárky

       

Komentáře

[Divný host]

Dobrá práce! Škoda že je asi nereálné dostat podporu této funkce do běžných distribucí ...

[Josef Kufner]

Tohle by chtělo dostat rovnou do jádra, aby se userspace vůbec nepoužíval, protože jedině tak odpadne problém s mrazákem.

[Divný host]

Pokud to dobře chápu, tak v jádře vše potřebné je (modulo problém se syncem). Je jen potřeba od uživatele po probuzení získat znova heslo, což už je záležitost userspace.

[Josef Kufner]

To právě že moc nejde, protože userspace je tou dobou zamrzlý. Prostě je potřeba do jádra dostat uživatelské rozhraní, které po zmražení userspace vypláchne klíče a po probuzení se zeptá na heslo a nebo umožní opětovné uspání, pokud by uživatel nechtěl/nemohl zadat heslo. Dávat tohle do userspace bude celkem zbytečná a nemalá komplikace.

[Mrkva]

No, ale tyhle věci zas do kernelspace nepatří a patřit nebudou :) Uživatelské rozhraní do jádra? To fakt ne...

[Josef Kufner]

Já vím, ale tou dobou prostě userspace není.

[VM]

Není jen disk I/O. Takže rozhraní by se mělo načíst celé do paměti na začátku uspávání, a to včetně případných knihoven, a mělo by se zajistit proti odswapování. Jít by to ale mělo.

[petr_p]

zajistit proti odswapování

Na to by měl stačit mlock(2). Jen nevím, jestli vztahuje i na stránky mapované ze souboru.

[petr_p]

Suspend nepoužívám, takže ani moc neznám, ale pokud vím, tak jádro normální boot a resume rozlišuje pomocí signatury ve swapu. Nedalo by se prvně nabootovat jen do initarmfs, tam se zeptat na heslo a pak přes kexec předat heslo třeba přes /proc/cmdline novému jádru s podporou uspávání? (Nebo složitěji přes reservovanou fyzickou paměť, protože u kexecu do paměti BIOS nešahá.)

Ale i myšlenka plně jaderné implementace není špatná. Jaderná správa klíčů umí klíče zašifrovat a zase odšifrovat a interaktivní jádro už stejně je (vga=ask).

Každopádně jsem viděl, že Fedora má resume do šifrovaného rootfs nějak vyřešený. Aspoň se to tak tváří.

[Josef Kufner]

Řeč je o uspávání do paměti, nikoliv na disk. Při uspání na disk se klíče zahazovat nemusí, protože swap do kterého se uspává je na šifrovaném disku. Po zavedení jádra z nešifrovaného /boot se to normálně zeptá na heslo k disku (LVM s / a swapem) a pak teprve kouká do swapu jestli se lze probudit. Takle to má defaultně Debian.

Uspání do paměti je úplně o něčem jiném: Nic se znovu nenačítá, žádné bootování. Prostě se jen vypne procesor a ty blbosti okolo. Zůstane naživu jen RAM s jejím řadičem a tlačítko na zapnutí. (Zjednodušeně řečeno.) Tím pádem stačí vzít paměť, stříknout dusík, přendat do jiného počítače a zkopírovat si ji. Velmi jednoduše se tak dostane kdokoliv dostatečně šikovný ke všemu, co zrovna běží, včetně klíčů od disku.

[Lol Phirae]

Tím pádem stačí vzít paměť, stříknout dusík, přendat do jiného počítače a zkopírovat si ji. Velmi jednoduše se tak dostane kdokoliv dostatečně šikovný ke všemu, co zrovna běží, včetně klíčů od disku.

Opravdu bych chtěl vidět tu jednoduchou demonstraci... Kdy na to máte po neděli čas? Počítám max. s půlhodinkou, je to přece velmi jednoduché.

[David Jaša]

Nic nového pod sluncem

[:::]

ten nesifrovany /boot mas na nejaky flashce kterou nosis porad sebou, nebo ho nechavas nehlidany?

[Mrkva]

Bootuju z flashky, ale /boot je na disku taky, samozřejmě nešifrovaný (jako fallback řešení). Nutno dodat, že mám v init skriptech kontrolu SHA hashe MBR a celého /boot :)

[Max]

Díky za hint, to bych si mohl také zavést :)
Zdar Max

[:::]

nejaky takovy test bych si mel taky vytvorit. Jenom doresit nektery detaily...

Napada me to udelat treba takhle:

- na HDD mit plne funkcni /boot, ale bez tehle testu, ktery by slouzil jako fallback a zaroven jako honeypot

- na flashdisku mit stejny boot ale navic s kontrolou dat na HDD

Pokud utocnik modifikuje boot na hdd tak pri bootu z flash na to prijdu a vim ze mam problem... Flashce bohuzel musim verit protoze kdyby ju modifikoval tak muze tyhle testy vypnout, pripadne zmenit aby zobrazili co chci videt...

Mit ten test i v bootu na hdd by asi bylo zbytecny, protoze pokud ma utocnik pristup k hdd tak muze upravit i test a navic by to zbytecne poutalo pozornost.

Nezapomel jsem na nejaky detail?

Jeste me ted napada ze utocnik s fyzickym pristupem by mohl nastavit bios aby bootoval z hdd s upravenym bootem, misto z usb. Nejaky napady jak tohle resit, krome kontroly biosu pri kazdym spusteni?

[Josef Kufner]

Říká se tomu Trusted Computing. Ty lepší notebooky mají v sobě čip, který tohle řeší místo tvé flashky.

[:::]

no teda, studoval jsem to jenom na rychlo ale z toho co jsem se docetl to vypada jako root of all evil

[Sten]

Trusted Computing je dvousečná zbraň. Současná „polovičatá“ implementace je velmi dobrá věc, právě protože umožňuje tyhle ochrany. V původním konceptu ale měl ten čip umožnit spouštět jenom zavaděč podepsaný klíčem, který uživatel nebude mít k dispozici, což asi budou ty informace, na které jste narazil (dnešní implementace místo toho používá heslo nebo jinou identifikaci zadanou uživatelem v nastavení BIOSu) — to naštěstí neprošlo, tak se to teď snaží MS dohnat s UEFI Secure Boot.

[Mrkva]

Tak tu integritu netestuje přímo skript v /boot (v initramfs) - to by tak trochu postrádalo smysl. Tu integritu testuju po připojení šifrovaného rootu z něj. Jasně pokud nabootuju z HDD, útočník může patchnout jádro tak, aby se /boot tvářil jako nezměněný. Ale bez znalosti toho co přesně a jak kontroluji to nebude nic moc.

Navíc, pokud útočník získá fyzický přístup k HW, záleží jen na schopnostech útočníka jestli se tam dostane nebo ne. Může patchnout BIOS, může tam dát HW keylogger, může napíchnout sběrnici...

[:::]

a co tahle situace: utocnik si zkopiruje tvuh hdd (zasifrovany) a upravi boot aby mu po zadani hesla to heslo posal. Ty zadas heslo, system nastartuje a detekuje ze se neco zmenilo. Utocnik ale uz ma data i heslo...

Kazdopadne je pravda ze s fyzickym pristupem muze udelat i dalsi veci, ktery by nebylo tak snadny detekovat.

Navic kdyz rozsifruje root tak by se jeste nemel dostat k uzitecnym datum, pokud je mas na dalsim oddilu s jinym heslem.

[Mrkva]

a co tahle situace: utocnik si zkopiruje tvuh hdd (zasifrovany) a upravi boot aby mu po zadani hesla to heslo posal. Ty zadas heslo, system nastartuje a detekuje ze se neco zmenilo. Utocnik ale uz ma data i heslo...

Data má, heslo nemá, síť se spouští (a kabel připojuji/vypínám RF kill) až po kontrole :)

Kazdopadne je pravda ze s fyzickym pristupem muze udelat i dalsi veci, ktery by nebylo tak snadny detekovat.

Jo. Nehlídaný fyzický přístup = konečná. Ono teda vzato do důsledků, člověk by neměl věřit ani prodejci, že od něj dostává čistý HW. Na nějakou práci s extra citlivými daty bych si pořídil asi RapsberryPi, BeagleBoard, Pandaboard, kde člověk může zkontrolovat každý čip (ale zase, ten čip může být napíchnutý aby ukládal hesla/poskytnul backdoor atd. už z výroby). Akorát tam pořád jsou nějaké closed source části.

[piCZa]

Jesteze neni realne dostat takovou podporu do beznych distribuci. Vse totiz resi pocitac pod zamkem, bez site a s odepsanym bootem.

[Mrkva]

Tak ono když člověk potřebuje něco dělat online, tak bez sítě není řešení. Když potřebuje cestovat, pod zámkem není řešení.

[Lol Phirae]

Asi mi něco uniklo nebo jsem nedostatečně paranoidní, ale proboha proč tak příšerně složitě?! Tohle funguje na první našlápnutí: Setting up an encrypted Debian system. Tím myslím konkrétně tu metodu s použitím /lib/cryptsetup/scripts/decrypt_derived jako keyscript pro šifrovaný swap. Při zapnutí po hibernaci se to zeptá na heslo pro šifrovaný root a je vyřízeno.

[msk]

A zahodi to pri suspend-e kluce z pamati?

[Lol Phirae]

Ne, ptá se to při resume na ten klíč jen tak z plezíru...

[msk]

Pri resume z RAM? Prevadzkoval som Debian nad sifrovanym LVM, ale suspendoval som len na disk, takze si nie som isty ...

[Lol Phirae]

Z RAM samozřejmě ne, proč by to asi tak dělal? Proboha lidi, jestli se 25 hodin denně pohybujete v prostředí nepřátelských agentů, tak nenechávejte zapnutý počítač, když u něj nejste. (Ano, STR je zapnutý počítač, u notebooku to během pár dnů komplet vyžere baterku.)

[SPM]

Protože celý blog byl o tom jak to udělat při suspendu do RAM? A protože tu i padlo, že suspend na disk je prakticky už skoro k ničemu :)

[Lol Phirae]

Jo tak, k ničemu. No tak nic. To by mě zajímalo, kolik z těch paranoidních šílenců tady má třeba povolený FireWire (přes který jde u spousty HW dumpnout komplet celá RAM.) Při suspendu do RAM to kromě v článku zmíněné příšernosti (která dřív nebo později skončí likvidací filesystému) nejde, protože to je padlé na hlavu. A co tak šíleně tajného máte na /, že vám nestačí při suspendu zlikvidovat klíč k /home.

[:::]

pri sifrovani / nejde o to aby utocnik nevidel obsah, ale aby ho nemohl nepozorovane zmenit.

[Lol Phirae]

Jistě, bude ho nepozorovaně měnit tím, že nepozorovaně ponoří RAMky do tekutého dusíku, zatímco majitel počítače se šel vychcat. Protože to je rozhodně nejjednodušší možnost, jak to udělat - nějaké bugy, kdo by se s tím zabýval. Prostě vezmu konev od mléka plnou tekutého dusíku a o polední pauze tam kolegovi nenápadně podstrčím backdoor.

[:::]

konecne se u tebe zacina projevovat ten spravnej frame of mind. Jeste chvili a budes paranoik jako my...

[Lol Phirae]

No jistě, přece jsem ten dual boot W7 šifrovanejch BitLockerem s Linuxem (kryptovanej / s btrfs na LUKS) nedělal zbytečně.

[SPM]

Tak uspání je delší, než počítač vypnout, probouzení bude asi tak nastejno; u mě navíc část systému zůstala ve swapu, takže několik prvních minut byl systém strašně líný... oproti suspendu do RAM, kde uspávám/probouzím v řádu jednotek sekund. Jinak je otázka, na kolik to při šifrování jenom /home bude lepší - pokud se neodpojí, tak stejnak bude problém s tím, že je třeba zahodit klíč až po freeznutí procesů a podobně... ale já až takový šílenec nejsem; hdd mám šifrovaný kvůli tomu, když mi nějaký sběrač kovů ten notebook ukradne, tak aby se nedostal k datům v něm. Nepředpokládám, že by heslo v screensaveru řešil jinak, než že to vypne.

[adam]

kup si ssd a na suspend2ram sa mozes z vysoka vysrat...

[SPM]

Jo, takže SSD zajistí po zapnutí funkční systém v řádu sekund, kde najdu spuštěné a rozmístěné aplikace přesně tak jak byly? :)

[msk]

Ked to suspendnes na disk ... Ale nebude to do par sekund, skor desiatok. Co je furt v porovnani s mojim pracovnym pc ( 10 min po zapnuti nepouzitelne ) parada

[:::]

pouzivat SSD jako swap, to myslim vzhedem k omezenymu poctu zapisu neni nejlepsi napad...

[msk]

Vzdy je mozne spravit swapon pred uspatim a swapoff po uspati. Mne je to ale jedno, ja PC prakticky neuspavam, zaprve som to este nevidel fungovat a zadruhe ked odchadzam od pc na dlhsiu dobu vypinam komplet zostavu, monitory a vsetko okolo na prepatovke.

[SPM]

To je otázka... SSD imho vede v tom, když ty data čtu z různejch oblastí - narozdíl od disku nemusí přenastavovat hlavu a podobně... ale ve chvíli kdy na disk chci v kuse nalít 16GB dat, tak to IMHO rychlostně o tolik lepší nebude (a stejně to bude trvat strašně dlouho)

[Pali]

Problem s freeze_processes, luksSuspend a sync sa snazim teraz chytit za tu spravnu stranu... Konkretne zavolat luksSuspend az po freeze_processes a to naviac automaticky z kernelu (kedze v case po freeze_processes uz userspace nebezi).

Patche co to implementuju som uz poslal na LKML: https://lkml.org/lkml/2015/4/5/120

Spomenul som si na tento blogovy zapis, je sice starsi ale snad sa to niekomu bude hodit...