Der Ghostscript Exploit, der in andere Anwendungen eskaliert

Vor einigen Tagen hatte ich ja was zum Kernel Bug geschrieben, nämlich, daß ich mir mehr Sorgen mache, daß eins der Desktopprogramme geknackt wird. Jetzt ist es bei Ghostscript soweit.

Der Ghostscript Exploit, der in andere Anwendungen eskaliert

Ghostscript < 10.1.02  hat eine Schwachstelle, die das Ausführen von Code erlaubt. Das an sich ist schon schlimm, wenn man dann erfährt, daß das bei den Maintainer untergegangen ist 🙁

Schlimmer ist aber, daß die Lücke in andere Anwendungen wie InkScape, LibreOffice und Gimp eskaliert, dort also auch funktioniert. Möglich macht dies das Äquivalent der größten Container-Sorge überhaupt: Diese Anwendungen halten sich eine selbst gepatchte Version von Ghostscript in der Codebasis und naja, in der ist der Bug auch drin.

Das ist vergleichbar mit einer Sammlung von Docker Containern,Snaps & Flatpaks, welche alle die gleiche ausnutzbare libPNG drin haben und jetzt alle geupdated werden müssen, wo ja eigentlich nur eine Komponente das Update wirklich bräuchte: Ghostscript. Was zeigt das: Dumme Entscheidungen brauchen kein Containermodell 😉

Anstatt einer Komponente, müssen jetzt ein Haufen unübersehbarer Anwendungen aktualisiert werden, wozu man erstmal rausfinden muß, wo das überall drin ist. Das muß man erst mal schaffen. Log4J lässt so derbe grüßen, daß heute wohl Murmeltiertag ist.

Da zu allem Überfluss ein POC-Exploit bekannt ist, werden echte Exploits nicht lange auf sich warten lassen.

Die Situation auf Debian ist besser als die von Fedora, weil Debian immerhin das erste GS Update ausgeschickt hat, bei Fedora aber nichts am Horizont ist. Dagegen habe ich mal was gemailt…

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36664

https://www.kroll.com/en/insights/publications/cyber/ghostscript-cve-2023-36664-remote-code-execution-vulnerability

 

Entspannt Euch mal – Kernel Schwachstelle in 6.1.x++

Da gewisse Kreise mal wieder trollgleich Häme verbreiten wollen, nur weil eine Schwachstelle im Kernel ist, muß man das mal für die etwas einordnet, die nicht soviel davon verstehen, wie Sicherheitslücken einzuordnen sind.

Entspannt Euch mal – Kernel Schwachstelle in 6.1.x++

Für Desktopbenutzer ist eine Kernelschwachstelle erstmal keine besondere Lücke. Sie muß geschlossen werden, keine Frage, aber besonders kritisch ist die erst mal nicht. Bevor jemand eine Kernellücke ausnutzen kann, muß er i.d.R. Code auf dem PC ausführen können und der wird idealerweise direkt mit dem Kernel reden müssen. Von der Regel gibt es natürlich Ausnahmen, z.b. wenn die Lücke im Netzwerk-, USB- oder Bluetoothstack ist. Diese sind von außen erreichbar, sonst wären sie ja sinnlos 😉

Für Euch bedeutet das, der Angreifer muß eine Lücke in einem der unzähligen Programme auf Eurem PC ausnutzen können um seinen Code auszuführen. Dazu muß da aber erst einmal eine Lücke vorhanden sein. Und ganz realistisch betrachtet, wenn da eine Lücke drin ist, braucht der Angreifer keinen Kernel Exploit mehr. Ihr seid i.d.R. der einzige Benutzer, was bedeutet: er hat jetzt Vollzugriff auf Eure Daten. Was kann er noch mehr erreichen?

Das Extra-Mehr eines Kernelexploits

Das Extra-Mehr besteht darin, daß wenn Ihr schlau wart und Eure Bankgeschäfte mit einem anderen Benutzer macht, er da dann auch dran kommt. Bedingung für das Extra-Mehr ist also, daß Ihr Euch auch extra angestrengt habt um Eure Sicherheit zu erhöhen. Einige tun das, ich habe auch mehrere Benutzer die Jobs erledigen, aber die meisten Benutzer da draußen haben das nicht.

Deswegen solltet Ihr mehr Angst vor einer Schwachstelle in Chrome und Firefox haben, als vor dieser Kernellücke, denn die befindet sich im Speichermanagement des Kernels. Eine sogenannte Use-After-Free-Schwachstelle. Dabei gibt ein Prozess Speicherbereiche frei, die aber von einem anderen Programm/Codeteil noch aufgerufen werden, also eigentlich noch in Benutzung sind. Bekommt ein anderes Programm Zugang dazu, kann es ggf. Code in dem Kontext des den Speicherblock freigegebenen Programmes ausführen lassen.. Das geht auch in die andere Richtung, da also z.b. der Angreifer einen Stück Speicher mit Code versieht, freigibt und ein anderer Prozess führt den dort befindlichen Code aus( eher seltenes Szenario).

In einer Multi-Benutzer-Umgebung

Die Crux an dem Kernelexploit hier ist jetzt, daß die Besitzer des Prozesses der den Exploit nutzen will und des angegriffenen Programmes nicht gleich sein müssen. D.b. der Angreifer kann ein x-beliebiger User im System sein, und der angegriffene Prozess kann Root gehören. In der Konstellation wird es also richtig gefährlich, weil der angreifende Benutzer, so seine Rechte ausweiten kann. Auf einem Server muß man sich daher große Gedanken zu dieser Lücke machen, auf dem heimischen Desktop eher nicht.

Also, entspannt Euch ein bisschen. Ich fahr jetzt auf eine Party 😉

21Nails: Interview mit Eximentwickler Heiko Schlittermann

Liebe Linuxfans,

ein kleines Interview als Teaser für Euch, denn Heiko hat eingewilligt nächste Woche bei Linux am Dienstag aus dem Eximnähkästchen zu plaudern. Er steht allen Interessierten gern Rede und Antwort. Ich rate Euch dringend diesen Termin wahrzunehmen, denn in unserem Vorgespräch offenbarten sich wahre Schätze an Wissen, das ganz dringend in den Tux in Euch rein muß 😉

21Nails: Interview mit Eximentwickler Heiko Schlittermann

Die Firma Qualys hat Ihre Entdeckung 21Nails genannt, aber Sargnägel waren es mit Sicherheit nicht. Eximmitentwickler Heiko Schlittermann stand uns heute morgen dankenswerterweise für ein kurzes Interview zur Verfügung.

„21 Lücken, 7 Monate bis zur Behebung, wieviele schlaflose Nächte waren das?“

Die meiste Zeit nicht mehr als sonst auch, aber die letzten zwei Wochen
vor dem public release waren etwas anstrengend, da einige Bugs erst in
letzter Minute auftraten – wir konnten ja nicht großflächig testen.

„Was hat Euch(Devs) so lange Zeit gekostet? War es die Qualität des Fixes an sich, oder die Kommunikation mit Qualys?“

Das ist eine längere Geschichte. Anfangs hatten wir nur die Bugreports
von Qualys. In diesem Zusammenhang muss ich noch mal deren sehr
professionelles und freundliches Verhalten bei der Zusammenarbeit
hervorheben.

Wir hatten zeitnah begonnen, uns um die Probleme zu kümmern. Eigentlich
hatte ich das Taintwarn-Feature in der Pipeline, denn ich wollte das
noch vor Debian11 rausbringen und ein 4.95-Release wäre eigentlich im
November dran gewesen.

Leider wurde einer der Entwickler vom Burnout aus der Kurve geschossen.

Qualys unterstützte uns dann mit Ressourcen: Sie haben uns die Patches
geliefert, die wir *eigentlich* nur noch importieren mussten. Es gab
aber intern einige Diskussion über die technische Umsetzung: es ist
wieder seteuid()* dabei, das eigentlich nicht mehr im Exim-Code
auftauchen sollte
*) Seteuid => setzt die effektive UserID eines Prozesses auf einen bestimmten User, damit der Prozess nur noch mit dessen Rechten läuft und falls dieser Prozess exploitet wird, ist der Schaden minimiert. Hier vom User „Root“, mit dem der Prozess startet, zu User „Exim“.

Wir suchten nach anderen Lösungen, aber das funktionierte alles nicht,
und das hat Zeit gekostet.

Einige Patches mussten geringfügig umgebaut werden. Und dann blieben bei
der Testsuite einige Tests auf der Strecke, da mussten die Ursachen
gefunden werden und gefixt werden. Exim hat eine Regression-Testsuite, mit gut
1000 Testsscripts, die jeweils im Schnitt 2…6 Einzeltests enthalten.
(Anm.d.R. insgesamt knapp 4000 Tests)

Qualys hat uns die ganze Zeit wertvoll unterstützt.

Mein Fazit: Wir hätten die Patches importieren sollen, Testsuite anpassen, shippen.
Und uns dann anschließend um Verschönerungsmaßnahmen kümmern. Auf der
anderen Seite wurde uns von Qualys kommuniziert, dass ja noch nichts brennt
und es keine Anzeichen gibt, dass eine der gefundenen Vulnerabilites aktiv genutzt wird.

„Wie kam es dazu, daß die Deadline so knapp war? Die Distros hatten ja kaum Zeit die neuen Versionen zu testen, geschweige denn zu shippen. Bei Fedora fiel die Testversion mit dem Releasedate des Advisories zusammen.“

Soweit ich den Prozess bei oss-security* verstehe, ist 1 Woche Vorlauf für die Distros schon gut bemessen. 3 Tage werden angestrebt.
(* Anm.d.R. OSS-Security ist eine öffentliche Mailingliste zu Securitymeldungen auf der u.a. die großen Distributionen und andere Organisationen vertreten sind )

„Da bleibt nicht viel Zeit für Test. Hat sich im Ablauf des Teams etwas geändert durch die Herkulische Aufgabe? Seit Ihr jetzt für die Zukunft besser bewappnet?“

Lesson learned. See above 🙂

„In der Mailing sieht man jetzt wieder sehr viele Hilferufe wegen „Tainting“. Erklärst Du mal, wie es dazu gekommen ist.“

Nun. Wir haben das Konzept von „tainted data“ mit 4.94 eingeführt. Da
werden Daten, die „von außen“ kommen als nicht vertrauenswürdig
betrachtet, und können z.B. nicht verwendet werden, um Dateien zu
öffnen. Der Klassiker

data = ${lookup{$local_part}lsearch{/etc/exim/virtual/$domain}}

geht dann plötzlich nicht mehr. Die „$domain“ ist „tainted“.

Wer jetzt beim Update von < 4.94 auf 4.94.2 aktualisiert hat, stand
plötzlich vor einer Herausforderung. Die Konfig ist nicht mehr sicher
und Exim arbeitet nicht mehr wie gewohnt.

Auch darüber hatten wir intern viele Diskussionen. (Das ist auch ein
Grund, warum wir 4.95 noch nicht released hatten: weil ich der Meinung
war, dass das mit dem Tainted so nicht bleiben kann.) Bisher waren
Updates des Exim immer möglich, ohne die Konfiguration ändern zu müssen.

(Der einzige „breaking Change“ war das aus Sicherheitsgründen
vorgenommene Bereinigen der Umgebungsvariablen für Kindprozesse. Da
hatten wir keine Wahl.)

Zurück zur Frage: Ja, wer jetzt plötzlich von < 4.94 auf >= 4.94
aktualisiert hat, hat möglicherweise ein Problem. Um das zu mildern, haben
wir eine Main-Config-Option eingeführt: „allow_insecure_tainted_data“.
Diese Option ist aber *nicht* Bestandteil von 4.94.2. Es gibt die
Meinung, dass wir alte Versionen vor 4.94 eh nicht unterstützen, und die
die sich den Exim selber bauen, sind schon bei 4.94, haben also mit dem
Update kein Problem. Ist sicher diskutierbar…

Wer über seine Distro aktualisiert, hat kein Problem, wir haben Debian
beim Backport der Patches auf 4.92 unterstützt. Von den anderen Distros
wissen wir nichts, aber es sieht so aus, als hätten die das auch
irgendwie gelöst.

Wer von Debian 10 auf Debian 11 aktualisiert, hat auch kein Problem, weil
Debian freundlicherweise den oben erwähnten „taintwarn“ Patch mit
übernommen hat.

Hm. Zu viel Antwort für die kurze Frage…:)

„Letzte Frage: Wird es jetzt aus Deiner Sicht Zeit, die Beispiele in der Eximdoku zu überarbeiten und Tainting-sichere Beispiele anzuführen?“

Ja, definitiv ist da noch etwas dokumentarische Arbeit nötig. Jeder
ist eingeladen, sich daran zu beteiligen.

Die Beispiel-Config ist „tainting sicher“.