PVA: kleines Sicherheitsloch im IMAP Modul

Wie das so mit komplexer Software ist, CVE Meldungen sind quasi vorprogrammiert, aber einfache Programmierfehler tun es meistens auch 🙁

PVA: kleines Sicherheitsloch im IMAP Modul

Jetzt ist der Einschlagkrater durch die im PVA gefundene Sicherheitslücke nicht besonders groß, man müßte Ihn vermutlich mit der Lupe suchen, weil kaum wer von dem neuen Feature wußte und es ausprobiert hat, aber, zur Vermeidung gleichartiger zukünftiger Unfälle, soll die Lücke seziert und dokumentiert werden.

Was ist passiert?

In der MailConnection-Komponente, die macht die IMAP Verbindung auf, war ein Programmierfehler drin, der die verschlüsselte Verbindung zum IMAP Server unterband. Wer also die neue Funktion schon ausprobiert hat , muß mindestens auf diesen Commit updaten: 685ee5ecaa486006a0cee04cac763ee479160e6e

Hier der fehlerhafte Code:

Properties props = System.getProperties();
if ( m.secure == true ) {
       props.setProperty("mail.store.protocol", "imaps");
} else props.setProperty("mail.store.protocol", "imap");

Session session = Session.getInstance(props, null);
Store store = session.getStore("imap");
store.connect(m.servername, m.username, m.password);

Statt die laut Konfiguration (m.secure) gewünschte Verbindungsart „imaps“ zu wählen, zog es der Code vor, dann doch unabhängig davon „imap“ zu verwenden. Korrekt wäre diese Zeile gewesen:

Store store = session.getStore();

Was war die Ursache?

Als Ursache konnte „mangelndes Verständnis“ der Methode getStore(…) ausgemacht werden, um genau zu sein, wurde erwartet, daß es sich um den Unterschied zwischen „POP3“ oder „IMAP“ handelt, weil der Sicherheitslevel wurde ja vorher schon festgelegt, aber leider überschrieb der Aufruf diese Voreinstellung wieder.

Was müßt Ihr tun?

Im Repo ist das Update bereits enthalten, so daß alle die, die Automatische Updates einspielen, schon sicher sind.
Wer seinen PVA selbst baut, der muß einmal updaten und compilieren.

Wie wurde es gefunden?

Vor 11 Jahren, ja, einfach weiterlesen, entschied ich, daß meine POP3/IMAP Serverlogs von einer Software auf genau diese unverschlüsselten Verbindungen prüft und den Benutzer darüber informiert, daß er irgendwo eine unsichere Konfig hat. 11 Jahre lang habe ich keine Email erhalten, und jetzt rettet dieses kleine Script dem PVA den Arsch 😉

PS: Falls wer dachte, daß man im Github einfach mal so ein Security Advisory schreiben könnte, der hat das noch nie versucht und mir ist jetzt klar, warum so viele Projekte mit Lücken, keine Securityeinträge haben 🙁

BleedingTooth: Remote Code Execution in BlueZ Kernelstack

Kritische Sicherheitslücke im Bluetooth-Stack von Linux und Android entdeckt. Bluetooth eingeschaltet zu haben, reicht aus um angreifbar zu sein.

BleedingTooth: Remote Code Execution in BlueZ Kernelstack

Kritische Sicherheitslücke im Bluetooth-Stack von Linux vor Kernel 5.9 entdeckt. Der Fix wurde am 29.9. bereits heimlich in einen Kernel Branch eingepflegt und wartet seitdem auf den Merge in den Hauptkernel. Erst für Kernel 5.9 war das der Fall, so daß derzeit alle Geräte die mit Linux angreifbar sind, bis auch dort Backportpatche verfügbar sind.

Gefunden hatten diese Lücken Intel ( „Intel – wie konnte das passieren, die finden doch sonst nichts“ )  und Google. Bei Google kann ich das verstehen, die verdienen damit Geld, aber Intel? 😉

Also RCE, Remote Code Execution, und das auch noch ohne Anmeldung. Meint: Jedes Gerät mit aktiviertem Bluetooth in der Nähe ist angreifbar, nur weil es da ist. BleedingTooth ist dabei nicht nur eine Lücke, sondern ein ganzes Sammelsurium an Schwachstellen, die kombiniert, den RCE mit Privilegien Eskalation erlauben.

Bis auf weiteres: BlueTooth abschalten!

Quellen:

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html

https://github.com/google/security-research/security/advisories/GHSA-h637-c88j-47wq  ( Die erlaubt die Code Ausführung )

 

CryptSetup: Update behebt CVE-2020-14382

Hi,

wer von Euch LUKS2 einsetzt sollte jetzt weiterlesen und nebenbei schon mal schauen, ob die Updates eingespielt sind.

CryptSetup: Update behebt CVE-2020-14382

CryptSetup fällt auf manipulierte Dateien herein, die sich als Luks2 Container ausgeben. Möglich ist es, damit ein nicht vorgesehenen Schreibzugriff auszulösen. Das ist per se nicht gut für Eure Datenintegrität 😉

Behoben wurde die in Version 2.2.0 eingeführte Ursache mit dem Update auf 2.3.4.

Nicht betroffen ist, wer Luks nicht benutzt um manipulierte Datencontainer aufzumachen aka. nicht auf alles draufklicken, was per Post kommt 🙂

Problematisch wird das nur, wenn jemand einen manipulierten USB Stick bei Euch einschieben kann, der sich als LUKS2 Laufwerk ausgibt. Da solche Laufwerke automatisch eingebunden werden, wird der Container sofort geöffnet. Hier hilft USB-Guard weiter, der nicht autorisierte USB Geräte gar nicht erst an das OS lässt.

Updates für Fedora gibts z.B. so:

sudo dnf update https://kojipkgs.fedoraproject.org//packages/cryptsetup/2.3.4/1.fc31/x86_64/cryptsetup-2.3.4-1.fc31.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/cryptsetup/2.3.4/1.fc31/x86_64/cryptsetup-libs-2.3.4-1.fc31.x86_64.rpm

Quelle: https://access.redhat.com/security/cve/CVE-2020-14382