6x 0-Day in Exim Mailserver

Nein, ich weiß auch nicht mehr als Ihr, auch wenn es mal wieder um Exim geht. Details sind nur spärlich zu haben.

6x 0-Day in Exim Mailserver

Mitte 2022 wurde von Trend Micro an das Exim Team eine Liste von 6 Lücken gemeldet, von denen jetzt 3 soweit abgedichtet wurden:

CVE-2023-42114 https://www.zerodayinitiative.com/advisories/ZDI-23-1468/ 3001 fixed

CVE-2023-42115 https://www.zerodayinitiative.com/advisories/ZDI-23-1469/ 2999 fixed

CVE-2023-42116 https://www.zerodayinitiative.com/advisories/ZDI-23-1470/ 3000 fixed

CVE-2023-42117 https://www.zerodayinitiative.com/advisories/ZDI-23-1471/

CVE-2023-42118 https://www.zerodayinitiative.com/advisories/ZDI-23-1472/

CVE-2023-42119 https://www.zerodayinitiative.com/advisories/ZDI-23-1473/

Wenn man sich die Timeline ansieht, dann bemerkt man, die langen Phasen des Stillstands. Über Monate wurde nichts gemacht. Jetzt ist es Trend Micro „zu blöd“ geworden und sie haben ein Veröffentlichungsdatum gesetzt. Das war Mittwoch! Es hat aber bis gestern Abend gedauert, bis es Reaktionen gab.

Heiko Schlittermann vom Exim-Team, den Ihr alle noch aus dem Exim-Exploit-Talk „21Nails“ vom LPD 2021 kennen dürftet, meinte dazu, daß zu 3 von den 6 Lücken gar nicht ausreichend Infos geschickt worden waren, so daß man die Fehler nicht reproduzieren konnte. Ich glaube ihm das sofort, denn im Zuge der 21Nails 2021 war es ähnlich. Da reportet eine auf Code-Analyse spezialisierte Firma Bugs im Code, benennt Stellen, lieferte aber kaum Material, wieso das eine Lücke wäre bzw. wie man das Ausnutzen könnte.

Nur durch die Fixe weiß man bis jetzt um was es geht.

CVE-2023-42116:  OOB-Write NTLM Authvorgang. (Geht hoffentlich nur, wenn man NTLM auch als AUTH drin hat. )
CVE-2023-42114:  OOB-Write NTLM Authvorgang. ( klingt wie eine Abart von 42116 )

CVE-2023-42115/7/8/9: sind alles  OOB Writes im SMTP-Teil, weil nicht richtig geprüft wird, wie lang das ist, was da gesendet wird.

Übers Wochenende wird es dann wohl mehr Infos geben. Ich kann Euch nur raten, wenn Ihr Exim einsetzt, die entsprechenden Stellen Eurer Distro so zu nerven, daß die auf Zack sind. EINE mögliche DEADLINE endet Sonntag Abend Ortszeit 🙁 Wenn bis dahin die Fixe nicht verteilt sind, geht das Rennen um die Exploits los und dann könntet Ihr die Verlierer sein. Ich überlege gerade, ob ich meine Exims nicht einfach selbst kompilieren, denn auch bei Fedora ist Funkstille. Ich habe genug Lärm gemacht, damit jeder dort weiß, das was dringendes im Busch ist. Ich hoffe es reicht, denn Zugang zu den geschützten Repos von Exim haben nur die großen Distros.

Fedora – Notfall Firefox Updates vorhanden

Kaum eine Woche ist die letzte Krise her, da müssen wir schon wieder ran: Lücke in WebP

Fedora – Notfall Firefox Updates vorhanden

Auch diesmal bedurfte es erst einmal einer Email, bevor das Update gebaut wurde. Irgendwas hakt da gerade im Fedoragetriebe.

Für Fedora 37 installiert Ihr das als Root so:

dnf update https://kojipkgs.fedoraproject.org//packages/firefox/117.0.1/1.fc37/x86_64/firefox-117.0.1-1.fc37.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/firefox/117.0.1/1.fc37/x86_64/firefox-langpacks-117.0.1-1.fc37.x86_64.rpm

Für Fedora 38 so:

dnf update https://kojipkgs.fedoraproject.org//packages/firefox/117.0.1/1.fc38/x86_64/firefox-117.0.1-1.fc38.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/firefox/117.0.1/1.fc38/x86_64/firefox-langpacks-117.0.1-1.fc38.x86_64.rpm

Diesmal reicht es aber nicht nur Firefox zu updaten, sondern Ihr dürft auch:

Thunderbird
Chromium
Schildichat
Element

und jede andere App updaten, die die libwebp.so nutzt.  Für Schildichat ist nicht mal ein Update verfügbar. Ich war da mal so frei, ein Issue da zu lassen. Ihr müßt da den von Euch genutzten Softwarepark selbst mal durchsehen!

Der Ghostscript Exploit, der in andere Anwendungen eskaliert

Vor einigen Tagen hatte ich ja was zum Kernel Bug geschrieben, nämlich, daß ich mir mehr Sorgen mache, daß eins der Desktopprogramme geknackt wird. Jetzt ist es bei Ghostscript soweit.

Der Ghostscript Exploit, der in andere Anwendungen eskaliert

Ghostscript < 10.1.02  hat eine Schwachstelle, die das Ausführen von Code erlaubt. Das an sich ist schon schlimm, wenn man dann erfährt, daß das bei den Maintainer untergegangen ist 🙁

Schlimmer ist aber, daß die Lücke in andere Anwendungen wie InkScape, LibreOffice und Gimp eskaliert, dort also auch funktioniert. Möglich macht dies das Äquivalent der größten Container-Sorge überhaupt: Diese Anwendungen halten sich eine selbst gepatchte Version von Ghostscript in der Codebasis und naja, in der ist der Bug auch drin.

Das ist vergleichbar mit einer Sammlung von Docker Containern,Snaps & Flatpaks, welche alle die gleiche ausnutzbare libPNG drin haben und jetzt alle geupdated werden müssen, wo ja eigentlich nur eine Komponente das Update wirklich bräuchte: Ghostscript. Was zeigt das: Dumme Entscheidungen brauchen kein Containermodell 😉

Anstatt einer Komponente, müssen jetzt ein Haufen unübersehbarer Anwendungen aktualisiert werden, wozu man erstmal rausfinden muß, wo das überall drin ist. Das muß man erst mal schaffen. Log4J lässt so derbe grüßen, daß heute wohl Murmeltiertag ist.

Da zu allem Überfluss ein POC-Exploit bekannt ist, werden echte Exploits nicht lange auf sich warten lassen.

Die Situation auf Debian ist besser als die von Fedora, weil Debian immerhin das erste GS Update ausgeschickt hat, bei Fedora aber nichts am Horizont ist. Dagegen habe ich mal was gemailt…

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36664

https://www.kroll.com/en/insights/publications/cyber/ghostscript-cve-2023-36664-remote-code-execution-vulnerability