Exim: neue mögliche RCE Schwachstelle gefunden

Toller Sonntag. Überall Regen und dann weckt mich noch die Meldung, das im Exim eine neue, nicht abwehrbare Schwachstelle gefunden wurde 🙁 ( wichtiges 13 Uhr Update unten )

Elysium ist gefallen

Es gibt einen neuen Bug, der auch bereits gefixt wurde, aber leider nicht mit einem Workaround abzuwehren geht. Das bedeutet für Euch, daß Ihr Updaten müßt.

Der Fehler liegt in einem Programmierfehler der Stringverarbeitung, die dummerweise bereits beim HELO/EHLO greift. Ein Angreifer kann einen Heap-overflow auslösen, in dem er einen überlangen ELHO String sendet.

An der Stelle des Codes wurden die Rootrechte zwar schon gedroppt, aber das hilft nur wenig, falls der Angreifer tatsächlich einen RCE hinbekommt, was nicht ausdrücklich ausgeschlossen ist, aber auch nicht 100% bestätigt wurde. Daher muß man davon ausgehen, daß es jemand früher oder später schafft: Worst-Case halt.

Betroffen sind alle Versionen < 4.92.3.

Also entweder Ihr patchted Euren alten Exim selbst, oder Ihr updated auf die neue Version. Eure Entscheidung.

Aktuelle CVE Nummer zu dem Exim RCE : CVE-2019-16928 .
(Passage geändert, vorher keine bekannt gewesen.)

13 Uhr Update

Fedora kompilierte Versionen sind nicht angreifbar. Der Exploit funktioniert einfach nicht.

Getestet auf: Fedora 29 64Bit gegen 4.92.2

Andere Distros könnten angreifbar sein. Es hängt auch ein bisschen damit zusammen, wie das angegriffene System konfiguriert ist. „Eylsium ist gefallen“ ziehe ich damit teilweise zurück .. das Fedosium steht noch :DDD

Der Exploitstring ist übrigens 11k lang, nur falls Ihr das bei euch mal selbst ausprobieren wollt, nehmt gleich 12k.

Außerdem wurde mitgeteilt, daß es im Rahmen der 4.92.x eingeführt wurde und mit 4.93 auch schon wieder draußen war. Die Exploitmeldung war leider etwas hastig formuliert worden. Allerdings sehe ich da keinen Schaden drin, weil „besser safe than sorry“ wie der Denglischer sagt 😉

 

OMG des Tages: Fulldisclosure ML bietet kein TLS an

Nicht das man es brauchen würde, aber in 2019 darf man doch von einer Securityliste erwarten, daß deren Mailserver TLS kann, oder? Nicht so bei NMAP.

seclists.org Mailserver bietet kein TLS an

Gerade wollte ich das Duplicator Pro Advisory an die  FullDisclosure Mailingliste schicken, da mault doch glatt mein Mailserver, daß er die Mail nicht schicken könnte, weil der Empfänger TLS verweigert. Ein OMG war die Folge:

CheckTLS Confidence Factor for „fulldisclosure@seclists.org“: 0

MX ServerPrefAnswerConnectHELOTLSCertSecureFrom
ack.nmap.org
[45.33.49.119:25]
0OK
(69ms)
OK
(151ms)
OK
(68ms)
FAILFAILFAILOK
(357ms)

2019-09-27 21:23:52 1iDvqI-0005NU-Mw == fulldisclosure@seclists.org R=dnslookup T=remote_smtp defer (-38) H=ack.nmap.org [45.33.49.119]: a TLS session is required, but the server did not offer TLS support

Jetzt braucht man natürlich keine Verschlüsslung, wenn eh an eine öffentliche Mailingliste Veröffentlichungen schickt, aber da laufen auch private Mailinglisten drüber z.b. über Bugs in NMAP und die sollten ja wohl verschlüsselt ankommen, oder?

Es kommt mir so bekannt vor…

Besonders prekär für die Admins des NMAP Mailservers ist der Umstand, daß deren Mailserver sehr wohl TLS beim Senden von Emails kann, sonst kämen die Emails nicht bei uns an:

2019-09-26 08:54:08 1iDNfD-00060F-Mj <= fulldisclosure-bounces@seclists.org H=ack.nmap.org [45.33.49.119] P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no S=21878 id=6e00195f-664f-1d1c-0fb6-1333992ad574@sec-consult.com

Die große Ähnlichkeit zum BSI CERT-Bund Mailserver macht es natürlich nicht besser: BSI aktualisiert Mailserver auf TLS 1.2.. ABER .

Ich seh schon, mit dem TLS Gate habe ich noch auf Jahre jede Menge Spaß fürs Blog 😀

Hinweis: Duplicator Pro <= 1.3.14 hat eine fiese IFDC Schwachstelle. Bitte updaten!

Wieso DoH nicht gut für die Privatsphäre des User ist.

Mozilla will ja ab sofort in den USA DoH als Testballon starten. Der Rest der Welt soll später folgen. Ziel der Aktion ist es, daß DNS Anfragen nicht mehr von DNS-Servern wie Bind beantwortet werden, sondern, daß Webserver die DNS Informationen für den anfragenden Clienten per HTTPS beantworten. Bleibt die Frage, was und woher tunnelt er die Daten?

„Wäre es nicht die Wirklichkeit, es wäre ein Bestseller“

Ganz kurz umrissen, wird Firefox per HTTPS  die Cloudflare DoH-Webserver fragen, die holen sich DNS Antworten dann vom Cloudflare DNS-Servern und der von den korrekten  DNS-Servern. In der Endstufe war geplant, daß die besuchten Webserver die DNS Anfragen selbst beantworten, so daß wieder eine dezentrale Struktur entsteht.

Mozilla möchte damit erreichen, daß DNS Anfragen nicht mehr im Klartext durchs Netz gehen, weil ein Angreifer die bisherige DNS Information mit einer MITM-Attacke angreifen kann ( Man-in-the-Middle ). Nobel, aber sollte DNSSEC nicht genau das Problem lösen?

Und wer sagt uns, daß Cloudflare die Daten nicht manipuliert? Millionen von DNS-Webanfragen  würden bei Cloudflare durchgehen und wären so leichteste Beute für einen, der nicht will, daß Domain X erreichbar ist, oder Inhalt Y hat.

Wer schützt uns vor Zensur?

Das DNS System, denn es gibt Millionen DNS Server und Caches aus denen ich mir die Informationen zu einer Domain ziehen kann, inklusive der Autoritären-DNS des Domaininhabers.

Wie jetzt, Eurer Provider blockt externe DNS und erlaubt Euch nur seine eigenen DNS-Caches zu benutzen?

Lest das hier: UDP Traffic per SSH tunneln

Und wie sieht es mit dem Datenschutz aus?

Firefox sendet jetzt private Informationen in einem Ausmaß an ein amerikanisches Unternehmen, daß daraus leicht Profile bilden kann, und der Datenschutz sieht zu? Glaube ich kaum.

Was wollte Mozilla doch gleich mit DoH schützen?

Die Privatsphäre, ach ja, kommen wir mal dazu. Korrekt ist, daß ein DNS Betreiber in den Logfiles, so er denn welche erstellt, nachsehen kann, welche IP welche Domain hat auflösen wollen. Cloudflare kann das auch, niemand hindert sie daran. D.b. für die Privatsphäre ist es mit Cloudflare als derzeit einzigem DoH Betreiber, noch schlechter bestellt, als jetzt.

Derzeit kann ich mir aussuchen, welchen der vielen DNS Server ich frage, oder ob ich mir vielleicht gleich selbst einen eigenen DNS Cache hinstelle, der nur für mich arbeitet. Mit DoH geht das nicht mehr, außer ich betreibe einen DoH Server. Mangels Masse, eher unrealistisch derzeit.

Wie man seine eigenen DNS Anfragen auf möglichst viele DNS Server verteilt um bei keinem der DNS Betreiber ein sinnvolles Profil zu hinterlassen, findet Ihr in diesem früheren Beitrag von mir : Linux – DNS-DeTracking mit nscd

Fazit

DoH ist derzeit die leibhaftige Vision einen dystopische Zukunft, in der alle User bei einem einzigen Anbieter sind, so wie in den Terranauten, alle beim Energiekonzern Energie beziehen, vom Lebensmittelkonzern ernährt werden und auch ansonsten von Monopolen beherrscht werden. DoH ist im jetzigen Zustand nur eins: nicht akzeptabel.

Eine (von vielen) Alternative

DNS-Anfragen per TLS manipulationssicher zu machen, ist ok. Aber, wozu eigentlich der HTTP Overhead? Reicht es nicht, wenn Bind einen TLS Port bereitstellen würde und der zuerst gefragt wird? Das hätte zur Folge, daß der Server durch den SNI im TLS auch domainbasierte Zertifikate benutzen kann, also auch beweisen könnte, daß er er ist und nicht ein MITM-Angreifer.

Zugegeben, der Overhead dabei wäre aufgrund der möglichen Schlüssellängen ziemlich heftig, aber dafür könnte man z.b. kleinere, mit dem Zertifikat des Domaininhabers signierte, DNS Zertifikate einsetzen. Lets Encrypt könnte das z.B. gleich mit erzeugen und ausliefern, wenn das Hauptzertifikat erzeugt wird.

DNS-Caches könnte man dann gleich daran erkennen, daß sie ein Zert anbieten, daß nicht zum Domainnamen paßt. Anhand der bekannten Root–Zertifikate könnte man auch gleich die Ketten verifizieren. Es ist etablierte Technik, es gibt etablierte Bibliotheken, systemische Schwachstellen sind bekannt, und durch die kürzeren Zerts wäre der Performanceeinbruch nicht so stark. Würde man zudem mehrere DNS Anfragen in einer TCP Sesssion durchführen, so denn sinnvoll möglich, würde der Overhead weiter sinken.

Es gibt also Methoden, die eine derzeit zentrale Instanz wie Cloudflare nicht benötigen, warum also  dann DoH durchziehen?  In einer dystopischen Zukunft wären die Gründe wie immer: Machtgeilheit, Geldgier und, daß eine Gruppe von wackeren Helden den Schurken in einem effektvollen Kampf schlagen kann.

In dem Sinn: „Avengers, Assemble!“