fedora Archive - Seite 44 von 77

Guten Nachrichten von Fedora. Wie wir so eben einer relevanten Fedora Mailingliste entnehmen konnten, planen die Fedora Entwickler das DoH in Firefox nicht zu aktivieren, wenn es kommt.

DNS over HTTPS in Firefox

Das Thema hat ganz schön für Wellen gesorgt. Ohne mich zu wiederholen, ist die Essenz über DoH, daß es vom Prinzip her ok ist, aber eben durch die Zentralisierung im Firefox auf Cloudflare so nicht akzeptabel ist. Da der Bundesdatenschutz ähnliche Bedenken gezeigt hat, wie sie auch mir und Anderen gekommen sind, würde das in Europa für Mozilla vermutlich nicht besonders gut ausgehen, um nicht zu sagen, daß es ein sehr teures Experiment würde.

Ein Fedora Entwickler bekundete in der ML dann auch, daß es in der Form nicht defaultmäßig aktiviert sein wird. Zieht man sich aber Firefox von der Mozillaseite direkt, z.b. wegen einer ESR Version, wäre das natürlich anders.

Ich für meinen Teil sage, daß jemand, der am DNS rumspielt, extrem viel Ahnung davon haben sollte, was DNS für alle bedeutet, um sinnvolle Entscheidungen zu treffen. Mozilla und Cloudflare zähle ich jetzt nicht zu dem Kreis, sonst wäre diese Entscheidung so nicht gefallen. Da ich das Thema erst heute in einem 90 Minütigen Vortrag mal von mehreren Seiten beleuchtet habe, kann ich sagen, daß so „simple“ der Dienst auch erscheinen mag, alle nachträglichen Security Erweiterungen sind daran gescheitert. DNS SEC z.b. hat zwar für Vertrauen in das Ergebnis gesorgt, ist aber auch nicht in allen Ecken und Enden der Server und Desktopanwendungen angekommen. Man mag es nicht glauben, aber das Fedora Repo kennt gerade mal eine Handvoll Pakete und die meisten davon sehen aus, als wenn es nur Teile ein und desselben Programms sind.

DNS-over-TLS, was technisch DNS-over-HTTPS sehr nahe kommen wird, ist auch so ein Krisenfall. Die Ursache dafür liegt darin, daß gute Krypto immer bedeutet, daß mehr in Aufwand, Rechenleistung,Zeit und Datengröße investiert werden muß, was es insgesamt teuer und langsam macht. Das wollte Mozilla mit dem Alleingang vermutlich vermeiden, aber dafür die Privatsphäre opfern geht ja mal gar nicht. Aber vielleicht meinten sie das ja auch ironisch, weil die Verschlüsselung sollte ja genau das verbessern, was es faktisch natürlich nicht tut 🙂

Gegen die Idee, daß auch der Inhalt von DNS gegen abhören gesichert ist, spricht außer der Rechenleistung, dem Keymanagement, der Datenblockgröße eigentlich nichts. Allerdings habe ich so meine Zweifel, ob das in den 1 $US IoT Chips jemals sauber implementiert sein wird.

Bleibt nur zu hoffen, daß das Ziel Encrypted DNS irgendwann mal funktioniert.

OOB Sicherheitslücke in Dovecot < 2.3.7.2 und < 2.2.36.4 führt schlimmstenfalls zu Remote-Code-Execution. Die Meldung vom Dovecotteam enthält einige Ungereimtheiten, die man mal aussprechen müßte.

UPDATE: 11:56 Uhr : Updates fertig ( Anweisung siehe unten )

Mögliche Remote-Code-Execution in Dovecot

Erstmal schauen wir uns an(siehe Advisory unten), was es für eine Schwachstelle ist: „OOB Write im Pre-AUTH „. Das meint, daß ein Angreifer ohne sich authentifizieren zu müssen, einen „Exploit-String“ an den Service schicken kann, der etwas überschreibt. Genauer betrachtet handelt es sich um einen HEAP Overwrite, d.b. ein Teil des internen Speichers des Prozesses kann durch den Angreifer manipuliert/überschrieben werden.

Das ist insofern kritisch, als daß im HEAP Speicher auch Programmteile und Rücksprungadressen liegen können. Gelingt es dem Angreifer die richtige Speicherstelle mit seinem Code zu überschreiben, führt der Prozess ggf. seinen Code aus, statt dem legitimen Programmcode von Dovecot.

Gelingt dies, hat der Angreifer einen privilegierten Prozess in seiner Gewalt und kann sich von dort weiter nach oben exploiten, weil er einen Fuß in der Tür hat. Da Dovecot in Teilen mit Rootrechten läuft, ist ggf. nicht mehr viel nötig um einen Server zu übernehmen:

root 18590 0.0 0.0 3688 2276 ? Ss 03:06 0:00 /usr/sbin/dovecot
root 18595 0.0 0.0 3640 2196 ? S 03:06 0:00 \_ dovecot/log
root 18617 0.0 0.1 5544 4172 ? S 03:06 0:00 \_ dovecot/config
root 18659 0.0 0.1 16552 8208 ? S 03:06 0:00 \_ dovecot/auth

Gegenmaßnahmen

Es gibt nur die Möglichkeit Dovecot auf die neueste Version zu hieven und da beginnt das Problem für viele Linuxuser, denn z.b. Fedora hat heute erst begonnen neue Versionen zu bauen, obwohl Redhat und das Fedora Team seitdem 14.8. Bescheid wissen.

Wieso das erst heute gemacht wird, liegt in der Einschätzung des Security Teams. Das kam zu der fatalen Fehleinschätzung, daß der OOB auf den Heap ja „extrem schwierig“ wäre, weil der Speicherbereich der überschrieben werden kann, zufällig wäre. Das ein Angreifer dann einfach so lange Exploitversuche wiederholt, bis es zufällig klappt, war dem Security Team offensichtlich nicht ganz klar. In Zeiten von riesigen BOT-Netzen, muß man diese Sicht der Dinge als ziemlich naiv bezeichnen, leider.

Zum Glück gibt es ja findige Blogger, die dem Team klar gemacht haben, wo bei der Einschätzung der Fehler liegt und siehe da …

Package Name dovecot
Version 2.3.7.2
Release 1.fc32
State building
Started Thu, 29 Aug 2019 07:47:34 UTC
Est. Completion Thu, 29 Aug 2019 08:10:40 UTC
Changelog * Thu Aug 29 2019 Michal Hlavinka <mhlavink@redhat.com> – 1:2.3.7.2-1
– dovecot updated to 2.3.7.2, pigeonhole 0.5.7.2
– fixes CVE-2019-11500: IMAP protocol parser does not properly handle NUL byte
when scanning data in quoted strings, leading to out of bounds heap
memory writes

es tut sich was bei Fedora.

Fazit: Manchmal braucht es nur einen, der den Arschtritt vornimmt 😉

Wie gefährlich ist die Lücke wirklich?

Das Problem liegt im Detail. Natürlich gibt es die Speicherverwürfelung von Linux als Schutzmaßnahme, aber das macht es einfach nur schwieriger, nicht unmöglich einen Exploit zu schreiben und auszunutzen. Der Knackpunkt ist genau, daß es nicht unmöglich ist, also muß man es zeitnah beheben. Der Angreifer hat im Worst-Case-Fall unendlich viel Zeit und unbegrenzt Ressourcen zur Verfügung ( eine Beschreibung eines Botnetzes 😉 ) und setz diese auch ein. Er kommt also irgendwann per Zufall durch.

Workround nicht vorhanden

Verschärfend kommt hinzu, daß es keinen Workaround gibt und keine Methode den Angriff verlässlich zu bemerken. Die Logfiles schweigen sich quasi aus:

Aug 29 09:33:26 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:16 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:17 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:18 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:19 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:19 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured

Was Ihr oben seht, ist mein Versuch mit einem Beispielcode aus dem Advisory eine Logmeldung zu produzieren. Die Meldung kommt aber am Tag auf größeren System so 100-1000 mal vor, weil natürlich andere Angreifer und falsch konfigurierte Mailprogramme unsinnige Verbindungen zum Server aufmachen, ohne sich zu authentifizieren. Nichts, was ein übermäßiges Security Problem darstellt. Dies muß so ein Server einfach aushalten. Von den jetzt anstehenden Versuchen, die verwundbaren Dovecotserver zu exploiten, kann man das bisherige Rauschen aber nicht unterscheiden und das macht einen effektiven Schutz bis zum Update durch Fedora so problematisch.

Ich seh da nur : Port firewallen und per SSH durchtunneln, oder Firwalllücken für Ips aufgrund einer Auth an einem anderen Service, aber macht das mal mit tausenden von Kunden… also eher keine Lösung.

Das Advisory von Dovecot

Kommen wir zu dem Teil, bei dem ich mich fragte, wieso wir überhaupt ein Problem haben. Das Advisory gibt folgende Daten preis:

Date: Wed, 28 Aug 2019 15:06:23 +0300
Open-Xchange Security Advisory 2019-08-14
Vulnerable version: All versions prior to 2.3.7.2 and 2.2.36.4
Vulnerable component: IMAP and ManageSieve protocol parsers (before and
after login)
Solution status: Fixed by Vendor
Fixed version: 2.3.7.2, 2.2.36.4
Vendor notification: 2019-04-13
Solution date: 2019-06-05
Public disclosure: 2019-08-28
CVE reference: CVE-2019-11500

Gefunden wurde das also im April, im Juni behoben und gestern Abend wurde es öffentlich gemacht. Der 14.8. ist der Tag, an dem Redhat/Fedora davon über die distributionsübergreifende Mailingliste erfahren hat. Soweit so gut.

Wenn man sich jetzt aber die „Fixed Version“ und die Buildhistory von Fedora ansieht:

 NVR                   Built by Finished            State
dovecot-2.3.7.2-1.fc32 mhlavink 2019-08-29 08:36:07 complete
dovecot-2.3.7.1-1.fc30 mhlavink 2019-08-19 20:30:43 complete
dovecot-2.3.7.1-1.fc29 mhlavink 2019-08-19 16:12:18 complete
dovecot-2.3.7.1-1.fc32 mhlavink 2019-08-19 13:52:26 complete

Demnach wurde also am 19.8, 4 Tage nach dem internen Advisory, eine verwundbare Version für Fedora gebaut. Da fragt man sich doch „Wieso“, oder nicht?

Was mich jetzt aber wirklich umtreibt ist, daß es ja schon am 5.6. den Fix gab, der vermutlich intern auch schon eingecheckt war in die Sourcecodes und folglich in dem Build 2.3.7.1 hätte vorhanden sein müssen. Laut Github ist die 2.3.7.1. vom 23. Juli, also 1 Monat nach dem Fix: „ Jul 23, 2019 2.3.7.1 “ .

Ich werde das leider nicht auflösen können, aber falls jemand anderes da mal Licht auf die Commithistorie werfen möchte, fühlt Euch eingeladen. Persönlich kann ich mir gut vorstellen, daß der Fix nicht ganz so foxy war, wie sich der Hersteller das gewünscht hat und er deswegen nicht gleich in den Code kam. Irgendeine andere Begründung, wäre vermutlich nicht so sexy für die Entwickler 😉

Dovecot Advisory in Natura: https://www.openwall.com/lists/oss-security/2019/08/28/3

PS: der FC32 Build ist durch, ich hoffe die anderen kommen auch gleich noch dran.

UPDATE: 11:56 Uhr

Die gefixte Version ist jetzt verfügbar und funktioniert auch ( für x86_64 ) . Ihr könnt direkt als Root Eure Pakete aktualisieren:

Fedora 29:

dnf update https://kojipkgs.fedoraproject.org//packages/dovecot/2.3.7.2/1.fc29/x86_64/dovecot-2.3.7.2-1.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/dovecot/2.3.7.2/1.fc29/x86_64/dovecot-mysql-2.3.7.2-1.fc29.x86_64.rpm

Fedora 30:

dnf update https://kojipkgs.fedoraproject.org//packages/dovecot/2.3.7.2/1.fc30/x86_64/dovecot-2.3.7.2-1.fc30.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/dovecot/2.3.7.2/1.fc30/x86_64/dovecot-mysql-2.3.7.2-1.fc30.x86_64.rpm

Anmerkung: Wer einen anderen Backend als MYSQL benutzt, muß die Anweisung anpassen.

Marius Welt

Tag Archives: fedora

Fedora wird DoH nicht in Firefox aktivieren