‘Dirty Sock’-Fehler in Snapd ermöglicht Root-Zugriff auf Linux-Server

Das Problem betrifft Standardinstallationen von Ubuntu-Server und -Desktop und ist wahrscheinlich in vielen Ubuntu-ähnlichen Linux-Distributionen enthalten.

Es wurde eine lokale Privilegien-Eskalationsanfälligkeit im Canonical-Paket snapd aufgedeckt, die es jedem Benutzer ermöglicht, Administratorrechte und sofortigen Root-Zugriff auf betroffene Linux-Systemserver zu erhalten.

Snapd wird von Linux-Benutzern zum Herunterladen und Installieren von Anwendungen im .snap-Dateiformat verwendet. Chris Moberly von Missing Link Security fand das Problem (CVE-2019-7304) und sagte, dass es in der Snapd-API liegt. Diese ist in Ubuntu standardmäßig installiert; Moberly sagte in seinem Fehlerbericht, dass seine Proof-of-Concept-Ausnutzungen "100% der Zeit bei frischen, standardmäßigen Installationen von Ubuntu-Server und -Desktop" funktionieren. Er bemerkte auch, dass der Fehler "wahrscheinlich in vielen Ubuntu-ähnlichen Linux-Distributionen enthalten ist".

In Anlehnung an die bekannte "Dirty Cow"-Schwachstelle nannte Moberly das Thema "Dirty Sock", da es sich um den Umgang mit Steckdosen dreht.

"Die Snapd-Versionen 2.28 bis 2.37 haben die Adresse des entfernten Sockels falsch validiert und geparst, wenn sie Zugriffskontrollen auf seinen UNIX-Socket durchführten", erklärte Canonical in seinem Ubuntu-Beratungsbericht, der Patches für betroffene Pakete bereitstellt. "Ein lokaler Angreifer könnte dies nutzen, um auf privilegierte Socket-APIs zuzugreifen und Administrator-Rechte zu erhalten.

Nüchtern ausgearbeitet in einem Blog-Post, der die technischen Details des Themas erklärt. "snapd bedient eine REST-API, die an einen lokalen UNIX_AF-Socket angeschlossen ist. Die Zugriffskontrolle auf eingeschränkte API-Funktionen erfolgt durch die Abfrage der UID, die mit allen Verbindungen zu diesem Socket verbunden ist. Vom Benutzer kontrollierte Socket-Peer-Daten können so beeinflusst werden, dass eine UID-Variable während des String-Parsing in einer for-Schleife überschrieben wird. Dies ermöglicht jedem Benutzer den Zugriff auf jede API-Funktion."

Beim Zugriff auf die API gibt es mehrere Methoden, um Root zu erhalten. Für zwei davon hat der Forscher PoCs entwickelt, die die Erstellung von Benutzer-Accounts auf Root-Ebene beinhalten; aber es gibt wahrscheinlich noch viele weitere Ansätze, die man nutzen könnte, stellte er fest.

Die erste, dirty_sockv1, umgeht die Zugriffskontrollprüfungen, um eine eingeschränkte API-Funktion (POST /v2/create-user) des lokalen Snapd-Dienstes zu verwenden. "Dabei wird das Ubuntu-SSO nach einem Benutzernamen und einem öffentlichen SSH-Schlüssel einer angegebenen E-Mail-Adresse abgefragt und dann ein lokaler Benutzer auf der Grundlage dieser Werte erstellt", erklärte Moberly.

Der Nachteil ist, dass für eine erfolgreiche Nutzung eine ausgehende Internetverbindung und ein SSH-Dienst, der über den lokalen Host zugänglich ist, erforderlich ist.

Der zweite, passend benannte dirty_sockv2, umgeht ebenfalls die Zugriffskontrollprüfungen des lokalen Snapd-Dienstes, um eine eingeschränkte API-Funktion zu nutzen, diesmal POST /v2/snaps. "Dies erlaubt die Installation beliebiger Snaps", sagte der Forscher. "Snaps im 'devmode' umgehen die Sandbox und können einen Installationshook enthalten, der zur Installationszeit im Kontext von root ausgeführt wird. dirty_sockv2 nutzt die Verwundbarkeit aus, um einen leeren 'devmode'-Snap zu installieren, der einen Hook enthält, der einen neuen Benutzer zum lokalen System hinzufügt. Dieser Benutzer hat die Berechtigung, sudo-Befehle auszuführen."

Im Gegensatz zu Version 1 erfordert dirty_sockv2 nicht, dass der SSH-Dienst ausgeführt wird. Es funktioniert auch auf neueren Versionen von Ubuntu ohne jegliche Internetverbindung, wodurch es widerstandsfähig gegen Änderungen und effektiv in eingeschränkten Umgebungen ist.

Exploit two ist auch auf Nicht-Ubuntu-Systemen wirksam, die Snapd installiert haben, aber die "Create-User"-API, die der erste Exploit nutzt, nicht unterstützen.

Moberly fand die Schwachstelle im Januar und lobte das snapd-Team, das das Problem schnell behoben hat. "Ich war sehr beeindruckt von Canonicals Antwort auf dieses Problem", sagte er. "Die Zusammenarbeit mit dem Team war großartig, und insgesamt gibt mir die Erfahrung ein sehr gutes Gefühl, selbst ein Ubuntu-Benutzer zu sein", sagte er.

Auf Ubuntu-Systemen, auf denen Snaps installiert sind, hat sich snapd "normalerweise bereits automatisch auf Snapd 2.37.1 aktualisiert, das davon nicht betroffen ist", sagte Canonical. Wie bei anderen Linux-Distributionen, die snapd verwenden, wie Linux Mint, Debian und Fedora, sollten Administratoren überprüfen, ob der Fehler vorhanden ist und entsprechende Patches anwenden.