Das Unternehmen Qualys hat eine Sicherheitsanfälligkeit (CVE-2026-3888) in der Zusammenarbeit zwischen snap-confine und systemd-tmpfiles unter Ubuntu entdeckt, die es einem unprivilegierten Benutzer ermöglicht, Root-Zugriff auf das System zu erhalten. Das Problem tritt in Ubuntu in der Standardkonfiguration ab der Version 24.04 auf. In Ubuntu 16.04-22.04 kann die Sicherheitsanfälligkeit in nicht standardmäßigen Konfigurationen ausgenutzt werden, die das Verhalten neuerer Versionen der Distribution nachahmen. In Ubuntu ist der Fix in der gestrigen Aktualisierung des Pakets snapd verfügbar. In snapd wurde das Problem mit dem Update 2.75 behoben.
Die Sicherheitsanfälligkeit ergibt sich aus der fehlerhaften Interaktion der Tools snap-confine und systemd-tmpfiles, die mit erhöhten Rechten ausgeführt werden. Das Tool snap-confine erstellt eine Sandbox-Umgebung für die Ausführung von Snap-Anwendungen, während systemd-tmpfiles die automatische Bereinigung temporärer Dateien und Verzeichnisse durchführt. Standardmäßig ist das Tool systemd-tmpfiles so konfiguriert, dass alle alten Dateien und Verzeichnisse in /tmp gelöscht werden, was von einem Angreifer genutzt werden kann, um das Verzeichnis /tmp/.snap zu ersetzen, nachdem es von systemd-tmpfiles gelöscht wurde, aber bevor es von snap-confine neu erstellt wird.
Der Angriff beruht darauf, dass der Angreifer darauf wartet, dass der Prozess zur Bereinigung temporärer Dateien startet, das Verzeichnis /tmp/.snap nach dessen Löschung ersetzt und eine modifizierte Kopie der Bibliotheken in /tmp/.snap/usr/lib/x86_64-linux-gnu austauscht. Es könnte für den Angreifer notwendig sein, mehrere Tage auf den Start von systemd-tmpfiles zu warten, da in Ubuntu 24.04 der Bereinigungsprozess alle 10 Tage und in neueren Versionen alle 30 Tage ausgeführt wird. Nach dem Austausch des Verzeichnisses erreicht der Angreifer die Initialisierung einer neuen Sandbox-Umgebung mit Hilfe von snap-confine.
Während der Erstellung 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 er die Bibliotheken ersetzt und deren Bind-Montage mit Root-Rechten ermöglicht. Auf diese Weise erhält der Angreifer Kontrolle über die gemeinsamen Bibliotheken und den Loader ld.so, die in der Sandbox-Umgebung von Snap ausgeführt werden, und kann die Ausführung beliebigen Codes mit Root-Rechten über das Starten eines beliebigen SUID-Programms erreichen, bei dem dynamisches Linking verwendet wird.
Mit Root-Zugriff in einer durch AppArmor isolierten Sandbox-Umgebung und einem auf seccomp basierenden Systemaufruf-Filter kann ein Angreifer /bin/bash in das Verzeichnis /var/snap/$SNAP/common kopieren und ihm die Berechtigungen „04755“ (suid root) zuweisen. Obwohl die Berechtigungen innerhalb der Sandbox-Umgebung geändert wurden, ist die Datei mit den geänderten Berechtigungen auch im Hauptsystem zugänglich. Daher reicht es aus, /var/snap//common/bash als regulärer nicht privilegierter Benutzer aus der regulären Systemumgebung zu starten, um vollen Root-Zugriff zu erlangen.
Parallel wurde eine Schwachstelle im Werkzeug uutils coreutils (Rust Coreutils), dem Äquivalent des GNU Coreutils-Pakets, das in Rust geschrieben ist, entdeckt. Diese Schwachstelle ermöglicht es einem nicht privilegierten Benutzer, Root-Rechte im System zu erlangen. Das Problem wurde während der Überprüfung von Änderungen in Ubuntu 25.10 identifiziert und vor der Veröffentlichung von Ubuntu 25.10 durch die Bereitstellung von /usr/bin/gnurm anstelle von uutils rm umgangen. Im Paket uutils wurde das Problem in der Version uutils coreutils 0.3.0 behoben, ohne dass in der Änderungsprotokollliste auf die Behebung der Schwachstelle hingewiesen wurde (es wurde angegeben, dass in rm, du, chmod und chgrp eine sichere Methode zum Umgehen von Pfaden implementiert wurde).
Das Problem wird durch einen Race Condition in der „rm“-Utility verursacht, die es einem lokalen Benutzer ermöglicht, den Inhalt eines Verzeichnisses während der Löschung einer Benutzer-Datei durch den „rm“-Prozess mit Root-Rechten durch einen symbolischen Link zu ersetzen. Unter anderem kann die Schwachstelle bei täglichem Ausführen des Cron-Skripts /etc/cron.daily/apport ausgenutzt werden, das mit Root-Rechten ausgeführt wird und den Inhalt des Verzeichnisses /var/crash rekursiv löscht, das für alle Benutzer im System schreibbar ist.
Beim rekursiven Löschen von Verzeichnissen überprüft die Utility rm zuerst alle Verzeichnisse und löscht sie dann der Reihe nach in umgekehrter Reihenfolge unter Aufruf der Funktion rmdir(). Wenn es gelingt, das übergeordnete Verzeichnis nach der Überprüfung dieses Verzeichnisses, aber vor der Überprüfung der darin enthaltenen untergeordneten Verzeichnisse durch einen symbolischen Link zu ersetzen, führt dies dazu, dass das Verzeichnis gelöscht wird, auf das der symbolische Link zeigt. So kann nicht nur eine beliebige Datei im System gelöscht werden, sondern auch durch das Löschen des Verzeichnisses /tmp/snap-private-tmp/$SNAP/tmp/.snap ein Privilegien-Upgrade durch den Austausch des Inhalts der Sandbox-Umgebung des Snap-Pakets erreicht werden (die Methode zur Erlangung von Root-Rechten ist analog zur ersten Schwachstelle).
Quelle: opennet.ru
