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.

Bitlocker unter Linux öffnen

Ihr erinnert Euch noch diesen c’t Uplink Beitrag, wo die Heise Redakteure über Bitlocker und Luks schwadroniert haben?  Damals wurde Bitlocker als „properitär“ eingestuft und sinngemäß gesagt:  „Um Festplatteverschlüsselung zu machen, brauchst Du eh die PRO Version, die Home kann das nicht“. Da hat sich was getan 😉

Bitlocker für Linux

Vor drei Tagen kam eine Updatemeldung von Fedora zu einem Produkt namens „Dislocker“ rein. Der Name versprach etwas spannendes, also habe ich mir die Meldung angesehen:

Name        : dislocker
Product     : Fedora 28
Version     : 0.7.1
Release     : 10.fc28
URL         : https://github.com/Aorimn/dislocker
Summary     : Utility to access BitLocker encrypted volumes
Description :
Dislocker has been designed to read BitLocker encrypted partitions ("drives")
under a Linux system. The driver has the capability to read/write partitions
encrypted using Microsoft Windows Vista, 7, 8, 8.1 and 10 (AES-CBC, AES-XTS,
128 or 256 bits, with or without the Elephant diffuser, encrypted partitions);
BitLocker-To-Go encrypted partitions (USB/FAT32 partitions).

Das Tool gibts als FUSE Modul, so daß die Bitlocker-Partition zur Laufzeit eingebunden und Gelesen sowie Geschrieben werden kann, und als Einmal-Komplett-Entschlüssler. So oder so, man kommt an die Daten ran.  Damit ist Linux jetzt Windows offiziell voraus 😀

Ob das eine gute Idee war/ist wird sich zeigen, aber eins kann man Bitlocker damit nicht mehr nennen: properitär. Zumindest nicht mehr im ganz engen Sinn. Es wird natürlich nur von M$ produktiv eingesetzt, aber immerhin, wie auch bei NTFS, kann man es jetzt auf anderen Plattformen ( Ja, Macs machen auch mit ) benutzen.

@Heise-Redaktion: Wird Zeit für einen neuen c’t Uplinkbeitrag zu dem Thema. Da könnt Ihr gleich die ganzen Gerüchte vom letzten mal berichtigen, von wegen Luks wäre unpraktisch, keine Passworteingabe usw. usw. 😀 PS: wenn Ihr schon dabei seid: Mit LUKS einen USB Stick verschlüsseln und Double Layer Encryption mit Veracrypt falls Euch die Beispiele ausgehen 😉

Fehler in der Security

Der Grund für das Update war dann übrigens das Beheben von drei CVE-Schwachstellen in der genutzten Cryptobibliothek, wie man auf der Projektseite nachlesen konnte u.a. :

ID: CVE-2018-0497
Impact: Allows a remote attacker to partially recover the plaintext
Severity: High

Im Bereich Crypto ist das quasi eine 11 von 10 möglichen Punkten auf der Richterskala (+1 weils Remote geht  😉 ).

Den Schlüssel für die Bitlocker Partition könnt Ihr bei Microsoft erfragen, falls Ihr den vergessen haben solltet 😉