[English]Noch ein kleiner Nachtrag von Ende letzter Woche. Im Mail Transfer Agent (MTA) und Open Source Mailserver gibt es gleich mehrere kritische Schwachstellen. CERT-Bund warnt vor diesen Schwachstellen, da Angreifer über den SMTP-Dienst beliebigen Code ausführen könnten. Inzwischen haben die Entwickler Sicherheitsupdates bereitgestellt. Wer den Exim MTA als Mailserver einsetzt, sollte diesen dringend umgehend patchen.
Anzeige
Was ist Exim?
Das Kürzel Exim steht für EXperimental Internet Mailer, ein Mail Transfer Agent und Mailserver. Das Programm wurde 1995 an der University of Cambridge von Philip Hazel entwickelt, ist freie Software und ist aus Smail-3 hervorgegangen. Exim ist weitgehend aufrufkompatibel zu dem traditionsreichen MTA Sendmail.
Die besondere besondere Stärke von Exim liegt in einer sehr flexiblen, aber trotzdem einfachen Konfiguration. So kann Exim Daten aus einer Vielzahl von Datenquellen/Datenbanken extrahieren und auch flexibel weiterverarbeiten bzw. speichern. Weiterhin verfügt Exim über eingebaute Reguläre Ausdrücke (PCRE) und eine einfache, aber sehr mächtige Skriptsprache. Exim erlaubt es außerdem, einen Perl-Interpreter einzubinden, wodurch eigene Perl-Skripte benutzt werden können, die dann z. B. Anbindungen an andere Datenbanken ermöglichen oder besondere Prüfungen durchführen.
Warnung des CERT-Bund
Mir ist bereits zum Wochenende die Warnung des Bundesamts für Sicherheit in der Informationstechnik (BSI) vor (damals) ungepatchten Schwachstellen in Exim untergekommen.
Anzeige
Ältere Versionen des Open Source Mail Transfer Agent (MTA) Exim weisen gleich mehrere schwerwiegende ungepatchte Schwachstellen auf. Besonders kritisch die Buffer Overflow Schwachstelle CVE-2023-42115 in der SMTP-Implementierung. Diese ermöglicht einem entfernten, unauthorisierten, Angreifer gegebenenfalls die Remote-Ausführung von Code mit Rechten des Service Accounts, mit dem Exim betrieben wird.
Der spezifische Fehler besteht laut der Zero Day Initiative (ZDI) innerhalb des smtp-Dienstes, der standardmäßig auf TCP-Port 25 lauscht. Das Problem resultiert aus dem Fehlen einer ordnungsgemäßen Validierung der vom Benutzer bereitgestellten Daten, was dazu führen kann, dass ein Schreibvorgang über das Ende eines Puffers hinausgeht. Ein Angreifer kann diese Schwachstelle ausnutzen, um Code im Kontext des Dienstkontos auszuführen.
Die Schwachstelle wird mit einer CVSS-Bewertung von 9.8 ("kritisch") eingestuft. Über die Remote-Code-Ausführung könnte es Angreifenden unter anderem möglich sein, sensible Daten inkl. transportverschlüsselter E-Mails abfließen zu lassen. Alle Schwachstellen in Exim wurden im Juni 2022 an den Hersteller gemeldet und nach Ablauf des für die Entwicklung von Patches eingeräumten Zeitfensters durch die Zero Day Initiative am 27.9.2023 veröffentlicht.
Patches verfügbar
Zum 29. September 2023 hieß es, dass noch keine Patches zur Verfügung stehen, obwohl der Fehler ein Jahr vorher gemeldet wurde. Zu dieser Zeit der Offenlegung war unbekannt, ob und wie die in Entwicklung befindliche Exim-Version 4.97 die Schwachstellen schließen wird (so steht es auch in der BSI-Warnung). Die einzig sinnvolle Abhilfestrategie bestand laut ZDI darin, die Interaktion mit der Anwendung einzuschränken.
Allerdings handelt es sich bei der ZDI-Meldung um eine koordinierte Veröffentlichung. Die Exim-Entwickler haben auf seclists.org die Meldung Exim4 MTA CVEs assigned from ZDI veröffentlicht und beschweren sich über die Kommunikation mit der ZDI, es gab keine Antworten auf Nachfragen, so dass die Fehler nur schwer identifiziert werden konnten. Inzwischen sind aber die meisten Schwachstellen gefixt:
- CVE-2023-42114 3001 fixed
- CVE-2023-42115 2999 fixed
- CVE-2023-42116 3000 fixed
- CVE-2023-42117
- CVE-2023-42118
- CVE-2023-42119
Zu den noch ungefixten Schwachstellen heißt es, dass man diese zeitnah patchen will, sobald das ZDI Details dazu liefert. Denn trotz der Meldung vom September 2022 fand der nächste Kontakt der Entwickler mit dem ZDI im Mai 2023 statt, in dessen Anschluss ein Bug-Tracker für 3 der 6 Probleme erstellt wurde. Zwei der gravierendsten Schwachstellen (OOB-Zugang) sind behoben, und ein kleinerer Fehler (Informationsleck) wurde ebenfalls behoben, heißt es von den Entwicklern. Die Korrekturen sind in einem geschützten Repository verfügbar und können von den Betreuern der Distribution angewendet werden.
Die verbleibenden drei Probleme seien strittig oder es fehlen Informationen, die die Entwickler zur Behebung der Schwachstelle benötigten, schreiben diese. Scheint eine unschöne Geschichte bezüglich der Kommunikation zu sein. Bleeping Computer und heise haben einige weitere Informationen zum Thema publiziert.
Bedingungen für die Ausnutzung
Ergänzung: Inzwischen hat Heiko Schlittermann in diesem Dokument einige Bedingungen veröffentlicht, unter denen die Schwachstellen relevant werden.
- 3 of them are related to SPA/NTLM, and EXTERNAL auth. If you do not use
SPA/NTLM, or EXTERNAL authentication, you're not affected.
These issues are fixed. - One issue is related to data received from a proxy-protocol proxy. If
you do not use a proxy in front of Exim, you're not affected. If your
proxy is trustworthy, you're not affected. We're working on a fix. - One is related to libspf2. If you do not use the `spf` lookup type
or the `spf` ACL condition, you are not affected. - The last one is related to DNS lookups. If you use a trustworthy
resolver (which does validation of the data it receives), you're
not affected. We're working on a fix.
Die Entwickler stehen in Kontakt mit den Haupt-Distributionen – die Fixes sollten inzwischen dort verfügbar sein.
Interessant wird es für "Appliances" und Software-Pakete, wo Exim eingesetzt wird. In der Sophos-Community gibt es für die XG Firewall diesen Forenthread. Die Sophos UTM und SFOS sind beide von der libspf2-Schwachstelle (CVE-2023-42118) betroffen. Kunden, die Email Security verwenden und das Sender Policy Framework (SPF) aktiviert haben, sind anfällig dafür. Als Workaround wird empfohlen, SPF zu deaktivieren. Weiterhin plant man bis zum 5. Oktober 2023 einen SFOS-Hotfix zu veröffentlichen.
Anzeige
>>> Wer den Exim MTA als Mailserver einsetzt, sollte diesen dringend umgehend patchen.
Das ist gar nicht so einfach, wenn der z.B. in einer Appliance "verbaut" ist – und da sind die Hersteller derzeit wohl kalt erwischt worden!
vielleicht sollte man den Text noch so erweitern, das dieser Expoit nur in ganz bestimmten, weniger üblichen Konfigurationen auf tritt?
So hört das schon sehr nach "wir werden alle störben" an,
Und jede der 3,5 Mio Installationen Zombies sind.
Ich habe gerade bei Günter ein Eindruck daß er nicht auf dieser Welle, wie z.B. Heise, reiten möchte/"muß".
Weshalb es auch weit mehr Spass macht hier zu lesen, als bei Heise immer wieder feststellen zu müssen, das man mit der Überschrift verarscht wurde.
Was genau hilft mir jetzt das Patschen des MTAs wenn die Lücken seit über über einem Jahr bekannt ist und sehr wahrscheinlich schon jahrelang vorher vorhanden gewesen sein muss.Exim gibt's ja schon seit über 20 Jahren.
Es wird ja nicht geschrieben, wann diese Lucken implementiert wurden.
Unwahrscheinlich daß man z.B. 25.6.22 die Exploits gemeldet wurden, weil sie am 24.6.22 eingebaut worden sind.
Man muss natürlich davon ausgehen dass das sein Mailserver gerootet worden ist und muss ihn neu aufsetzen.
Nur den Exim zu patchen und gut ist wäre naiv.
Bei Heise wollte jemand einen anderen MTA durch vorschqlten eines anderen MTAs sichern.
Vermutlich ist er im Hauptberuf Windows Admin.
Es ist zwar kein remote exploit gewesen, aber gerne erinnert man daran, dass der Linux Zufalls zahlen Generator nicht mehr zufällig war.
Ursache war ein einziges Semicolon.
Seltsamerweise konnte man natürlich feststellen wann dieses gesetzt wurde, wer das war jedoch nicht…
Sehr spooky.
Völlig richtige und berechtigte Fragen, wie bei vielen vielen anderen "Lücken" auch.
Antworten wird es keine geben, viele IT Schaffende verstehen diese Fragen nichtmal und verstehen auch nicht, dass sie dann nicht im IT Bereich arbeiten sollten.
Wenn man diese Frage konsequent lösen würde, dann müsste man jedes System an jeden Patchday von 0 neu aufsetzen.
Und auch wenn Software gepatcht wurde, müsste man das Betriebsystem neu aufsetzen, denn die Lücke in der Software könne ja eine Lücke im Betriebssystem aufgemacht haben.
Das ist aber völlig realitätsfremd.
> Das ist aber völlig realitätsfremd.
Ja, in der Realität arbeitet man nicht wirklich an echter Sicherheit sondern hauptsächlich daran, keine Verantwortung übernehmen zu müssen.
Daher bestehen heutzutage ganze Messen wie z.B. die it-sa etwa aus der einen Hälfte Anbietern von Sicherheits Bla Blubb Schlangenöl und aus der anderen Häfte Pentration Testing und Incident Response Dienstleistern.
Solche Dinge werden von Verantwortlichen dort betrachtet und dann später fleissig gekauft und schon ist man selbst aus der fachlichen Verantwortung, der Software Verkäufer oder Dienstleister ist im Zweifel der Buhmann.
Wer Webseiten, Bugtracker und Mailinglisten von exim studiert bekommt den Eindruck, dass das Projekt in den letzten Jahren eingeschlafen ist und kaum Mitwirkende hat.
Wäre es nicht der Standard-MTA in Debian (und das vermutlich auch nur, weil dort seit 10 Jahren keiner mehr darüber nachgedacht hat) wäre das kein Problem – so beißt es all die, die den Standard einsetzen und nicht z.B. Postfix verwenden.
Das, was man bisher zu dem Thema lesen konnte liest sich wie eine Kette von "wayne interessierts?": Das ZDI lässt 10+ Monate für Nachfragen verstreichen. Exim macht nicht mal für jede CVE ein Ticket auf (egal ob berechtigt oder nicht) und fragt nicht mit Nachdruck nach, wo die Probleme liegen. Das ZDI kündigt die Veröffentlichung an. Exim sagt "dann macht doch". Und hinterher stellt man fest, dass eine 6-stellige Zahl an Servern dadurch gekapert werden kann. Alles super.
Obendrein habe ich den Eindruck, dass niemand mehr Mailserver selbst macht sondern nur noch mietet und hofft, dass der Betreiber schon weiß was er tut…
Ob die SOPHOS UTMs wohl noch ein Update bekommen? Die nuten auch den EXIM und für SOPHOS existiert die UTM quasi nicht mehr….
Das letzte Update ist nicht so lange her und die Sophos SG hat EOL am 30.06.2026 – und genau so lange wird es da Updates geben.
Das Sophos von dem Thema kalt erwischt wurde – wie vermutlich auch weitere Hersteller die Exim in ihrem Produkt "eingebaut" haben ist ein anderes Thema. In OpnSense steckt der auch oder?
Die opnsense nutzt als Mail relay Plugin Postfix .wäre mir neu wenn sie exim benutzen.
>>In OpnSense steckt der auch oder?
Nein
Die Diskussion gärt gerade im Sophos-Forum, zumal ja auch die "neueste und schönste" XG-Firewall Exim (nur in einer anderen Version) verwendet.
Wird auf alle Fälle ein Prüfstein, weil ja Sophos groß verkündet hat, die UTM bis Mitte 2026 zu supporten und von denen, die noch nicht gewechselt haben, mehr Geld einstreicht als je zuvor.
Aktueller Stand: "We already reached out internally about this matter, and once we hear back, we'll provide an update."
Das Advisory liegt jetzt vor.
https://community.sophos.com/sophos-xg-firewall/f/german-forum/142276/exim-schwachstelle/530275
Kurzfassung: Es bleibt als einziges die Schwachstelle in der libspf, alle anderen Mechanismen werden nicht verwendet.
Ein Patch wird bis zum 5.10. in Aussicht gestellt, bis dahin sollte man SPF abschalten.
Der 5.10. gilt für die XG, für SG ist kein Datum genannt. Für die SG steht dort:
An UTM MR will be released to patch this vulnerability, date is TBD
Naja, die Aktionäre haben die Sophos UTM nun schon genug kaputt gespart :-) Ein Update zu paketieren, was andere programmieren, werde die Aktionäre ggf noch mal so durchgehen lassen.
Stellungnahme von Sophos liegt nun vor. Anfällig ist die UTM nur für CVE-2023-42118. Patches werden als "TBD" in Aussicht gestellt.
>>> An UTM MR will be released to patch this vulnerability, date is TBD
Workaround ist das Abschalten der SPF Checks. Das alles konnte man sich mit den Infos unter https://lists.exim.org/lurker/message/20231001.165119.aa8c29f9.en.html bereits selbst zusammenreimen und SPF Ausschalten…
https://community.sophos.com/utm-firewall/f/mail-protection-smtp-pop3-antispam-and-antivirus/142286/info-urgent-exim-vulnerability
Hier sind weitere Informationen dazu, unter welchen Bedingungen die Lücken bestehen/bestanden: https://lists.exim.org/lurker/message/20231001.165119.aa8c29f9.en.html
Debian-Packete sollen noch heute kommen: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053310#15
Danke.
das ist ein hilfreiche Information.
alles andere war reisserischer Click bait.
Gerade bedauerlicher bei Heise im voll im Trend.
Security Announces Ubuntu – noch offen, needs triage.
Security Announces Debian – published: Announce hier, wird seit kurzem verteilt zB Bookworm + Bullseye – Fokus auf CVE-2023-42114, -42115 und -42116
Exim: Tracking Ubuntu – in progress
Exim: Tracking Debian – in progress, vulnerable (no DSA), WWW nicht ganz up2date
Sophos UTM und XG News
https://community.sophos.com/sophos-xg-firewall/f/german-forum/142276/exim-schwachstelle
XG Pacthes für Sophos sind draussen, SG Patches sind anvisiert für den 17. Oktober:
"Sophos UTM version 9.717 will be available to update to on 17 October 2023"
Für SG gilt bis dahin SPF abschalten.