Schwachstellen in snapd und Rust Coreutils, die Root-Rechte in Ubuntu ermöglichen

Das Unternehmen Qualys hat eine Schwachstelle (CVE-2026-3888) in der Funktionsweise von snap-confine und systemd-tmpfiles in Ubuntu entdeckt, die es einem nicht privilegierten Benutzer erlaubt, Root-Zugriff auf das System zu erhalten. Das Problem tritt in Ubuntu ab der Standardkonfiguration der Version 24.04 auf. In Ubuntu 16.04-22.04 kann die Schwachstelle in nicht standardmäßigen Konfigurationen ausgenutzt werden, die das Verhalten neuerer Versionen der Distribution imitieren. In Ubuntu ist das Patch in dem gestrigen Update des snapd-Pakets verfügbar. In snapd wurde das Problem mit Update 2.75 behoben.

Die Schwachstelle entsteht durch die fehlerhafte Interaktion der Tools snap-confine und systemd-tmpfiles, die mit erhöhten Rechten ausgeführt werden. Das Tool snap-confine erstellt eine Sandbox-Umgebung zur Ausführung von Snap-Anwendungen, während systemd-tmpfiles die automatische Bereinigung temporärer Dateien und Verzeichnisse vornimmt. Standardmäßig ist das Tool systemd-tmpfiles so konfiguriert, dass es alle alten Dateien und Verzeichnisse in /tmp löscht, was von einem Angreifer ausgenutzt werden kann, um das Verzeichnis /tmp/.snap zu ersetzen, nachdem es von systemd-tmpfiles gelöscht wurde, aber vor der Neuanlage durch snap-confine.

Ein Angriff besteht darin, auf den Start des Prozesses zur Bereinigung temporärer Dateien zu warten, das Verzeichnis /tmp/.snap nach dessen Löschung zu ersetzen und eine modifizierte Kopie der Bibliotheken /tmp/.snap/usr/lib/x86_64-linux-gnu.exchange zu platzieren. Der Angreifer muss möglicherweise mehrere Tage auf den Start von systemd-tmpfiles warten, da in Ubuntu 24.04 der Bereinigungsprozess alle 10 Tage und in neueren Versionen alle 30 Tage gestartet wird. Nach dem Ersetzen des Verzeichnisses erreicht der Angreifer die Initialisierung einer neuen Sandbox-Umgebung mit Hilfe von snap-confine.

Während der Erstellung des Inhalts der Sandbox-Umgebung im temporären Verzeichnis /tmp/.snap wartet der Angreifer auf den richtigen Moment und benennt /tmp/.snap/usr/lib/x86_64-linux-gnu.exchange in /tmp/.snap/usr/lib/x86_64-linux-gnu um, wodurch die Bibliotheken ersetzt und ein Bind-Mount mit Root-Rechten gewährt wird. So erlangt der Angreifer Kontrolle über die gemeinsam genutzten Bibliotheken und den ld.so-Lader, die in der Snap-Sandbox-Umgebung gestartet werden, und kann die Ausführung beliebigen Codes mit Root-Rechten durch das Starten eines beliebigen SUID-Programms, das dynamisches Linking verwendet, erreichen.

Mit Root-Zugriff in einer Sandbox-Umgebung, die durch AppArmor und einen syscall-Filter auf Basis von seccomp isoliert ist, kann ein Angreifer /bin/bash in das Verzeichnis /var/snap/$SNAP/common kopieren und die Berechtigung "04755" (suid root) setzen. Obwohl die Berechtigungen innerhalb der Sandbox-Umgebung geändert werden, ist die Datei mit den geänderten Rechten auch im Hauptsystem zugänglich. Daher reicht es aus, /var/snap//common/bash als normaler unprivilegierter Benutzer aus der standardmäßigen Systemumgebung auszuführen, um vollständigen Root-Zugriff zu erhalten.

Gleichzeitig wurde eine Schwachstelle im Toolset uutils coreutils (Rust Coreutils) festgestellt, das das Pendant des GNU Coreutils-Pakets ist und in Rust geschrieben wurde. Die Schwachstelle ermöglicht es einem unprivilegierten Benutzer, root-Rechte im System zu erlangen. Das Problem wurde während der Überprüfung von Änderungen in Ubuntu 25.10 erkannt und durch die Bereitstellung von /usr/bin/gnurm anstelle von uutils rm vor dem Release von Ubuntu 25.10 workaround-mäßig behoben. Im Paket uutils wurde das Problem in der Version uutils coreutils 0.3.0 behoben, ohne dass dies in den Änderungsprotokollen zur Behebung der Schwachstelle vermerkt wurde (es wurde angegeben, dass in rm, du, chmod und chgrp eine sichere Methode zur Umgehung von Pfaden implementiert wurde).

Das Problem wird durch einen Race Condition in dem Tool "rm" verursacht, das es einem lokalen Benutzer ermöglicht, den Inhalt eines Verzeichnisses während der Löschung einer benutzergesteuerten Datei durch den "rm"-Prozess mit Root-Rechten durch einen symbolischen Link zu ersetzen. Unter anderem kann die Schwachstelle bei der täglichen Ausführung des Skripts /etc/cron.daily/apport, das mit Root-Rechten läuft und rekursiv den Inhalt des Verzeichnisses /var/crash löscht, welches für alle Benutzer im System zur Schreibweise zugänglich ist, ausgenutzt werden.

Beim rekursiven Löschen von Verzeichnissen überprüft das Tool rm zunächst alle Verzeichnisse und löscht sie dann in umgekehrter Reihenfolge, indem es die Funktion rmdir() aufruft. Wenn der übergeordnete Ordner sofort nach dieser Überprüfung, aber vor der Überprüfung der darin enthaltenen untergeordneten Verzeichnisse durch ein symbolisches Verzeichnis ersetzt wird, führt dies dazu, dass das Verzeichnis gelöscht wird, auf das das symbolische Verzeichnis verweist. Auf diese Weise kann nicht nur jede Datei im System gelöscht werden, sondern auch ein Privilegienausstieg erreicht werden, indem das Verzeichnis /tmp/snap-private-tmp/$SNAP/tmp/.snap gelöscht wird, um den Inhalt der Sandbox-Umgebung des Snap-Pakets zu ersetzen (die Methode zur Erlangung von Root ist ähnlich wie bei der ersten Schwachstelle).

Quelle: opennet.ru