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

Linux am Dienstag – Programm für den 25.3.2025

Diesmal bei Linux am Dienstag machen wir den Desktop schöner.

Linux am Dienstag – Programm für den 25.3.2025

u.a. im Programm am 25.3.2025, ab 19 Uhr :

  • Sicherheit – ForntinetFirewalls unter Beschuss
  • Deep Fakes – in Bewerbungsgesprächen
  • ChatGPT – Sprüche in seriösen Büchern
  • ChatGPT – erklärt Nutzer zum Mörder
  • KI Upscaleing – macht Inhalt auch nicht besser
  • Linux – Desktop verschönern mit Fondo

und andere IT-Newsbeiträge aus aller Welt. Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .
Hinweis: Die bisherigen Vorträge findet man unter https://linux-am-dienstag.de/archiv/ .

Pinephone: Telefonieren mit Twinkle

Ihr wollte auch Eure Telefonanlage zuhause benutzen, wenn Ihr mit dem Pinephone unterwegs seid? Euch kann geholfen werden. Der SIP Client Twinkle macht es möglich.

Pinephone: Telefonieren mit Twinkle

Ich hatte heute morgen nichts besseres vor und probierte mal Twinkle auf dem Pinephone mit Fedora 42 aus. Die PostmarketOS Leute hatten das wohl schon einmal im Einsatz, aber auch Bugs gefunden. Bei Fedora reicht es nur für einen RFE, Bugs habe ich keine gefunden.

Die erste Hürde

die Ihr zu bewältigen habt, ist, es startet nicht mit Phosh als DE (Desktop Environment). Das liegt an der Konstruktion, daß Twinkle ohne UI startet und dafür direkt ins Systemtray will, was ja nicht geht, da es das nicht gibt. Dazu wird Twinkle nicht direkt gestartet, k.A. wieso, sondern durch den Befehl twinkle-uri-handler . Dem kann man aber nicht sagen, daß Twinkle mit offenem Window gestartet werden muß.

Im Ergebnis  dürfte Ihr die Desktopdatei unter /usr/share/applications/twinkle.desktop  so ändern:

Exec=twinkle –show %u

dann startet es normal.

Die zweite Hürde

besteht aus Eurem Telefonbildschirm, der ist klein. „Gerade so an der Grenze“ trifft es wohl am besten. Man kann Twinkle benutzen, aber es wahnsinnig fitzelig das mit dem Finger zu bedienen. Von den ganzen Menüs, die man besuchen muß um die SIP-Daten einzugeben, solltet Ihr die Finger lassen, wenn Ihr über das Dock keine Maus angehängt habt.

Zu Eurem Glück müßte Ihr das gar nicht, denn Twinkle ist ja eine Desktop App, die die gesamte Konfiguration in einem Ordner in Eurem Home abspeichert. Alles was Ihr machen müßt ist, Twinkle auf dem PC zu konfigurieren und dann den Ordner „.twinkle“ auf das Pine zu kopieren, z.B. so:

$ tar cz .twinkle | ssh pine@pine „tar xz“

ABER: macht das nur, wenn Twinkle beendet ist, sonst denkt Twinkle auf dem Pine, es würde schon laufen, weil seine lck (lock) Datei in dem Ordner liegt. Falls Euch das doch passiert: rm -f .twinkle/twinkle.lck

Kleiner Tip

Passt die Lautstärke des Mikros und der Wiedergabe für Twinkle an. Ansonsten ist es etwas übersteuert.