Fedora wird DoH nicht in Firefox aktivieren

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.

Firefox 70 für Fedora (fast) bereit

Liebe Fedorianer,

wenn Ihr morgen früh aufsteht, könnt Ihr Euch den neuen Firefox 70 installieren. Die Pakete befinden derzeit im Bau und sollten schon vor 2 Stunden fertig sein. Leider ist eine Hamsterfarm ausgefallen, daher dauert es noch ein bisschen.

Dana Keeler vom Mozilla Firefox Team ist indirekt auch schon begierig auf das Release, denn es könnte das SSL Problem aus dem Artikel Firefox, die Fritz!box & der SEC_ERROR_INADEQUATE_KEY_USAGE Fehler lösen. Dann hätten alle AVM Linux Kunden fast schon sowas wie Weihnachten im Oktober.

Apropos Weihnachten, El Camino Chrismas mit Tim Allen könnte man sich ansehen, wenn man nicht auf Happy Chrismas steht. Kurzversion: Ein alkoholkranker Dorfpolizist hält sich für unfehlbar, was zu einer wilden Schießerei zwischen den Polizisten führt. Das Ende ist dann eher nicht was man erwarten würde. Von daher, wer auf Überraschungen steht, dem kann damit geholfen werden. Den Film gibt es derzeit auf Netflix zu sehen.

Fast hätte ich es vergessen, Thunderbird 68.1.1-3 ist verfügbar. Wer vorhat jetzt das Fedora Upgrade vorzunehmen, sollte das dringend VORHER einspielen, sonst besteht die Gefahr, daß etwas schwer mit Eurem Profil schief geht.

 

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.