Qualys: Drei Umgehungen von Ubuntus Namespace-Beschränkungen für unprivilegierte Benutzer

Gestern Abend kam ein Advisory von Qualys über Sicherheitsprobleme mit Ubuntus AppArmor und UserNameSpaces heraus. Das Ubuntu Security Team ist von Anfang an involviert, ob das aber per Update gefixt werden kann, ist fraglich. Bevor Panic ausbricht, damit das überhaupt relevant wird, muß ein Dritter, egal ob legal oder per Remote-Exploit ( z.b. durch Firefox ) Zugriff auf Euren PC haben.

Qualys: Drei Umgehungen von Ubuntus Namespace-Beschränkungen für unprivilegierte Benutzer

Erst mal klären wir, das es mit Namespaces auf sich hat. Dateibeschränkungen für User sind Euch ja sicher bekannt, da regelt man, welcher User auf welche Datei zugreifen darf bzw. diese ausführen kann. Das reichte irgendwann nicht mehr aus, als alle Pcs Netzwerkkarten und andere schöne Geräte wie USB, PCI hatten, denn der Zugriff da drauf war nicht beschränkt, weil Root die eingerichtet hat. In einem NameSpace sind bestimmte Rechte wie z.b. Netzwerkänderungsrechte möglich. Das ist aber nur ein Recht unter Dutzenden.

Kleines Beispiel:

ap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore

Das sind die Adminrechte des Systemaccounts für Fedora, also der Hauptuser, abgesehen von Root. Deswegen sind auch Admin Capabilities enthalten. Der „Otto-Normal“-Benutzer hat diese i.d.R. nicht, weil er z.b. kein neues Interface zum Netzwerk hinzufügen soll. Nützlich ist das z.b. für User-VPNs, daher braucht eine Anwendung die VPN Tunnel bauen will und vom User ausgeführt wird, die Rechte dazu, was in dem Namespace organisiert ist. Damit kann jeder Benutzer eines PCs den NetworkManager starten und sich ein VPN einrichten ohne das man Root sein muß oder sudo etc. braucht.

Das System wurde von Qualys ausgetrickst, weil Ubuntu das selbst ausgehöhlt hatte:

Bei Ubuntu 24.04 LTS ist dann die Verwendung von unprivilegierten Benutzernamensräumen für alle Anwendungen erlaubt, aber der Zugriff auf alle zusätzlichen Berechtigungen innerhalb des Namespaces verweigert worden. Dies ermöglicht mehr Anwendungen feingranuliert mit dieser Standardbeschränkung umzugehen, während gleichzeitig gegen den Missbrauch von Benutzer-Namensräumen geschützt, ergibt sich aber eine zusätzliche Angriffsfläche für den Zugriff auf den Linux-Kernel.“ Zitat: übersetztes Qualys Security Advisory 27.3.2025 via FD ML

Meint nichts anderes als das die Maßnahme unabsichtlich ein Tor zur Hölle, in dem Fall zur Local Privilege Escalation, aufgestoßen hat. Ganz nach dem Motto: der Weg zur Hölle ist mit guten Absichten gepflastert 😉

Diese drei Wege hat Qualys gefunden:

– Ein unprivilegierter lokaler Angreifer kann einfach das Tool aa-exec verwenden (das standardmäßig auf Ubuntu installiert ist), um zu einem der vielen vorkonfigurierten AppArmor-Profile zu wechseln, die die Erstellung von Benutzernamensräumen mit vollen Funktionen erlauben (z. B. das Chrome-, Flatpak- oder Trinity-Profil).

– Ein unprivilegierter lokaler Angreifer kann zunächst eine Busybox-Shell ausführen, die standardmäßig auf Ubuntu installiert ist und zu den Programmen gehört, deren vorkonfiguriertes AppArmor-Profil die Erstellung von Benutzernamensräumen mit vollen Fähigkeiten erlaubt. Namespaces mit vollen Fähigkeiten erlaubt.

– Ein unprivilegierter lokaler Angreifer kann eine Shell mit LD_PRELOAD in eines der Programmen, deren vorkonfiguriertes AppArmor-Profil die Erstellung von die Erstellung von Benutzernamensräumen mit vollen Fähigkeiten erlaubt (z. B. ist Nautilus standardmäßig auf Ubuntu Desktop installiert).

Zitat: übersetztes Qualys Security Advisory 27.3.2025 via FD ML

Qualys sagt aber auch, daß die meistens gar nicht nötig sind, weil die Linux Distributionen Tools zur Verfügung stellen um NameSpaces mit vollen Rechten zu erstellen. Der Unterschied ist, daß das eine gewollt ist, das andere nicht. Im weiteren behandelt das Advisory die Möglichkeiten innerhalb eines beliebigen NameSpaces auszubrechen und sich Adminrechte zu verschaffen, der eigentliche Exploit um den es dabei geht.

Qualys zeigt im weiteren Verlauf des Advisories konkrete Beispiele wie das geht und bespricht diese. Was es am Ende nicht gibt, ist eine Lösung sich davor zu schützen.

Das Advisory findet Ihr im Netz hier: https://seclists.org/fulldisclosure/2025/Mar/8

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 😉