Tailscale schließt Root-Lücken im eingebauten SSH-Server

Die Lücken gehen auf einen Bericht mit dem Namen „Tailworm" zurück, den Erica Windisch von Cyberdione Labs wenige Tage vor dem Fix veröffentlichte. Sie untersuchte dafür freigegebene Versionen des Tailscale-Clients sowie den selbst betriebenen Steuerserver headscale in einer Laborumgebung.

Tailscale SSH entscheidet anhand der Geräteidentität und der Policy-Datei des Netzwerks, wer sich verbinden darf – nicht anhand von Passwort oder Schlüssel. Ein Angreifer benötigt deshalb keine gestohlenen Zugangsdaten, sondern lediglich einen Fuß in der Tür auf einem Gerät, dem die Policy ohnehin vertraut. Die Schwachstellen erlaubten es „einem nicht authentifizierten Angreifer nicht, sich mit beliebigen Tailscale-SSH-Servern zu verbinden", erklärte Tailscale; erreichbar bleiben nur die Maschinen, die die Policy-Datei bereits zulässt. Der SSH-Server von Tailscale läuft ausschließlich unter Linux und im quelloffenen macOS-Build; das Gerät des Angreifers kann dagegen auf jeder Plattform laufen.

Der Kern des Problems liegt in der Socket-Weiterleitung. Leitete eine zulässige SSH-Sitzung eine Verbindung an einen Unix-Socket auf dem Server weiter, prüfte der Tailscale-Prozess zwar den Pfad, arbeitete anschließend aber als Root. Über einen Timing-Trick ließ sich nach dieser Prüfung ein anderer Pfad unterschieben – die Schutzmaßnahme, die die erreichbaren Sockets begrenzen sollte, wurde damit ausgehebelt. In Windischs eigenen Tests führte die Weiterleitung an den Docker-Steuersocket zu einer Root-Shell und erlaubte das Auslesen der Systempasswortdatei /etc/shadow, ganz ohne Administratorrechte. Tailscale beschreibt die Reichweite in seinem Bulletin enger: Ein Angreifer könne Root-exklusive Sockets wie den Docker-Socket oder die lokale API von tailscaled erreichen.

In 1.104.4 führt der Server die Weiterleitung nun als der angemeldete Nutzer statt als Root aus und verlässt sich auf die Dateirechte des Betriebssystems anstelle der bisherigen Pfadprüfung. Die Freigabe umfasst vier Sicherheitsbulletins:

• TS-2026-014: die beschriebenen Fehler bei der SSH-Socket-Weiterleitung, über die eine zugelassene Sitzung Root-exklusive Sockets wie den Docker-Socket oder die lokale tailscaled-API erreichen konnte.
• TS-2026-015: eine Möglichkeit, über eine zugelassene SSH-Sitzung den Arbeitsspeicher eines Servers zu erschöpfen und den Tailscale-Prozess zum Absturz zu bringen, wodurch die gesamte Tailscale-Vernetzung dieses Knotens ausfällt.
• TS-2026-016: eine Lücke in tailscale serve, bei der eine Weiterleitung an einen Unix-Socket die lokale tailscaled-API erreichen und damit die Fernsteuerung des Knotens ermöglichen konnte, dazu ein verwandtes Socket-Austauschproblem.
• TS-2026-017: ein Fehler, bei dem mit TLS-serve und zwei oder mehr Mounts eine Anfrage die Berechtigungs-Header eines anderen Mounts erhalten konnte.

Nutzer von Tailscale SSH sollten auf Version 1.104.4 oder neuer aktualisieren. Lässt sich ein Server noch nicht aktualisieren, kann die SSH-Weiterleitung dort abgeschaltet werden, indem in der Dienstumgebung von tailscaled TS_SSH_DISABLE_FORWARDING=1 gesetzt und der Dienst neu gestartet wird. Nach Angaben von Tailscale schaltet das die Weiterleitung ab, ohne Tailscale SSH insgesamt zu deaktivieren, und blockiert mehrere der schwerwiegenderen Befunde. Zusätzlich empfiehlt das Unternehmen, die SSH-Zugriffsregeln zu überprüfen, damit nur die Nutzer und Geräte Zugang haben, die ihn benötigen. Für sensible Systeme rät Tailscale zum SSH-Check-Modus, der eine erneute Anmeldung vor Sitzungsbeginn verlangt. Gegen die Weiterleitungsfehler hilft er allerdings nicht: Er sichert den Start einer Sitzung ab, während die Weiterleitung innerhalb einer bereits genehmigten Sitzung stattfindet.

Besteht der Verdacht, dass ein Server bereits kompromittiert wurde, genügt der Fix allein laut Windischs Bericht nicht. Ein entwendeter Geräteschlüssel bleibt gültig, bis das Gerät in der Steuerungsebene gelöscht wird – ein Neuaufsetzen der Maschine widerruft ihn nicht. Tailscales Hinweise gehen auf diesen Fall nicht ein.

Schlechter sieht es bei headscale aus, dem selbst betriebenen Steuerserver. Dort wird SSH-Weiterleitung bei jeder akzeptierten Sitzung gewährt und lässt sich in der Policy nicht abschalten. Jede SSH-Berechtigung dort sei deshalb als Root-Zugriff zu behandeln, heißt es in Windischs Bericht. Die jüngste headscale-Version 0.29.5 vom 13. Oktober behebt die gemeldeten Probleme nicht.

Windisch bezeichnete die Angriffskette als „wurmfähig". In ihren Tests konnte sich ein kompromittiertes Gerät auf jedes von der Policy erlaubte Gerät ausbreiten – ohne Passwörter, ohne gestohlene Schlüssel, ohne Zutun eines Nutzers und in weniger als einer Sekunde pro Schritt. Zwei Maßnahmen stoppten die Ausbreitung in diesen Tests: Zugriffsregeln, die als einzelne Gerät-zu-Gerät-Paare formuliert sind, sowie die Bindung von Geräteschlüsseln an Hardware wie ein TPM, die die Wiederverwendung einer gestohlenen Identität an anderer Stelle verhinderte.

Tailscale weist die Wurm-Beschreibung zurück. Die Befunde beschrieben keine sich selbst replizierende Schadsoftware, die sich eigenständig zwischen Maschinen ausbreite, so das Unternehmen, sondern laterale Bewegung, begrenzt auf die von einer Policy-Datei ohnehin erlaubten Verbindungen. Die Rechteausweitungsprobleme nannte Tailscale „ernste Sicherheitsprobleme", erklärte, die wichtigsten reproduziert zu haben, und arbeite noch daran zu bestimmen, welche Konfigurationen betroffen sind.

Zum Zeitpunkt der Veröffentlichung tragen die vier Bulletins weder CVE-Kennungen noch Schweregrade, und keines nennt die älteste betroffene Version. Der Bericht behandelte zudem Tailscales App-Connectors sowie die Funktionen serve und funnel. Der App-Connector-Befund betrifft nach Angaben von Tailscale conn25, eine experimentelle und nicht freigegebene Funktion; die heute von Kunden genutzten Connectors seien nicht betroffen. Von fünf Befunden zu serve und funnel behob das Unternehmen drei, die übrigen zwei funktionierten wie vorgesehen.

Windisch veröffentlichte den Bericht, ohne die Freigabe vorab mit Tailscale abzustimmen – sie beschreibt das als „gemeldet, aber nicht koordiniert". Tailscale erklärte, den Bericht am Morgen von Samstag, dem 24. Oktober, etwa zwei Stunden vor der Veröffentlichung erhalten zu haben; die eigenen Entwickler hätten sich bereits mit denselben Codeteilen befasst.

Weder Tailscale noch der Bericht geben an, dass die Lücken in realen Angriffen genutzt wurden. Der Proof-of-Concept-Code ist nicht öffentlich; Windisch gab ihn nach eigenen Angaben nur an Tailscales Sicherheitsteam weiter. Es ist nicht der erste Fix in diesem Codebereich in diesem Jahr: Im Juni behob Tailscale in Version 1.98.9 eine andere Lücke in der Unix-Socket-Weiterleitung von Tailscale SSH, über die ein unprivilegierter Nutzer einen privilegierten Socket erreichen konnte.