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

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“.