CVE-2019-11500: Heap-Overwrite Lücke in Dovecot

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.

Die Sache mit dem Namen

Gerade drüber gestolpert:

Paketname : igt-gpu-tools

igt-gpu-tools (früher bekannt als intel-gpu-tools) ist der Standard für das Schreiben von Testfälle für DRM-Treiber.
Es enthält auch eine Handvoll nützlicher Werkzeuge für die folgenden Bereiche verschiedene Treiber, wie z.B. Intels GPU-Tools für i915.

Aus „intel-gpu-tools“ wird „igt-gpu-tools“, was ausgeschrieben dann „intel-gpu-tools-gpu-tools“ bedeutet. Wer denkt sich sowas bitte aus?

Das ist ganz klar noch eine Steigerung von dem GNOME MPV Unsinn.

Linux Praxis: Remote Desktop Protokoll

Da ich kürzlich Gelegenheit bekam per Fernwartung in einer Firma mit Windowsclienten zu arbeiten, möchte ich Euch viel unnötiges Gesuche darüber ersparen, was geht und was nicht geht.

Windows 10 und RDP

Zunächst einmal, es geht um Windows 10 und dessen RDP Service. Das man den nicht einfach ins Netz exponieren kann, weil der PC sonst binnen Sekunden gehackt wird, sollte jedem spätestens seit BlueKeep und dessen Nachfolger, der sich gleich wurmartig fortpflanzen konnte, klar sein.

Wie macht man das jetzt, wenn man keine teure Firewalllösung einkaufen möchte, die dann vielleicht selbst zur ungepatchten Schwachstelle wird ( so wie die F5 ) oder nicht schnell genug die Signaturen aktualisiert?

Linux ist die Rettung

Man nehme ein gescheites Linux (Centos LTS mit Autoupdate würde reichen), und stellt es ins Intranet. Der SSH Port wird über DSL-Router nach außen exponiert, idealerweise nicht Port 22, was die Anzahl der Scans reduziert, und fail2ban-ed dann noch gleich die BruteForceangriffe weg 😉 . Das man den Zugriff nur per >=4K-SSH-Schlüssel und nicht mehr per PAM ( Passwort ) zulässt dürfte selbstverständlich sein, oder muß ich das extra erwähnen? 🙂

Wenn man Linux auch als Desktop hat, ist es jetzt ganz leicht den RDP Port des Windowszielrechners im Intranet auf 127.0.0.1 zu forwarden:

ssh -C -L 3389:192.168.178.33:3389 root@externe.dsl.ip

Kleiner Pro Tip: „-C“ nicht vergessen, dann komprimiert SSH die Daten zusätzlich noch, was gerade bei langsamen Verbindungen von Vorteil sein wird. Durch SSH wird die Verbindung über das Netz komplett verschlüsselt.

Wie verbindet man sich jetzt zu seinem mit TLS gesicherten RDP Service?

Jetzt kommen wir zum eigentlichen Problem mit Linux als RDP Clienten: kaum ein RDP Client taugt was.

Die kurze Liste der RDP Clienten unter Fedora lautet: RDesktop, gnome-rdp aka Vinagre und freerdp

RDesktop und Vinagre kann man gleich löschen. Der RDP Client der Wahl ist FreeRDP! Das ist nämlich der einzige, der überhaupt funktioniert. Vinagre baut zwar eine Verbindung auf, liefert aber nur ein Schwarzbild ab => fail. RDesktop war nicht mal dazu in der Lage.

FreeRDP hat neue Optionen

Im Netz findet man z.b. im Ubuntu-Forum Hinweise wie man FreeRDP erzählt, wo es hin soll und wie groß der Bildschirm sein. Leider muß man das angeben, sonst gibt es die Defaultwindowssession mit 1280×1024 😀 Das hatten wir dann auf dem 3k Display vom meinem Surface Pro als kleines Icon irgendwo in der Ecke vom Bildschirm liegen 😉 Ok,ok, Icongröße hatte es nicht ganz, aber da FreeRDP nicht DPI-Scaleaware ist, mußte man halt eine Lupe benutzen.

FreeRDP scheint seine CLI-Optionen umstrukturiert zu haben und man muß statt mit „-“ mit „/“ arbeiten. Beispiel: /size:WxH. Ob die sich an die Windows-DOSshell anwanzen wollten, wer weiß …

Windows failed beim DPI-Scaling

Es bliebt einem nichts anderes übrig als FreeRDP zu sagen, wie groß das Fenster denn sein soll, damit man dann einen größeren Font im Windows einstellen kann. Ab da wird es dann peinlich für M$, denn das DPI-Scaling funktioniert nur bei realen Bildschirmen, nicht bei Remote-Zugriffen per RDP 😀 Allen Versuchen zum Trotz blieb das Fenster ohne DPI-Scaling, auch als Windows behauptet hat, es würde 500%! skalieren 😉 Lustigerweise warnt einen Windows, daß es kein Vergnügen sein wird, ein 500% skaliertes Windows zu benutzen. Ich wäre schon froh über 200% gewesen 😀

Wenn man auf dem Windowsystem jetzt mit Browsern arbeiten muß, ist die Lösung denkbar einfach: das Browserfenster zoomen. Bei richtigen Anwendungen geht das natürlich nicht, was das Arbeiten auf einem 3k-4K Display nicht gerade vergnüglich macht. Da hilft es nur einen kleineren Bildschirm zu benutzen. Für ein FullHD Display könnte die Anweisung an FreeRDP so lauten:

xfreerdp /u:username /v:127.0.0.1 /size:1920×1020

Damit ist das Fenster brauchbar in Cinnamon eingefasst. Da wir glücklicherweise zwei HighSpeed-DSL Anschlüsse nutzen, ist die Latenz der Pakete sehr niedrig und das Arbeiten ist (bislang) angenehm.

Windows ist in dem Szenario leider nicht das einzige Programm, das failed. FreeRDP müßte das Scaling eigentlich auch automatisch beachten. FreeRDP bietet als Optionen jetzt einen Scalingparameter an, leider funktioniert auch das nicht sofort.

xfreerdp /u:username /v:hostname /size:1920×1080 /scale:140 /scale-desktop:200

Obiges bringt dann die Lösung. Damit läßt sich der Desktop uns seine Anwendungen auch auf 3k/4K besser lesen. Offensichtlich muß man Windows erst von außen sagen, das es skalieren soll, interne Einstellungen zählen halt nicht.

Für FreeRDP gibt es übrigens noch die Rocket-GUI, so muß man nicht alles in der Bash machen. Allerdings ist das Programm recht simple und wird nicht allen Anforderungen an unser spezielles Problem gerecht.

Aus Gnome MPV wurde Celluloid

„Ins Hirn geschissen“ würden Bayern wohl zurecht sagen, wenn Sie von dem neuesten Streich wüßten, der die GTK Gui von MPV erwischt hat.

Aus GNOME MPV wurde Celluloid

Da über den Namenswechsel kaum berichtet wurde, und Google hat sich wirklich ins Zeug gelegt was zu finden, ist es jetzt auch leider zu spät sich dazu zu melden. Trotzdem soll nicht unerwähnt bleiben warum denn der Name geändert wurde:

Weil „GNOME MPV“ ein wenig uninformativ ist, wie GNOME Entwickler Tobias Bernard erklärt:

„Der aktuelle Name ist etwas unelegant und passt nicht wirklich zu anderen Anwendungen auf der GNOME-Plattform. Gute App-Namen sind in der Regel ein einzelnes Substantiv, das mit der Domäne der App zusammenhängt (z.B. „Fragments“ für eine Torrent-App oder „Peek“ für einen Bildschirmrekorder).

Also alleine schon die Auflistung der Beispiele ist ja wohl an den Haaren herbei gezogen! „Torrento“ wäre ein passender Name für eine Torrent-App, aber doch nicht „Fragments“. „Peek“, was soll das bitte sein? „to peek“ meint in der Übersetzung „gucken“, „spähen“, „nachsehen“, aber doch keinen Bildschirmrekorder.

Der alte Name „GNOME MPV“ macht genau das, was angeblich gefordert ist, er beschreibt was es ist: Eine Gnomeversion von MPV. Geht es eigentlich noch besser?

eine Rasenfläche mit Häusern

Um den hier gehts!

Also: Wieso nur?

Über die wahren Gründe kann ich nur spekulieren, aber die Assoziation „Celluloid/Zelluloid“ mit Film, Popkorn und „Rahmen“ ( kannste Dir nicht ausdenken sowas s.u. ) dürfte heutzutage hinken. Wo gibt es denn noch Kinos die analoge Projektoren haben? Im Museumsdorf? Wie alt muß man bitte sein um bei „Film ansehen“ als erstes an durchsichtige Plastikstreifen mit lustigen Bildern drauf und ein Mais-Butter-Komglumerat zu denken?

Ich habe dazu die „Diskussion“ dazu gefunden: https://github.com/celluloid-player/celluloid/issues/353

Wie jemand woanders meinte, könnte Celluloid als Name allein deswegen genommen worden sein, weil alles andere schon belegt war. Das fällt einem sehr schnell auf die Füße, wenn man doppelte Appnamen hat.

Wenn man sich die „Diskussion“ oben mal durchliest, merkt man gleich, daß das nur eine Handvoll Leute entschieden hat. Wenn die sich mal in 1-2 Jahren nicht wünschen werden, daß sie das mal lieber gelassen hätten. Wer jetzt nach MPV sucht, stolpert jedenfalls nicht mehr so leicht über den Player und wer RPMFusion aktiviert hat, wird eh nur leicht irritiert drein schauen und dann nur das reine MPV installieren.

Gesagt – Getan 🙂

Diese Arbeitshypothese habe ich gleich mal getested und dabei gesehen, daß das gnome-mpv Paket noch bei „dnf search mpv“ gefunden wird, weil es vermutlich als Baserpm noch im Repo vorhanden ist. Dabei fiel mir aber auch ein neuer Videoplayer auf MPV Basis auf : deepin-movie. Leider könnt Ihr Euch die Installation schenken, weil:

[marius@eve ~]$ deepin-movie
deepin-movie: symbol lookup error: deepin-movie: undefined symbol: _ZN3Dtk6Widget9DTitlebar7setIconERK7QPixmap

Da passen wohl das exe und die referenzierten Libs nicht ganz zueinander.

Kleiner Rework gefällig?

Wenn man GNOME MPV wieder als Namen haben will, kann sich entweder eine eigene DesktopDatei nach Schreibtisch kopieren oder gleich die systemweite Desktpdatei anpassen:

[marius@eve ~]$ cat /usr/share/applications/io.github.celluloid_player.Celluloid.desktop 
[Desktop Entry]
Version=1.0
Name[bg]=Gnome MPV
Name[ca]=Gnome MPV
Name[cs]=Gnome MPV
Name[da]=Gnome MPV
Name[de_DE]=Gnome MPV
Name[eo]=Celuloido
Name[es]=Gnome MPV
Name[fr]=Gnome MPV
Name[hr]=Gnome MPV
Name[hu]=Gnome MPV
Name[it]=Gnome MPV
Name[ja]=Gnome MPV
Name[nl]=Gnome MPV
Name[pl]=Gnome MPV
Name[pt_BR]=Gnome MPV
Name[pt_PT]=Gnome MPV
Name[ro]=Gnome MPV
Name[ru]=Gnome MPV
Name[sr]=Gnome MPV
Name[sr@latin]=Gnome MPV
Name[sv]=Gnome MPV
Name[tr]=Gnome MPV
Name[zh_CN]=Gnome MPV
Name[zh_TW]=Gnome MPV
Name=Gnome MPV
...

Ein paar Sekunden nachdem Speichern der Änderungen, aktualisiert sich das Menü und alle Appnamen in Nemo und Nautilus. Bis auf den „Celluloid“ Namen im Fensterrahmen, wärs damit erstmal wieder in grünen Bereich 😉

In dem Sinne: gute Nacht.

Update: Fedora: Probleme mit hwdata und Asus Mainboards

Wie bereits vor zwei Tagen mitgeteilt, gibt es bei Fedora ein Problem mit dem Paket hwdata. Darin sind die PCI Ids der Geräte und Hersteller enthalten. Die Quelle der Daten wird bei Github gepflegt und damit betrifft es nicht nur Fedora, sondern alle Distributionen, die Ihre Daten von dort beziehen.

Die Datei oui.txt (Organisational Unit Ids) verursacht dies, offensichtlich sind dort Kennungen falsch eingetragen  oder verloren gegangen, so das Wechselmedien nicht sauber erkannt werden.

Kuriose an der Sache: Der eingesteckte USB Stick war für Root gemountet und nicht für den angemeldeten User.

Wie eine falsche OUI das auslösen kann, wird derzeit geprüft. Ich meine, da liegt ein ziemlich dicker Bug kurz vor seiner Entdeckung.