LUKS who's talking now?

Kedvenc Linuxos mottóm, hogy ami működik, azt úgyis elbasszák. Vegyük példának okáért a LUKS-ot. Mi az a LUKS? Linux Unified Key Setup, egy egységesített lemeztitkosítási eljárás, aminek az eredeti célja az lett volna, hogy platformfüggetlenül lehessen kezelni a különféle titkosított merevlemezeket. Oh, és nem csak lemeztitkosítás de még szabványosított jelszókezelési eljárás is akart lenni.
Nos, ez utóbbiban követtek el egy irgalmatlan szarvashibát. Az támadónak csak annyit kell tennie, hogy mikor bootnál jelszót kér a gép a titkosított rendszerpartíció feloldására/mountolására rákönyököl az enterre. Igen, ennyi. 70-150 másodperc és már jön is a shell.
Kik lehetnek az érintettek? Mindenki, aki a telepítésnél bebökte a rendszerpartíció titkosítását, mert ugye az milyen biztonságos...

Részletek:
http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_sh…
http://www.theregister.co.uk/2016/11/16/want_to_pop_linux_shell_hole_en…

( asm v | 2016. 11. 16., sze – 23:01 )

Ez azert tul van lihegve. Ha jol ertem "csak" egy root shell-t kap a user, attol meg a titkositott particio adataihoz nem fer hozza.
Kb. olyan mint az init=/bin/bash ...

Hány olyan gép van, ami titkosított, le van lockolva a grub, nem férsz hozzá fizikailag, jelszavas a BIOS, nem lehet semmilyen külső eszközről felbootolni és amikor leülsz elé, akkor a LUKS promptban várja hogy megtörd..?

Egy LUKS-os Ubuntu alapinstall már a lockolt grubot sem teljesíti, azaz őket érinti egy sokkal súlyosabb, szélesebb körben kihasználható sebezhetőség: init=/bin/bash. Mindmeghaljunk.

+1
Itt szó sincs a LUKS hibájáról, az továbbra is teszi a dolgát rendben, kezeli a kulcsokat és a metaadatokat, és nem ad lehetőséget a titkosított adatokhoz jelszó nélküli hozzáférésre.

Itt két külön use-case van:
- Confidentiality - ha a támadó lemásolja a nyers adatokat, akkor ne tudja megfejteni azokat. Ezt csinálja a LUKS. A legtöbb felhasználó valójában ezért titkosít, leginkább elvesztett/ellopott eszközről az adatai ne kerüljenek illetéktelen kezekbe.
- Integrity - ne lehessen a rendszert megszabotálni, mást futtatni rajta, backdoor-t/keyloggert elhelyezni. Erre igazából a LUKS önmagában sosem biztosított garanciát, a legtöbb disk titkosításra praktikus módszer (CBC, CTR, XTS) kisebb-nagyobb mértékben bit-flipping támadásokra sebezhető. Logikusan ez következménye is annak az elvárásnak, hogy egy blokkhiba a diszken ne tegye az egész volume-ot olvashatatlanná, és a teljesítménye jó legyen, egy blokk random olvasás/íráshoz ne kelljen több blokkműveletet végezni, ad absurdum a teljes volume-ot mindig újraírni (CFB, OFB, PCBC ezért esik ki). Kell még egy további checksum vagy hash layer a plaintext adatok szintjén, akkor beszélhetünk integritásvédelemről.

Namost mi is itt a 'sebezhetőség'? Az, hogy kapott egy root promptot, úristen akkor 'feltörte' a gépet!? Mivel integritásvédelmet kérünk számon, ezért fel kell tételeznünk, hogy a /boot is titkosítva volt, valamint a fő volume encryption key nincs kényelemből az intramfs-be becsomagolva -> a normális best practice-eket betartották. Ekkor a támadó a root promptjával eppen egy in-memory filerendszerben áll, amit a grub nyitott ki és töltött be, vagyis a kulcs éppen nincs benn a memóriában (legfeljebb talán valami memóriaszemétből lehet kibányászható), és a változtatások vissza sem íródnak a még mindig titkosított /boot-ra. Még alapvetőbb kérdés, hogy a támadó egyáltalán hogy jut el az initramfsig, ha /boot is titkosítva van? És emiatt nem is annyira kritikus kérdés, hogy a grub jól takarítja-e maga után a memóriát.

Gyakorlatilag tényleg a publikus kiosk típusú használati eset az egyetlen, amit ez a hiba komolyan érint.
---
Régóta vágyok én, az androidok mezonkincsére már!

-1

"Erre igazából a LUKS önmagában sosem biztosított garanciát, a legtöbb disk titkosításra praktikus módszer (CBC, CTR, XTS) kisebb-nagyobb mértékben bit-flipping támadásokra sebezhető."

Ez igaz CBC-re es CTR-re, de az XTS-re nem egeszen. Kifejezetten integritasvedelmet nyilvan az XTS sem biztosit, de ott kontrollaltan csak min. egy egesz AES blokk regebbi tartalmat tudod visszamasolni (vagy nem kontrollalt tartalommal felulirni). Az egy erdekes kerdes, hogy ez milyen attack model mellett kihasznalhato (szvsz min. traffic analysis kell hozza), de messze nem trivialis.
Masreszt letezik olyan device mapper target, ami kifejezetten integritas-ellenorzest vegez (es mielott valaki beleokoskodik: igen, hasznaljak ezeket androidon kivul is). A lenyeg: nem indulhatsz ki abbol, hogy ugysincs integritasvedelem.

A konkret vulnrol: egyreszt a linkelt oldalon eleg vilagosan leirjak: az, hogy "fizikai hozzaferes" csak egyesek fejeben egy kategoria, a gyakorlatban eleg nagy kulonbseg van akozott, hogy korlatlan ido all rendelkezesedre FIB-el modositani barmelyik IC-t az alaplapon es hogy talaltal a halon egy IP-KVM-et default jelszoval. Ez a vuln minden olyan esetben kihasznalhato, amikor a konzolhoz hozzaferesed van, a diszkhez meg nem. Kioszk, ATM, cloud, random szerver szereles alatt radugva egy IP-KVM-re, barmelyik gep tamperproof hazzal, etc.

Masreszt (amit nem irnak le): a grub es a szoban forgo szornyuseg bizony jobb hijan resze a trusted boot chain-nek, ergo itt nem csak egy random root promptod van, hanem egy root promptod abban a kornyezetben, ami vegigment a trusted boot check-en, tehat pl. kiolvashatod vele az FDE kulcsot a TPM-bol.

--
"You're NOT paranoid, we really are out to get you!"

Ha jelszó promptban áll a LUKS, akkor nem a TPM tárolja az FDE kulcsot. Meglepődnék ha egy tipikus kioszk LUKS root-os lenne és valaki minden áramszünetnél körbeszaladná a várost beírni a jelszót. Gyanítom, hogy aki default jelszóval elérhető IP-KVM-es géppel bír, annak BIOS jelszava nincs, így egy live image is bebootolható USB storage emulációval és máris ott a root. Colocban jellemzően nem használnak fix jelszavas IP-KVM-et, amit ismerek, ott mindig átállítja az operátor.

Nem mondom, hogy nincs olyan környezetet ahol ez valós támadási vektor, de kurvára gondolkozni kell, hogy elméletben összeszedjünk egyet ami életszagú. :)

Az XTS a többihez képest valóban még a legjobban védett bit-flipping ellen, de úgy rémlik itt sem bizonyított, hogy nem lehet legalább valamilyen korlátozottan kontrollált (vagyis nem totál garbage lesz a plaintext) bit-flipping támadást kivitelezni, inkább csak jelenleg nem ismerünk rá módszert (leszámítva a visszajátszást, amit említettél).

De nem ezt akartam mondani az egésszel, hanem azt, hogy a LUKS nem célzott meg integritásvédelmet, ezt külön kell ráraknod egy további DM rétegként vagy checksum-oló filerendszert kell használni. A LUKS csak a dm-crypt target fogja kezelni. Vagyis a hír illetve cím megfogalmazását tartom hibás szenzációhajhásznak. Amint továbbolvasod látod, hogy utána éppen abból a feltételezésből indulok ki, hogy valaki korrektül konfigurálta a rendszert és megpróbált minden eddigi integritásvédelmi best practice-t betartani.

Tisztában vagyok vele, hogy a fizikai hozzáférés szintje többféle lehet. Viszont azt nem értem, hogy egy remote konzol hozzáférési szintnél hogy állhat elő az egész helyzet, amiben ennek a támadásnak egyáltalán értelme van.
1. TPM-ben vagy hasonló hardveres eszközben tárolva van a kulcs -> miért állna a meg az initramfs jelszó prompt-nál, miért nem bootol tovább?
2. Nincs tárolva a kulcs, de normális integritásvédelem van -> hogy jutott el az initramfs jelszó promptig, miért nem a bootloader jelszó promptnál áll?
3. Valaki a bootloader jelszót beírta, de otthagyta a gépet az initramfs jelszó prompttal -> hát igen, ezesetben van egy root shellje az initramfs-hez. De ha ez a helyzet, akkor nem hiszem, hogy lenne TPM-ben tárolt kulcs (miért nem ment tovább). Ráadásul elég valószínűtlen ez a helyzet.
4. Ha létezik olyan használati eset, hogy van trusted boot check, de mégis jelszavas ellenőrzés is be van kapcsolva, de nem a bootloadernél, csak az initramfs-ben -> ez az egyetlen eset ahol valóban van relevanciája a támadásnak

De tapasztalatból mit mondasz, gyakorlatban tényleg előfordul ez a 4. felállás?
---
Régóta vágyok én, az androidok mezonkincsére már!

"Az XTS a többihez képest valóban még a legjobban védett bit-flipping ellen, de úgy rémlik itt sem bizonyított, hogy nem lehet legalább valamilyen korlátozottan kontrollált (vagyis nem totál garbage lesz a plaintext) bit-flipping támadást kivitelezni, inkább csak jelenleg nem ismerünk rá módszert (leszámítva a visszajátszást, amit említettél)."

Hat ugye az i-edik XEX blokk visszafejtese ugy nez ki, hogy Pi = Dk (Ci ⊕ Δ) ⊕ Δ, ahol Δ a tweak-tol meg a kulcstol fugg, most mindegy is, hogyan. Ha feltetelezzuk, hogy az AES "jo" (PRP), eleg egyertelmu, hogy csak a ciphertext modositasaval a plaintextet befolyasolni nem tudod (ugyanez igaz az utolso 2 blokkra is). Kevesbe egyertelmu, de ugyanez igaz a tweak-ekre is.

"De nem ezt akartam mondani az egésszel, hanem azt, hogy a LUKS nem célzott meg integritásvédelmet, ezt külön kell ráraknod egy további DM rétegként vagy checksum-oló filerendszert kell használni. A LUKS csak a dm-crypt target fogja kezelni. Vagyis a hír illetve cím megfogalmazását tartom hibás szenzációhajhásznak. Amint továbbolvasod látod, hogy utána éppen abból a feltételezésből indulok ki, hogy valaki korrektül konfigurálta a rendszert és megpróbált minden eddigi integritásvédelmi best practice-t betartani."

Ja, ez tru.

"Ha létezik olyan használati eset, hogy van trusted boot check, de mégis jelszavas ellenőrzés is be van kapcsolva, de nem a bootloadernél, csak az initramfs-ben -> ez az egyetlen eset ahol valóban van relevanciája a támadásnak"

Yup. Altalaban a TPM-es bootot ugy implementaljak, hogy vagy a TPM-ben van a teljes kulcs es kell hozza az SRK jelszo, vagy a TPM-bol jon a kulcs fele, amihez meg hozzajon a jelszo (kulonben ha ellopjak a gepet, bekapcsoljak, akkor siman eljut a login promptig, ami az egesz ertelmet kerdojelezi meg) - utobbi szokott lenni a paranoidabb opcio, ha onmagaban nem bizol a TPM-ben. Normal esetben erre a legjobb tamadas az, ha modositod a bootloadert/kernelt hogy logolja a jelszot (fizikai hozzaferes #1), visszaadod a cuccot a juzernek, a juzer tapasztalja, hogy nem tud belepni (mert nem stimmel a kornyezet a TPM-nek), visszarakod az eredeti kernelt (fizikai hozzaferes #2), kiolvasod az elmentett jelszot, bebootolod, es valahogy megprobalsz atvergodni a login prompton es feltenni egy rootkit-et (a fs-t direktben nem modosithatod ugye, mert a TPM-es kulcsot nem tudod).
Ehhez kepest ezzel a vulnnal eleg ha egyszer hozzafersz a gephez, unseal-eled a TPM kulcsot, modositod a kernelt, hardcode-olod a kulcsot, es kesz.

--
"You're NOT paranoid, we really are out to get you!"

( dap | 2016. 11. 16., sze – 23:19 )

Pólót, bögrét lehet már rendelni hozzá? Ez vagy a Grinch hozza el a világvégét? Mikor bulvárosodott el ennyire a security iparág? Megannyi kérdésem lenne, de inkább alszok..

( laja | 2016. 11. 17., cs – 11:09 )

Tehat ha jol ertem: ez akkor johet elo, ha van fizikai hozzaferes? Es meg igy se fer hozza a titkositott particiokhoz? De akkor mire jo ez, ra tud rakni ennel a pontnal valami keyloggert vagy ilyesmit?