News Fix steht bereit: Schwachstelle in Exim gefährdet Mailserver weltweit

[Cool Master]

Dovecot+Postfix und man hat die perfekte Kombi. Exim war schon immer so ein Problemkind.

 

[Bigfoot29]

Hier fände man den aktuellen Stand des Exim-Paketes bei Debian: https://security-tracker.debian.org/tracker/source-package/exim4

Ich gehe davon aus, dass wir da zeitnah einen Fix sehen. Zumindest, solange da nicht massiv Featuritis während des Bugfixings betrieben wurde. (Darauf reagiert Debian ja - zu Recht - etwas empfindlich. )

Regards, Bigfoot29

 

[coffee4free]

Artikel-Update: Ein deutscher Exim-Entwickler namens Heiko Schlittermann hat sich inzwischen zu den Ausführungen der ZDI geäußert. Demnach gebe es für drei von insgesamt sechs von der ZDI gemeldeten Problemen inzwischen einen Fix, der Betreuern der jeweiligen Distributionen in einem geschützten Repository zur Verfügung stehe. Dazu zähle auch jener für CVE-2023-42115. Die verbleibenden drei Schwachstellen seien strittig oder es mangle noch an für eine Behebung erforderlichen Informationen.

Grund für die Verzögerungen waren offenkundig Kommunikationsprobleme. So behauptet Schlittermann, das Entwicklerteam von Exim habe gleich nach der ersten Kontaktaufnahme der ZDI im Juni 2022 weitere Details angefordert, jedoch keine Antwort erhalten, mit denen das Team hätte arbeiten können.

Warum angesichts der Tragweite des Problems keine der involvierten Parteien an der Sache dran geblieben ist, bleibt damit jedoch fraglich. Aktuell erwecken die Darlegungen den Anschein, als sei einer effektiven Problembeseitigung beiderseits nur wenig Aufmerksamkeit geschenkt worden.

Die Redaktion dankt Community-Mitglied 0x8100 für den Hinweis zu diesem Update.

 

[mae]

Was soll das denn heißen? Du kannst hergehen und die Lücke sogar selbst schließen - Code ist ja öffentlich.

Ja, allerdings muesste man dazu die Luecken wohl zuerst finden. In den CVEs, in denen ich nachgeschaut habe, habe ich dazu nichts gefunden. Diejenigen, die die Luecken gemeldet haben, haben die Luecken nur recht allgemein beschrieben. Ob sie mehr an die Exim-Entwickler gemeldet haben, weiss ich nicht. Wenn nicht, wundert mich nicht, dass die nichts gemacht haben.

Also ja, jeder kann Bugs fixen. Dazu muss er aber erst von ihnen wissen.

 

[xexex]

Wer kennt sie nicht? Diese Opensource Bastelbuden wo Bärtige Entwickler die 3 Wochen nicht geduscht haben in einer Garage hocken und frei von irgendwelchen finanziellen Ziele für die Verbesserung der Welt ihre Zeit aufwenden.

Du solltest hier mal klar zwischen Projekten unterscheiden, die aktiv von großen Firmen gewartet und entwickelt werden und zwischen unzähligen Projekten die längst aufgegeben wurden oder aus welchen Gründen auch immer nicht mehr weiter gepflegt werden.

91 Prozent der kommerziellen Code-Basen enthalten Open-Source-Komponenten, die seit gut zwei Jahren nicht gepflegt wurden, auch Schwachstellen sind weit verbreitet. Dieses Bild zeichnen 1.500 Audits, die in den „Open Source Security and Risk Analysis“- oder kurz OSSRA-Report von Synopsys eingeflossen sind.
https://www.dev-insider.de/verwaister-open-source-code-in-neun-von-zehn-projekten-a-1014918/

Ein schönes Bildchen dazu gefällig?

https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2023.pdf

 

[Snowi]

Stimmt nicht, Emails werden zwischen Servern in der Praxis ausschließlich an Port 25 gesendet.

Wenn der offen ist, ja. Ansonsten probieren die gängigen Softwarelösungen aber scheinbar auch die anderen Ports. Woher ich das weiß? Habe es aus Interesse mal getestet, als ich damals ein Testsystem aufgesetzt habe. Wirklich Probleme mit einem Mailserver, der nur via Port 465/587 annimmt, hatte ich nicht. Zumindest mein eigener Server mit Postfix hat das problemlos gemacht, und auch Gmail und iCloud Mails gingen problemlos.

Und hast Du irgendeine Statistik, die deine zweite Behauptung untermauern würde? Die meisten Server dürften wohl STARTTLS versuchen, die Email aber auch unverschlüsselt annehmen, solange keine Policy dagegen spricht.

Nein, Statistiken nicht. Kann natürlich sein, dass die meisten noch SMTP annehmen würden. Fände ich aufgrund von SSL Interception / MitM aber schwierig, z.B. in öffentlichen WLANs. Da kannst du ja einfach den Handshake unterbrechen, und der Fallback wäre dann automatisch SMTP? Kann ich mir kaum vorstellen.
Scheinst aber nicht unrecht zu haben, zumindest zu Google kann ich mich via telnet auf Port 25 verbinden und auch arbeiten...
Gut, hab ich mich wohl geirrt

 

[Bob.Dig]

Fände ich aufgrund von SSL Interception / MitM aber schwierig, z.B. in öffentlichen WLANs. Da kannst du ja einfach den Handshake unterbrechen,

Hier geht es aber um Server2Server und jene stehen für gewöhnlich nicht in einem WLAN.

 

[Bigfoot29]

@xexex: Wobei hier vieles Compliance-BS der Firmen ist. Nur, weil Code "veraltet" oder "nicht aktualisiert" ist, heißt das nicht, dass er unsicher ist. Für Firmen ist die Lizensierung von Code tatsächlich ein Problem. Aber selbst unlizensierter Code ist ja kein "kaputter" Code. Es ist halt nur welcher, der nicht einfach so verwendet werden darf.

Übrigens: Nur bei Open Source kann man überhaupt derartige Scans machen.

Regards, Bigfoot29

Nachtrag:
@Bob.Dig : Falls Du BGP kennst - das ist, vereinfacht gesagt, das Protokoll zwischen den großen Routern der Netz- und RZ-Betreiber - dann ist "unverschlüsseltes WLAN" nicht weit weg. Eine Transportverschlüsselung sollten heutzutage alle Protokolle haben. Wegschnüffeln geht ansonsten leider immer(noch viel zu einfach).

 

[Snowi]

Hier geht es aber um Server2Server und jene stehen für gewöhnlich nicht in einem WLAN.

Gut, ist ein Argument Aber theoretisch könnten auch alte Clients so Mails verschicken.
Müsste mal Thunderbird probieren, ob der bei unterbrochenem Handshake via SMTP sendet, wenn im Profil TLS eingestellt ist.

 

[Bob.Dig]

wenn im Profil TLS eingestellt ist.

Natürlich nicht, aber darum geht es ja hier überhaupt nicht.

 

[Rickmer]

Eine Transportverschlüsselung sollten heutzutage alle Protokolle haben.

Das letzte mal, dass ich eine SMTP-Mailübertragung durchs Internet ohne TLS gesehen habe war 2018, als die Firmen panisch festgestellt haben, dass DSGVO vor der Tür steht.

Jeder Mail-Header, den ich mir die letzten 4 Jahre oder so angeschaut habe, hatte Transportverschlüsselung dokumentiert.

Gut, ist ein Argument Aber theoretisch könnten auch alte Clients so Mails verschicken.

Wenn ein Client versucht, ohne Auth aus irgendeinem freien wlan eine Mail abzusetzen, sollte der Server die abweisen...
Nicht wegen SMTP oder so, sondern weil die dann wie ein anonym submit aussieht und prompt bei SPF/DKIM/DMARC durchfällt.

 

[DFFVB]

Verständlich - da deine Beispiele nicht im Geringsten zu deiner Behauptung passen und eher meiner Beschreibung entsprechen

Übertreib mal nicht, Du weißt genau was gemeint ist, und dass es korrekt ist. Und natürlich passt es dazu, und ich könnte mich jetzt hinsetzen und weitere Beispiele finden. Wie ich gesagt habe, Aussagen "wie" - du machst daraus "genau". D.h. Du verschiebst zuerst meine Aussage, um Dich dann darauf aufzuhängen und zu sagen "stimmt ja nicht". Das ist kindisch und ein Strohman. Die Tendenz ist Dir doch klar, auch wenn es Dir nicht schmeckt...

 

[Dragon0001]

Wenn der offen ist, ja. Ansonsten probieren die gängigen Softwarelösungen aber scheinbar auch die anderen Ports. Woher ich das weiß? Habe es aus Interesse mal getestet, als ich damals ein Testsystem aufgesetzt habe. Wirklich Probleme mit einem Mailserver, der nur via Port 465/587 annimmt, hatte ich nicht. Zumindest mein eigener Server mit Postfix hat das problemlos gemacht, und auch Gmail und iCloud Mails gingen problemlos.

Das kann ich mir nicht vorstellen, da dies nicht der Spezifikation entspricht. Zudem ist bei Port 465 und 587 normalerweise eine Authentifizierung zwingend notwendig, sodass andere Mail-Server gar keine Mails einliefern können.
Auf meinem Postfix habe ich so etwas weder eingehend noch ausgehend beobachtet.

 

[=dantE=]

Wenn Du keine Ahnung hast, einfach mal die Finger still halten.

Danke für die subtile Erläuterung.
Als Frage ausgelegt, könnte man mich auch einfach informieren.
Haste verpasst … ebenso meine Wertschätzung.

Ergänzung (30. September 2023)

Aber der Port ist und bleibt bei den meisten Servern geöffnet, nur eben beschränkt auf TLS/STARTTLS Verbindungen

Danke für die Erleuchtung! Ist ernst gemeint!

 

[Termy]

Die Tendenz ist Dir doch klar, auch wenn es Dir nicht schmeckt...

In der Tendenz stimmt aber eben auch die Aussage, dass Open Source für bessere/sicherere Software sorgt, auch wenn es Dir nicht schmeckt

 

[Piktogramm]

Du solltest hier mal klar zwischen Projekten unterscheiden, die aktiv von großen Firmen gewartet und entwickelt werden und zwischen unzähligen Projekten die längst aufgegeben wurden oder aus welchen Gründen auch immer nicht mehr weiter gepflegt werden.

Da verhaust du aber Dinge..
Ob statisch gelinkte Bibliotheken veralten hat nichts mit OpenSource oder propritärer Software zu tun. Das Problem ist das selbe, die statisch gelinkten Bestandteile veraltet, wenn der Anbieter den keinen Aufwand in "Dependency management" steckt. Das bekommen kleine Hobbyentwickler genauso gut/schlecht hin wie die großen, bekannten Namen. Genauso wie es egal ist, ob es da um direkt laufende Programme oder Container geht. Zeug um das sich nicht gekümmert wird vergammelt.

Naja und die andere Seite ist die "Dependency Hell"

 

[GTrash81]

Wenn der offen ist, ja. Ansonsten probieren die gängigen Softwarelösungen aber scheinbar auch die anderen Ports. Woher ich das weiß? Habe es aus Interesse mal getestet, als ich damals ein Testsystem aufgesetzt habe. Wirklich Probleme mit einem Mailserver, der nur via Port 465/587 annimmt, hatte ich nicht. Zumindest mein eigener Server mit Postfix hat das problemlos gemacht, und auch Gmail und iCloud Mails gingen problemlos.


Nein, Statistiken nicht. Kann natürlich sein, dass die meisten noch SMTP annehmen würden. Fände ich aufgrund von SSL Interception / MitM aber schwierig, z.B. in öffentlichen WLANs. Da kannst du ja einfach den Handshake unterbrechen, und der Fallback wäre dann automatisch SMTP? Kann ich mir kaum vorstellen.
Scheinst aber nicht unrecht zu haben, zumindest zu Google kann ich mich via telnet auf Port 25 verbinden und auch arbeiten...
Gut, hab ich mich wohl geirrt

Wenn es so einfach wäre.
Es gibt tatsächlich Server in der freien Wildbahn, die kein TLS können.
Oder aber der Server ist irgendwas halbgares, was bei den TLS-Parametern Schluckauf bekommt.
Zum anderen ist Port 25 defacto SMTP und da gibt es viel weniger Probleme bei Anträgen für die
Portfreischaltung bzw. Kommunikationsgenehmigung zwischen verschiedenen Institutionen.

Am einfachsten ist es zwischen Servern Port 25 freizuschalten und die Möglichkeit für TLS anzubieten.
Wer TLS dann nicht (richtig) beherrscht kann immer noch unverschlüsselt kommunizieren.

Ist die Vorgehensweise richtig? Vielleicht nicht, aber wenn du von 30 Personen angeschrien wirst,
dass die Mail nicht ankommt, dann geht man diesen Weg.

 

[DFFVB]

In der Tendenz stimmt aber eben auch die Aussage, dass Open Source für bessere/sicherere Software sorgt

Falsch - aber alleine die Tatsache, dass Du "besser" ins Spiel bringt, zeigt wie verbohrt Du hier bist. Von besser hat keiner gesprochen, steht auch auf einem ganz anderen Blatt.... Aber wenn Du es mach fachlich wissen willst:

https://madaidans-insecurities.github.io/linux.html

(als Beispiel)

 

[Snowi]

Das kann ich mir nicht vorstellen, da dies nicht der Spezifikation entspricht. Zudem ist bei Port 465 und 587 normalerweise eine Authentifizierung zwingend notwendig, sodass andere Mail-Server gar keine Mails einliefern können.
Auf meinem Postfix habe ich so etwas weder eingehend noch ausgehend beobachtet.

In freier Wildbahn nicht, ich hab auch damals nicht in die Logs geschaut. Aber wie gesagt - mit geschlossenem Port 25 ging es trotzdem. Werde ich bei Gelegenheit nochmal testen.

Es gibt tatsächlich Server in der freien Wildbahn, die kein TLS können.

Die Mails kommen dann bei meinem Server einfach nicht an...

Zum anderen ist Port 25 defacto SMTP und da gibt es viel weniger Probleme bei Anträgen für die
Portfreischaltung bzw. Kommunikationsgenehmigung zwischen verschiedenen Institutionen.

Es macht auch auf jeden Fall Sinn, Port 25 zu nutzen. Wollte nur schreiben, dass es scheinbar irgendwie auch ohne Port 25 geht, zumindest je nach Konfiguration. Empfehlen würde ich es aber nicht, weil es dennoch genug Software geben wird, die damit nicht klar kommt, und man sich damit nur Probleme einfängt. Nicht alles, was technisch funktioniert, sollte auch so gemacht werden

Ist die Vorgehensweise richtig? Vielleicht nicht, aber wenn du von 30 Personen angeschrien wirst,
dass die Mail nicht ankommt, dann geht man diesen Weg.

Ja, das ist leider das Problem, wenn man einen Mailserver betreut. Kenne ich zu gut. Wollte gerade ein paar Geschichten schrieben, aber geht dann doch etwas weit am Thema vorbei hier

 

[andr_gin]

1.) Ich wüsste nicht was gegen die Verwendung von Port 25 spricht. Das bedeutet ja nicht, dass die Kommunikation unverschlüsselt erfolgt. Der Großteil der Mails kommt TLS verschlüsselt über Port 25. Es wäre mir auch neu, dass den irgendjemand für die Server zu Server Kommunikation sperrt.

2.) Den Empfang bzw. das Versenden nicht TLS verschlüsselter Mails zu sperren kann schnell nach hinten los gehen. Es gibt leider immer einige Mailserver, die mit aktuellen Verschlüsselungsstandards ein Problem haben und hier ist der unverschlüsselte Versand ein guter Fallback.
Man kann es mit dem Datenschutz auch etwas übertreiben. Wer seinen Mailserver in einem öffentlichen WLAN betreibt, der hat denke ich andere Probleme.