Názory k článku
Zranitelnost LUKS 2.2.0 a novějších, disk jde rozšifrovat bez hesla

Mám zašifrované disky pomocí verze 2.2.2. Je po nainstalování opravené verze nutno nějak manuálně aktualizovat hlavičky, nebo se to udělá samo?

Žádná aktualizace hlavičky není nutná, mění se pouze formát metadat pro probíhající reencryption operaci. Tj. pokud si teď pustíte cryptsetup reencrypt --decrypt tak se s novou verzí cryptsetupu zapíší do hlavičky nová metadata, nic dalšího se nemění.

Ahoj, bud sa stracam, alebo tomu len nerozumiem.
cryptsetup reencrypt co je preferovana metoda oproti "alternative" cryptsetup-reencrypt commandline prikazu by --decrypt znemanlo: Remove encryption (decrypt already encrypted device and remove LUKS header). WARNING: This is destructive operation and cannot be reverted. Cize kompletne zrusim LUKS co nechcem.


$ sudo cryptsetup-reencrypt --decrypt container.img
$ cryptsetup luksDump container.img
Device container.img is not a valid LUKS device.


Ci?

cryptsetup reencrypt -- změna paramterů šifrování (např. změna šifry nebo master klíče)

cryptsetup reencrypt --decrypt -- dešifrování aktuálně zašifrovaného zařízení

cryptsetup reencrypt --encrypt -- zašifrování aktuálně nešifrovaného zařízení

Všechny tři tyhle akce si zapíší metadata do LUKS hlavičky, aby v případě přerušení šlo tu operaci obnovit a <b>jen tahle metadata</b> se mění (jsou nově podepsaná, aby nešlo podvhrnout probíhající dešifrování). Tj. není třeba nic dělat, v LUKS hlavičce jako takové se nic nemění a pokud si s novým cryptsetupem některou z těch operací pustíte, tak se použijí nová reencryption metadata.

No takže si to opravme, "Zranitelnost LUKS umožní útočníkovi přinutit cryptsetup, aby po zadání hesla celý disk odšifroval" což je sice nepříjemné, ale už to není žádná senzace.

Taky v tom nevidím žádnou tragédii. Jo, kdyby to dokázal bez hesla to je něco naprosto jiného. Evidentně se jedná o velmi specifickou variantu např. cloudové servery, kdy vlastníci hw infrastruktury jenž mají v hw fyzický přístup toto mohou využít a vlastník dat používající remote přístup má hold smůlu.

Tak pokud má správce přístup k HW, tak si klíče může prostě najít v RAM a nemusí dělat takovéhle opičárny.

Pokud se nepletu, kazdy inteligentni program uklada klice do nejake formy chranene pameti, tj. "proste najit v RAM" nema byt mozne.

Tak v tom případě jsem moc inteligentních programů neviděl. Ono taky moc „chráněné paměti“ v implementacích např. virtualizace neexistuje…

Jedná se o velmi standardní variantu, kdy zálohuješ na LUKS svazek připojený přes síť.

„Útočník pak může také proces také obrátit a znovu disk nechat zašifrovat.“

Co to znamená?

ransomware bude o par kilobajtov mensi, lbo sifrovanie za neho spravi luks... On len doda heslo od utocnika a ten bude vydierat jeho znalostou/spris­tupnenim za poplatok...

že útočník získal data a může to zpět opět zašifrovat, aby si toho nikdo nevšiml

Při čtení zprávičky jsem nepochopil, že jde o to, že reencryption podporuje i decryption, a toho se zneužívá - myslel jsem si, že jde jen o nějaký problém typu že útočník vynutí použití staré hlavičky nebo tak něco. Ale tohle je teda hustý.

Tak to uz je jedno jestli to utocnik desifruje uplne, nebo jen vyvola presifrovani vlastnim znamym klicem, pomoci ktereho si to pak desifruje sam.

No ne, tak, jak jsem to pochopil ze zprávičky, by to bylo podstatně méně závažné.