LUKS2: CVE-2020-14382 – out of bounds write

Zeit für ein Update von CryptSetup: CVE-2020-14382

LUKS2: CVE-2020-14382 – out of bounds write

CryptSetup ist das Tool, daß Luks Container, egal ob als Datei oder Festplatte, einhängt und/oder bearbeitet. Eine Lücke im Speicherhandling von CryptSetup kann von einem Angreifer ausgenutzt werden, indem er einen manipulierten Container einer anfälligen Version von CryptSetup präsentiert, was z.B. durch das Einstecken eines USB Sticks ausgelöst wird.

Die Lücke in CryptSetup sorgt dafür, daß weniger Speicher allokiert wird, als tatsächlich angegeben ist, aber von dem manipulierten Inhalt des Containers aufgrund mangelnder Grenzprüfungen, überschrieben werden kann. Damit gelangt ggf. Code an eine Stelle, die von einem anderen Prozess genutzt wird. Die Lücke CVE-2020-14382 kann also ggf. zu Arbitrary-Code-Execution führen, wenn es im System dumm läuft.

Daher empfehle ich Euch kurz mal nach dem Zustand Eures CryptSetup Befehls zu schauen und ggf. zu Updaten, denn auch wenn Ihr selbst keine Festplattenverschlüsslung benutzt, es reicht, daß das Paket auf dem System installiert ist und jemand einen USB Stick einsteckt.

Kleine Anmerkung zur Lage

Falls Ihr die Red Hat Securityliste lest, ist Euch auch aufgefallen, daß da heute ein ganzes Rudel (70+) Sicherheitsadvisories gekommen sind und die Bugs größtenteils Nummern aus 2018 und 2019 tragen? Ich glaube, da ist etwas arg schief gelaufen bei Red Hat.

LUKS: Wie man einen Cloud-Container erstellt.

Wer kennt das Bedürfnis nach Synchronisation des Dateibestandes von verschiedenen Geräten über einen Cloudanbieter aka Webhoster nicht? Ok, Ihr könnt jetzt zur nächsten OSBN News wechseln, außer Ihr möchtet an einem Zweitstandort eine sicher aufgehobene Kopie Eurer Daten haben, auf die nur Ihr Zugriff habt, dann lest jetzt weiter …

LUKS: Wie man einen Cloud-Container erstellt.

Verschlüsselungssysteme gibt es ja viele, aber nicht alle sind bei jeder Distro onboard und osübergreifend verfügbar, LUKS schon. Deswegen heute ein kleiner Beitrag wie man seine Daten bei einem Webhoster so parkt, daß man sie von überall aus einbinden kann.

ACHTUNG: Bei einer Cloud-Container-Lösung auf Basis von Luks oder Truecrypt darf nur ein PC das System aktiv einbinden, sonst Datenverlust! Möglich ist aber ein READ-ONLY-Einbinden mehrerer Rechner gleichzeitig. Ich warne ausdrücklich davor so etwas zu versuchen und es dann zu versemmeln!

Der Hintergrund für die Warnung ist ganz einfach der, daß Eurer PC der Meinung ist, daß er den Datenträger exklusiv hat und daher Sachen im RAM vorhält, die nicht auf den Datenträger synchronisiert sind um die Leistung zu steigern. Wenn zwei Rechner das machen und dann vermeidliche freie, aber vom anderen PC schon im RAM anvisierte Blöcke beschreibt, kommt es unweigerlich zum Datenverlust. Wer schon einmal mit SSHFS gearbeitet hat, das einen entfernten PC als Laufwerk einmountet, der wird bemerken, daß da keine lokale Pufferung stattfindet, weil der PC hier nicht wissen kann, ob und wer sonst noch so auf die Datenquelle zugegriffen hat. SSH greift auf der  anderen Seite auch nicht als Filesystem, sondern über die OS API auf Dateien zu und simuliert Euch nur ein Laufwerk.

Anders ist das, wenn zwar der Container per SSHFS verfügbar gemacht wird, aber das Einbinden des entschlüsselten Filesystems dann lokal stattfindet. Das findet dann wieder mit den OS eigenen IO-Steigerungsamethoden statt. Beim Mounten von Datenträgern kann man über die Mount-Options noch einiges abändern, da geht vielleicht sogar was, aber empfehlen kann ich das definitiv nicht.

Die Ausgangslage

Wir behandeln daher einen PC der auf einen Webserver zugreift, dort seinen Container lagert und die ganze Ent- und Verschlüsselung auf dem eigenen PC auflaufen lässt.

Wir brauchen: CryptSetup, einen Webserver, schnelles Internet ( ist von Vorteil )

Der Webserver

Der Webserver muß eine der folgenden Anbindungen unterstützen: SSH, SAMBA oder NFS und zwar genau in der Reihenfolge sollte man das auswählen. Für diesen Artikel nehme ich SSH, da das auf jedem LinuxPC vorhanden ist und der Transportweg so zusätzlich verschlüsselt ist. Da sieht man dann auch nicht, was da eigentlich auf dem Webserver gemacht wird.

Samba ist zwar mittlerweile auch im Datentransport verschlüsselt, aber viele Router halten das auf, damit die Windowskisten nicht das Providernetz vollspammen, die sind sehr mitteilungsbedürftig 😉

NFS kennt keine Authentifizierung außer IPs, ist unverschlüsselt und ist im allgemeinen bestenfalls zwischen Servern einzusetzen.

Das PRE-SETUP

Wir machen das alles als ROOT, weil CryptSetup und mount das gern so möchten. Da hier FUSE nur sekundär im Einsatz ist, weil es sich um normale Filesysteme des Kernels handelt (kommt gleich),  kommt mount zum Einsatz, welches zwingend als ROOT laufen möchte. Das Ergebnis der Aktion kann aber dann von jedem User benutzt werden. Wenn man sich da nicht besonders blöd im Rechtemanagement anstellt, dann ist das auch auf einem Mehrbenutzersystem kein Problem.  Kommen wir zu …

Schritt 1: Einen Mountpoint für den Container erstellen

mkdir -p /media/container/server

Der Ort ist in der Regel für jeden Benutzer erreichbar, was z.b. beim Mounten im eigenen Home nur für den aktuellen Benutzer gelten würde.

Schritt 2: Der Server als Laufwerk einbinden

sshfs demo@meine.demo.de:/home/demo /media/container/server -o allow_other

Je nachdem was man als Authmechnismus eingestellt hat ( KEY oder PASSWORD )  macht da der SSH-AGENT, der hoffentlich in irgendeiner Form bei Euch läuft ( gpg-agent, ssh-agent, gnome-keyring-daemon ) das mit dem Schlüssel automatisch für Euch, oder Ihr müßt ein Passwort eingeben.

Schritt 3: Das Containerfile anlegen

Hier im Beispiel benutze ich jetzt ein 100MB File ( 1M * 100 ) :

# dd if=/dev/zero of=/media/container/server/container.luks bs=1M count=100
100+0 Datensätze ein
100+0 Datensätze aus
104857600 bytes (105 MB, 100 MiB) copied, 29,0354 s, 3,6 MB/s

Wer da übers Netz GBweise Dateien anlegt, der sollte sich fragen, ob er verstanden hat, was er da gerade tut, denn das dauert Stunden und man könnte es ja auch auf dem Webserver erledigen lassen, daß dauert nur Sekunden, denn noch ist da weder Crypto noch ein Filesystem dran beteiligt, es wird nur ein BLOCK mit NULLEN erzeugt.

Schritt 4: Den Container mit LUKS formatieren

Der nächste Schritt sollte allerdings zwingend vom PC aus erledigt werden, da dazu ein Passwort nötig ist, welches, solange der Vorgang dauert, auch im Speicher des Webservers verfügbar wäre, würde man es dort tun. Das Formatieren dauert dann auch ein gutes Weilchen.

# cryptsetup -y luksFormat /media/container/server/container.luks

WARNING!
========
Hiermit werden die Daten auf »/media/container/server/container.luks« unwiderruflich überschrieben.

Are you sure? (Type ‚yes‘ in capital letters): YES
Geben Sie die Passphrase für »/media/container/server/container.luks« ein: ***********************
Passphrase bestätigen: ***********************

Ein sinnvoll langes Passwort > 20 Zeichen ist angeraten! Es sollte nicht 123456789… lauten 😉

Schritt 5: Den Container öffnen und zum Mounten bereitstellen

Dieser Schritt geht dann recht zügig von statten. Ihr müßt nicht zwangsweise den gleichen Cryptocontainernamen benutzen wie ich, da seid Ihr flexibel.

# cryptsetup luksOpen /media/container/server/container.luks cryptocontainer
Geben Sie die Passphrase für »/media/container/server/container.luks« ein: ***********************

Schritt 6: Das Filesystem erstellen

Beim ersten mal muß man jetzt das Filesystem einrichten:

# mkfs.ext4 -j /dev/mapper/cryptocontainer
mke2fs 1.45.5 (07-Jan-2020)
Ein Dateisystem mit 86016 (1k) Blöcken und 21560 Inodes wird erzeugt.
UUID des Dateisystems: bcbccb1b-794e-4700-bd64-cd021a42bf32
Superblock-Sicherungskopien gespeichert in den Blöcken:
8193, 24577, 40961, 57345, 73729

beim Anfordern von Speicher für die Gruppentabellen: erledigt
Inode-Tabellen werden geschrieben: erledigt
Das Journal (4096 Blöcke) wird angelegt: erledigt
Die Superblöcke und die Informationen über die Dateisystemnutzung werden geschrieben: erledigt

ich habe jetzt EXT4 ausgewählt, weil das in jedem Kernel vorkommt und als Journalingfilesystem keine ellenlangen Reparaturen vor dem Mounten braucht, was gerade bei einem Netzwerkcontainer ein wichtiger Entscheidungsgrund ist, sonst wartet Ihr da auch schon mal Stunden auf den Mount.

Schritt 7: Den Containerinhalt ins System einbinden

Das Einbinden in das System ist dann denkbar einfach:

# mount /dev/mapper/cryptocontainer /mnt
# df -h | grep mnt
/dev/mapper/cryptocontainer 78M 1,6M 70M 3% /mnt

Das wärs schon, wenn da nicht das Zugriffsproblem wäre. Also muß Root da jetzt z.B. noch ein Verzeichnis anlegen, weil die User keine Schreibrechte haben:

# ls -ls /mnt/
insgesamt 12
12 drwx——. 2 root root 12288 13. Sep 12:01 lost+found
# ls -lad /mnt/
drwxr-xr-x. 3 root root 1024 13. Sep 12:01 /mnt/
# mkdir /mnt/demo
# chown demo:demo /mnt/demo
# chmod 700 /mnt/demo/
# ls -ls /mnt
insgesamt 14
2 drwx——. 2 demo demo 1024 13. Sep 12:10 demo
12 drwx——. 2 root root 12288 13. Sep 12:01 lost+found

Nun kann der Benutzer „demo“ da machen was auch immer er möchte.

Einbinden beim System-Boot

Das ist nicht ganz ohne. Man könnte dem Cron sagen, daß er das nach dem Boot machen soll, indem man da ein kleines Script benutzt, daß alle Schritte als Root macht, aber wer sagt uns, daß das auch passiert, wenn ein Netzwerk vorhanden ist? Niemand, also müssen wir das wohl oder übel an den Systemd übergeben. D.b. Ihr schreibt einfach ein kleines Start/Stop Script nach /etc/init.d/ oder direkt eine Unit für Systemd direkt, in dem die Anhängigkeiten zum erfolgreichen Netzwerkstart angegeben sind z.b. wie hier:

xl2tpd.service:After=network.target

So ist sichergestellt, daß es auch klappen kann, sofern alles mit dem Netzwerk und dem Server ok ist.

Sicherheitsanalyse

Wo liegen hier die Vorteile zu einem USB Stick? Zum Einen macht der Hoster normalerweise ein Backup von dem Server oder bietet Euch zumindest an, daß Ihr eins machen könnt. Dann ist das von überall aus erreichbar und i.d.R. kann man das nicht verlieren. Auch ein „Diebstahl“ wäre nicht tragisch, da der Dieb nicht an den Inhalt kommt, außer Eurer Passwort war „123456“ 😀

Die gesamte Ver- und Entschlüsselung der Daten findet zur Laufzeit auf Eurem PC statt, d.b. jemand muß sich Zugang zu Eurem PC verschaffen und dann auf die Daten zugreifen, wenn diese lokal verfügbar sind. Das könnt Ihr mit Updates und Festplattenvollverschlüsselung leicht kontern, denn dann können Euch lokale Angreifer mal am ….. . Auf diese Sicherheit müßt Ihr sowieso bauen, da ansonsten der Aufwand die Daten verschlüsselt im Netz zu speichern kompletter Unfug wäre. Also ganz klar: Entweder alles oder nichts verschlüsseln, sonst nützt es im Zweifel nichts.

VeraCrypt vs LUKS

Aus Benutzersicht ein klares Ja zu VeraCrypt: Kommt mit GUI und bindet sich ohne Root auch beim Login automatisch per FUSE ein.. 1a!

Der LUKS Container hat aber den Vorteil, daß man damit nur den Leuten vertrauen muß, die sowieso schon Eurer OS zusammenbauen. Wenn man denen nicht trauen würde, könnte man auch VeraCrypt nicht einsetzen, weil wenn das OS unsicher ist, wozu dann noch Verschlüsseln?

Über die /etc/crypttab kann LUKS Medien auch automatisch ins System einbinden lassen, allerdings muß zu dem Zeitpunkt das Netzlaufwerk mit dem Container verfügbar sein, sonst ist Essig. Hat also alles Vor- und Nachteile. Welche davon für Euch interessant sind, müßt Ihr entscheiden.

Wie bekomme ich den Container wieder zu?

Wichtige Frage, einfache Antworten:

umount /media/container/server
cryptsetup luksClose cryptocontainer
fusermount -u /media/container/server

Zwei Sicherheitslücken auf die wir lange warten mußten!

Darauf mußten wir lange, lange warten:

THN: 36 Jahre alte Sicherheitslücke in SCP entdeckt!

Wie die Hacker News berichten, gibt es in SCP eine 36 Jahre alte Lücke, die es einem böswilligen Server erlaubt, beliebige Files beim Benutzer zu überschreiben.Da fast alle Implementierung vom alten Originalcode abstammen, sind sehr viele Anwendungen davon betroffen. Es können z.B. verstecke Bash-Files im Home (eines Unix/Linux/Macusers ) erzeugt werden, die als ANSI Codes übermittelt werden. Möglich wird die mangels guter Prüfung des erhaltenen Contents durch SCP. Da scp üblicherweise in der Shell eingesetzt wird, könnte das praktische ausnutzen der Schwachstelle in der Regel schwierig werden, da man sich nur zu bekannten Server mit SCP verbindet. Jemanden da per Spam hin zu bekommen, könnte schwer fallen.

Auch lange warten mußten wir auf diese Meldung, die nicht minder prikär ist, vielleicht sogar noch schlimmer:

heise.de : Forscher brechen aus Docker-Container aus

Ich persönlich warte ja schon länger auf diese Meldung, aber verwundern wird sie wohl keinen. Die Hauptkritik an Container ist ja, daß die darin enthaltene Software nicht aktuell gehalten sein wird, weil sonst könnte der Entwickler die Anwendung ja auch prima auf einem normalen System starten. Natürlich gibt es noch andere Gründe für einen Container: Transferierbarkeit, Skalierbarkeit  usw. aber uns interessiert die Sicherheit natürlich mehr. Wenn ich jetzt Software von Anno Schnee in einem Container habe, der nicht aktualisiert wird, weil „wieso, geht doch!“, das übliche Argument der Neulandmanager halt, dann habe ich jetzt endlich den Exploit, der mir bisher fehlte, um aus dem Schrott auszubrechen. VMs sind übrigens nicht anders, nur einer VM kann ich ( ICH!! ) sagen, daß das System dadrin aktualisiert werden soll. Bei „Docker“ ist das ein Heckmeck sondergleichen, wenn die Funktion nicht vorgesehen ist.

Die „Play with Docker“ Containerumgebung wird nicht die Einzige sein, die mit „wieso, kann doch keiner ausbrechen“ als Argument, die Anwendung mit erhöhten Rechten laufen läßt. Es wird also spannend werden, wenn man Docker einsetzt. Eine Lücke mehr, die man stopfen muß. Das sollte man sich vor Augen halten.

Bullshit: Snappy auf Fedora

In einem Blog-Beitrag auf seiner Webseite hat sich Adam Williamson, seines Zeichens bei Red Hat für die Fedora QA/QS zuständig,  über Snappy und die unglückliche Pressemitteilung von Ubuntu ausgelassen.

Kurz zusammengefaßt heißt es da, daß Ubuntu bei Fedora zwar wegen Snappy angefragt hat, aber nur zu dem Zweck, um zu erfahren, wie man die Pakete für Fedora bauen muß. Ansonsten gibt es  keine Zusammenarbeit von Ubuntu und Fedora in dem Punkt.

Die weiteren Statements sind privater Natur und spiegeln wider, was auch ich über so ein Vorhaben wie Snappy denke. Dazu muß man jetzt aber wissen, was Snappy machen soll.

In der Kurzfassung: Snappy ermöglicht es Dockercontainer gleich, eine Anwendung mit all Ihren Libs und Konfigfiles als Ganzes unabhängig vom Betriebssystem in einem dicken BinaryBlob (ein monolithisches Binärfile) zubündeln und damit direkt ausführbar zu machen. Als Folge davon, und das ist der Hauptkritikpunkt, handelt man sich ggf. komplett veraltetet Versionen ein, weil der Entwickler des eigentlich Hauptprogramms keinen Bock hat, seine Anwendung auf Stand zu halten. Im Prinzip hat man eine LTS Version, nur völlig ohne das S , was hier wahlweise für Support oder Sicherheit stehen kann.

Dazu kommt laut AdamW noch, daß Ubuntu Fedora Pakete ohne das Confinement anbietet, was die einzige Sicherheitshürde darstellt, wenn es denn überhaupt an ist. Confinement meint, das Ausführen in einer Sandbox, wo eine Sicherheitslücke in der Anwendung eben gerade nicht das Hostsystem kompromitieren kann.

Dieser Punkt ist aber IMHO nicht verhandelbar. Es muß immer sicher sein und unsichere Softwareversionen kommen einfach nicht auf den Tisch. Man muß sich ernsthaft fragen, ob bei Ubuntu noch alle Latten im Zaun sind, seid Sie mit Microsoft enger zusammenarbeiten.

Am Ende möchte ich AdamW noch kurz zu Wort kommen lassen 🙂

This is, to put it diplomatically, a heaping pile of steaming bullshit. You may not be surprised to learn that said pile has been served by the Canonical press department.

Noch Fragen ? 😀