Tailscale behebt SSH-Schwachstellen, die Root-Zugriff über Socket-Weiterleitung ermöglichen

Tailscale hat Version 1.104.4 veröffentlicht, um schwerwiegende Sicherheitslücken im integrierten SSH-Server zu beheben, die es Angreifern ermöglichen könnten, ihre Berechtigungen auf Zielrechnern bis zum Root-Niveau auszuweiten. Die Schwachstellen, die in einem Bericht von Erica Windisch von Cyberdione Labs offengelegt wurden, betreffen die Handhabung der Netzwerkverbindungsweiterleitung durch den Dienst und wurden nur wenige Tage nach ihrer öffentlichen Bekanntmachung gepatcht.

Was passiert ist

Das Kernproblem liegt in der Handhabung der Unix-Socket-Weiterleitung durch den Tailscale-SSH-Server. Wenn ein Benutzer eine SSH-Sitzung etabliert, führt der Tailscale-Hintergrundprozess die Weiterleitungsoperation mit Root-Rechten aus. Obwohl das System den Pfad des zugriffsrelevanten Sockets überprüft, ermöglichte eine zeitliche Schwachstelle (Race Condition) Angreifern, den Pfad nach der Überprüfung, aber vor der Herstellung der Verbindung auszutauschen. Diese Wettlaufsitze umging effektiv Schutzmechanismen, die den Zugriff auf sensible System-Sockets einschränken sollten.

In Labortests demonstrierte Windisch, dass ein Angreifer, der bereits ein Gerät kontrolliert, das durch die Netzwerkrichtlinie zugelassen ist, Verbindungen zum Docker-Kontrollsocket oder zur lokalen tailscaled-API weiterleiten konnte. Dieser Zugriff gewährte eine Root-Shell und die Möglichkeit, sensible Dateien wie /etc/shadow ohne Administrator-Anmeldedaten zu lesen. Der Angriff erfordert keine gestohlenen Passwörter oder Schlüssel, sondern lediglich einen Fußpunkt auf einem vertrauenswürdigen Gerät innerhalb des Tailscale-Netzwerks.

Tailscale stellte klar, dass diese Fehler keinen unauthentifizierten Angreifern erlauben, sich mit beliebigen Servern zu verbinden. Der Zugriff wird weiterhin durch die Richtliniendatei des Netzwerks geregelt, was bedeutet, dass ein Angreifer nur Maschinen erreichen kann, zu denen er bereits autorisiert ist. Sobald jedoch eine zulässige Sitzung aktiv ist, ermöglicht die Privilegieneskalation die laterale Bewegung zu Diensten, die nur für Root-Benutzer zugänglich sind. Das Unternehmen beschrieb die Probleme als ernsthafte Sicherheitsrisiken, lehnte jedoch die Charakterisierung des Exploits als selbstreplizierenden Wurm ab und wies darauf hin, dass dieser auf bestehenden Richtlinienberechtigungen basiert und nicht auf autonomer Verbreitung.

Wie es funktioniert

Die Schwachstelle nutzt den Unterschied zwischen Berechtigungsprüfung und Ausführungskontext aus. Zuvor überprüfte der Tailscale-Prozess den Socket-Pfad und führte die Weiterleitungsoperation dann als Root aus. Durch das Austauschen des Socket-Pfads während dieses Zeitfensters konnte ein Angreifer das System dazu bringen, sich mit einem privilegierten Socket anstelle des beabsichtigten zu verbinden. Der Fix in Version 1.104.4 ändert dieses Verhalten so, dass die Weiterleitung als angemeldeter Benutzer und nicht als Root durchgeführt wird. Zudem verlagert sich die Abhängigkeit von internen Pfadprüfungen auf die nativen Dateiberechtigungen des Betriebssystems, die robuster gegen solche Race Conditions sind.

Diese Änderung adressiert spezifisch das Bulletin TS-2026-014, welches die Socket-Weiterleitungsfehler abdeckt. Das Update behebt auch drei weitere Probleme: einen Speichererschöpfungsfehler, der den Tailscale-Prozess zum Absturz bringen könnte (TS-2026-015), einen Fehler in der tailscale serve-Funktion, der die Fernsteuerung von Knoten über Unix-Sockets ermöglichte (TS-2026-016), sowie ein Header-Leckage-Problem in TLS serve-Konfigurationen (TS-2026-017). Der Tailscale-SSH-Server läuft unter Linux und dem Open-Source-macOS-Build, obwohl das angreifende Gerät jede Plattform sein kann.

Wichtige Details

• Betroffene Versionen: Die älteste betroffene Version ist nicht spezifiziert, aber Version 1.104.4 enthält die Fixes.
• Voraussetzungen: Angreifer müssen bereits ein Gerät kontrollieren, das durch die Netzwerkrichtlinie vertraut ist und bei dem die SSH-Weiterleitung aktiviert ist.
• Auswirkung: Eine erfolgreiche Ausnutzung gewährt Zugriff auf Root-only-Sockets, wie das Docker-Socket oder die lokale tailscaled-API.
• Headscale-Nutzer: Der selbst gehostete headscale-Control-Server (Version 0.29.5) behebt diese Probleme noch nicht, und die SSH-Weiterleitung kann in seiner Richtlinie nicht deaktiviert werden.
• Offenlegung: Der Bericht wurde ohne vorherige Koordination veröffentlicht; Tailscale erhielt ihn zwei Stunden vor der öffentlichen Freigabe.
• Keine CVEs: Zum Zeitpunkt der Veröffentlichung haben die vier Sicherheitsbulletins keine zugewiesenen CVE-Identifier oder Schweregradbewertungen.

Warum es wichtig ist

Für Engineering-Teams, die Tailscale für den Infrastrukturzugriff nutzen, hebt dieser Vorfall die Risiken impliziten Vertrauens in Geräteidentitätsmodelle hervor. Da Tailscale SSH Geräteidentitäten anstelle von Passwörtern verwendet, kann die Kompromittierung eines einzelnen vertrauenswürdigen Geräts einen Weg zu kritischen Systemen bieten, wenn die Weiterleitung aktiviert ist. Die Geschwindigkeit, mit der der Exploit lateral wandern kann – unter einer Sekunde pro Schritt in Tests – bedeutet, dass Erkennungs- und Reaktionszeiten extrem schnell sein müssen, um eine weitreichende Kompromittierung zu verhindern.

Die Situation ist besonders herausfordernd für Nutzer von headscale, der Open-Source-Alternative zur Tailscale-Control-Plane. Da headscale derzeit nicht die Möglichkeit bietet, die SSH-Weiterleitung in der Richtlinie zu deaktivieren, und noch keinen Fix veröffentlicht hat, müssen Administratoren, die dieses Setup verwenden, jede SSH-Gewährung als potenzielle Gewährung von Root-Zugriff betrachten. Dies unterstreicht die Bedeutung, die Unterschiede zwischen verwalteten Diensten und selbst gehosteten Alternativen bei der Bewertung der Sicherheitslage zu verstehen.

Was Sie tun können

• Aktualisieren Sie alle Tailscale-Clients und -Server sofort auf Version 1.104.4 oder höher.
• Falls ein Update nicht möglich ist, setzen Sie TS_SSH_DISABLE_FORWARDING=1 in der tailscaled-Dienstumgebung, um die Weiterleitung zu blockieren.
• Überprüfen Sie die SSH-Zugangsregeln, um sicherzustellen, dass nur notwendige Geräte und Benutzer Berechtigungen zum Verbinden haben.
• Aktivieren Sie den SSH-Check-Modus für sensible Systeme, um vor Sitzungsbeginn eine erneute Authentifizierung zu verlangen.
• Für headscale-Nutzer: Beschränken Sie SSH-Gewährungen aggressiv und überwachen Sie auf unbefugte Root-Level-Aktivitäten.
• Reimaging und Löschen kompromittierter Geräte aus der Control Plane, wenn Sie einen Einbruch vermuten, da alleiniges Reimaging die Geräteschlüssel nicht widerruft.