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\u00e4\u00dfigen Konfigurationen ausgenutzt werden, die das Verhalten neuerer Versionen der Distribution imitieren. In Ubuntu ist das Patch in dem gestrigen Update des snapd-Pakets verf\u00fcgbar. In snapd wurde das Problem mit Update 2.75 behoben. <\/p>\n
Die Schwachstelle entsteht durch die fehlerhafte Interaktion der Tools snap-confine und systemd-tmpfiles, die mit erh\u00f6hten Rechten ausgef\u00fchrt werden. Das Tool snap-confine erstellt eine Sandbox-Umgebung zur Ausf\u00fchrung von Snap-Anwendungen, w\u00e4hrend systemd-tmpfiles die automatische Bereinigung tempor\u00e4rer Dateien und Verzeichnisse vornimmt. Standardm\u00e4\u00dfig ist das Tool systemd-tmpfiles so konfiguriert, dass es alle alten Dateien und Verzeichnisse in \/tmp l\u00f6scht, was von einem Angreifer ausgenutzt werden kann, um das Verzeichnis \/tmp\/.snap zu ersetzen, nachdem es von systemd-tmpfiles gel\u00f6scht wurde, aber vor der Neuanlage durch snap-confine. <\/p>\n
Der Angriff besteht darin, auf den Start des Prozesses zur Bereinigung tempor\u00e4rer Dateien zu warten, das Verzeichnis \/tmp\/.snap nach dessen L\u00f6schung zu ersetzen und eine modifizierte Kopie der Bibliotheken \/tmp\/.snap\/usr\/lib\/x86_64-linux-gnu.exchange zu platzieren. Der Angreifer k\u00f6nnte mehrere Tage auf den Start von systemd-tmpfiles warten, da im Ubuntu 24.04 der Reinigungsprozess alle 10 Tage und in neueren Versionen alle 30 Tage ausgef\u00fchrt wird. Nach dem Ersetzen des Verzeichnisses erreicht der Angreifer die Initialisierung einer neuen Sandbox-Umgebung mit snap-confine. <\/p>\n
W\u00e4hrend der Erstellung des Inhalts der Sandbox-Umgebung im tempor\u00e4ren 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\u00e4hrt wird. So erlangt der Angreifer Kontrolle \u00fcber die gemeinsam genutzten Bibliotheken und den ld.so-Lader, die in der Snap-Sandbox-Umgebung gestartet werden, und kann die Ausf\u00fchrung beliebigen Codes mit Root-Rechten durch das Starten eines beliebigen SUID-Programms, das dynamisches Linking verwendet, erreichen. <\/p>\n
Mit Root-Zugriff in der \u00fcber AppArmor isolierten Sandbox-Umgebung und einem auf seccomp basierenden Systemaufruffilter kann der Angreifer \/bin\/bash in das Verzeichnis \/var\/snap\/$SNAP\/common kopieren und die Berechtigungen auf \u201e04755\u201c (suid root) setzen. Obwohl die Berechtigungen innerhalb der Sandbox-Umgebung ge\u00e4ndert wurden, ist die Datei mit den ge\u00e4nderten Berechtigungen auch im Hauptsystem verf\u00fcgbar, sodass es ausreicht, \/var\/snap\/\/common\/bash als normaler unprivilegierter Benutzer aus der regul\u00e4ren Systemumgebung auszuf\u00fchren, um vollst\u00e4ndigen Root-Zugriff zu erhalten. <\/p>\n
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\u00f6glicht es einem unprivilegierten Benutzer, root-Rechte im System zu erlangen. Das Problem wurde w\u00e4hrend der \u00dcberpr\u00fcfung von \u00c4nderungen 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\u00e4\u00dfig behoben. Im Paket uutils wurde das Problem in der Version uutils coreutils 0.3.0 behoben, ohne dass dies in den \u00c4nderungsprotokollen 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). <\/p>\n
Das Problem wird durch einen Rennzustand im Befehl \u201erm\u201c verursacht, der es einem lokalen Benutzer erm\u00f6glicht, den Inhalt eines Verzeichnisses w\u00e4hrend der L\u00f6schung einer vom Benutzer kontrollierten Datei durch den \u201erm\u201c-Prozess mit Root-Rechten auf einen symbolischen Link zu \u00e4ndern. Unter anderem kann die Vulnerabilit\u00e4t aus einem t\u00e4glichen Job in der cron-Skripting-Umgebung \/etc\/cron.daily\/apport ausgenutzt werden, der mit Root-Rechten l\u00e4uft und rekursiv den Inhalt des Verzeichnisses \/var\/crash l\u00f6scht, das f\u00fcr alle Benutzer im System beschreibbar ist. <\/p>\n