[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: CVE-2016-4484: - Cryptsetup Initrd root Shell



Sascha Reißner schrieb am 18. Nov um 05:00 Uhr:
> Am Donnerstag, den 17.11.2016, 20:56 +0100 schrieb Christian Knoke:
> > Sascha Reißner schrieb am 17. Nov um 14:14 Uhr:
> > > Sobald der LUKS-Container aufgesperrt ist, kann man den Stick bereits
> > > abziehen, da alle nötigen Sachen in der initramfs liegen die ja schon im
> > > RAM ist.
> > > Da ein LUKS-Container einen Header hat, ist dies die einzige Information
> > > die ein Angreifer bekommt und wieviele aktive Key-Slots vorhanden sind.
> > 
> > Dieser Header ist auch ein Schwachpunkt, weil man allein auf den header,
> > ohne den Rest der Platte, einen brut force angriff machen kann.
> > 
> > Der angreifer klaut erst den header, und bei seinem zweiten Besuch kann er
> > das System modifizieren.  Er muss nicht mehr die ganze Platte kopieren,
> > sondern kann gezielt nach Informationen suchen.
> 
> Das ist mir klar. Ich spielte auch mit dem Gedanken die Platte mit
> crypt-setup ohne LUKS zu verschlüsseln.

das hatte ich versucht, aber die Scripte wollten kein key file vom Stick
einlesen.

> Dadurch gibt es garkeinen Header
> und die Platte ist auch voll verschlüsselt. Nachteil ist aber, daß man
> das Key-File später nicht tauschen kann (außer man macht ein volles
> Backup der Daten und formatiert die Platte komplett neu).

grundsätzlich sollte es möglich sein, nach backup und umount das blockdevice
umzuschlüsseln. In einem Prozess lesen (ein wenig 500 mb voraus) und im
anderen schreiben.

> Mit LUKS hab ich die Möglichkeit später das Key-File zu tauschen.

> Ohne LUKS müsste ich das Key-File irgendwo ganz sicher aufbewahren,
> damit ich im Falle eines kaputten oder verloren gegangenen Sticks an
> meine Daten komme.

Ohne LUKS würde man das key file, das dann ja den Plattenschlüssel enthält,
seinerseits mit einer pass phrase schützen. Der Vorteil ist, dass auf den
geschützten Schlüssel kein brute force Angriff möglich ist, wenn die pass
phrase lang genug ist (sie müsste aber auch nicht extrem lang sein) und wenn
dem Angreifer nicht gleichzeitig der Platteninhalt zu Verfügung steht.

> Ein dritter Gedanke kommt mir da:
> Man kann ein Backup vom LUKS-Header ziehen.
> Ob LUKS den Header direkt vor dem Container braucht, hab ich noch nicht
> geprüft. Wenn das nicht erforderlich ist könnte man den Header ebenfalls
> auf den Stick schreiben und den auf der Platte löschen.
> Dazu muß man aber die Start-Scripte, die den LUKS-Container öffnen,
> anpassen, damit diese den LUKS-Header in der Datei auf dem Stick
> verwenden um den Container auf der Platte zu öffnen.
> Oder man fügt 2 Scripte hinzu. Das erste schreibt beim Start des
> Rechners das Backup wieder am Anfang der Platte. Das andere läuft als
> letztes beim Shutdown und überschreibt den Header auf der Platte wieder
> mit Datenmüll.

ich denke zumindest die 2. variante ist zwar holprig, aber möglich.

> Bei beiden Varianten wird das Header-Backup-File zur wichtigsten Datei
> die man irgendwo absolut sicher verwahren muß für den Fall eines
> kaputten Sticks.

ist aber nicht so dass Problem, weil man ohne die Plattendaten nicht viel
damit anfangen kann.

> Vielleicht ist jetzt dem Einen oder Anderen von Euch noch etwas
> eingefallen.
> 
> -- 
> mfG Sascha

Gruß
Christian

-- 
Christian Knoke            * * *            http://cknoke.de
* * * * * * * * *  Ceterum censeo Microsoft esse dividendum.


Reply to: