Tailscale, v1.104.4'te root düzeyinde erişime izin veren dört Tailworm SSH ve Serve açığını kapatıyor

Tailscale, 28 Ekim'de 1.104.4 sürümünü yayımlayarak "Tailworm" adı altında açıklanan ve TS-2026-014 ile TS-2026-017 arasındaki güvenlik bültenlerinde belgelenen dört açığı kapattı. Tüm bültenlerin incelendiği bir dev.to analizine göre üç hatanın kök nedeni ortak: tailscaled root olarak çalışıyor, izinleri bağlanan kullanıcıymış gibi denetliyor ve ardından root yetkisiyle hareket ediyordu.

Zaman çizelgesi oldukça sıkışıktı. Tailscale SSH ile ilgili endişeler 23 Ekim'de dolaşıma girdi ve dış uzmanlarla birlikte bir inceleme başlatıldı; araştırmacı raporunu 24 Ekim Cumartesi sabahı teslim etti ve iki saat sonra yayımladı. Tailscale 26 Ekim'de geçici azaltıcı önlemleri paylaştı; ardından Mike Shaver'ın kaleme aldığı bulgular yazısı ve 28 Ekim'de dört bülten geldi. dev.to yazarı, v1.104.4'ün aynı gün 01:05 UTC'de çıktığını GitHub üzerinde doğruladı.

Root düzeyinde socket yönlendirme (TS-2026-014)

En ciddi bülten, Tailscale SSH'nin TCP ve Unix socket yönlendirmesiyle ilgili. SSH sunucusu root olarak çalışan tailscaled içinde çalışıyor ve Unix socket yollarını sözcüksel olarak — yani yol dizgesini inceleyerek — doğruluyordu; ardından işlemi root olarak gerçekleştiriyordu. Bülten üç sonucu sıralıyor: yerel yönlendirme (ssh -L) üzerinden ayrıcalıklı bağlantılarla yerel kullanıcının asla erişemeyeceği socketlere ulaşılması; uzak yönlendirme (ssh -R) yoluyla socket değiştirilmesi, yani root'a ait socketlerin silinip yerlerine başkalarının bağlanması; ve çekirdeğin doğrulamadan sonra yolu yeniden çözümlemesiyle ortaya çıkan bir yarış koşulu — denetlenen yol, kullanılan yol olmayabiliyor. Bülten, Docker socketini ve tailscaled yerel API socketini önem taşıyan hedefler olarak adlandırıyor; ikisinden biri makinenin tamamen ele geçirilmesi anlamına geliyor. Daha katı bir denetim yerine çözüm mimari: yönlendirme artık root yerine kimliği doğrulanmış kullanıcı adına yapılıyor.

Serve açıkları (TS-2026-016)

tailnet bağlantılarını yerel Unix socket arka uçlarına proxy'leyen tailscale serve iki zayıflık barındırıyordu. Unix socketlere yapılan TCP yönlendirmelerinde hiçbir koruma yoktu ve hedefe root olarak bağlanılıyordu; bu da daemon'un kendi izinleriyle yerel API socketine ham baytların beslenmesine izin veriyordu — bültenin "makinenin tamamen ele geçirilmesi" olarak nitelediği bir etki. Bunun yanı sıra HTTP proxy'leri için symlink denetimi her bağlantı kuruluşunda değil yalnızca yapılandırma yeniden yüklendiğinde yapılıyordu; bu nedenle yeniden yüklemeden sonra zararsız bir arka uç yolunun bir symlink ile değiştirilmesi koruyucuyu tamamen atlatıyordu. Düzeltmeler TCP yönlendirmelerini tailscaled socketiyle sınırlıyor ve arka uç hedefini her bağlantı kuruluşunda yeniden doğruluyor.

Bellek tükenmesi ve yetenek sızıntıları

TS-2026-015 bir hizmet reddi sorunu. Kimliği doğrulanmış bir eş, bir oturum içinde sürekli pencere boyutu değişikliği mesajları ve ortam değişkeni ekleme istekleri göndererek tailscaled'de sınırsız bellek büyümesine yol açabiliyordu; ayrılan bellek eş bağlantıyı kestikten sonra da kalıyordu. Sürekli baskı halinde OOM killer tailscaled'i sonlandırabiliyor ve daemon düğümün tüm ağ durumunu taşıdığı için o düğümdeki tüm Tailscale bağlantıları da onunla birlikte düşüyordu. Oturum belleği artık sınırlı ve bağlantı kesildiğinde serbest bırakılıyor.

TS-2026-017, Serve'in HTTP/2 üzerindeki eşzamanlılık açısından bir hata. Bir bağlantıdaki tüm akışlar tek bir serveHTTPContext paylaşıyordu: handler her istek için AppCapabilities yazarken reverse proxy bunları paylaşılan bir hook üzerinden okuyordu; böylece bir mount'un yetenekleri başka bir isteğe sızabiliyordu. Eşleri Tailscale-App-Capabilities değerini inceleyerek yetkilendiren uygulamalar — dev.to yazısının belirttiğine göre bu, belgelenmiş yaklaşım — bu kararı başka bir uygulamanın yeteneklerine dayanarak verebiliyordu. Yetenekler artık istek başına bir bağlamdan türetiliyor.

Orijinal araştırmacı raporu, Serve ve Funnel için beş bulgu daha içeriyordu: üçü gerçek hataydı ve 1.104.4'te düzeltildi, ikisi ise tasarlandığı gibi çalışan davranışları tarif ediyordu. Yayımlanmamış Conn25 uygulama bağlayıcılarındaki altıncı bulgu Tailscale tarafından zaten biliniyordu; stabil bağlayıcılar etkilenmiyor.

Kapsam ve sınırlar

Hem Tailscale hem de dev.to analizinin vurguladığı gibi, dört sorunun hiçbirine kimliği doğrulanmamış bir saldırgan erişemiyor. Sömürü için yetkili bir eş üzerinde bir kalıcılık noktası, politikanın zaten izin verdiği SSH erişimi ve yönlendirmenin etkin olması ya da Serve'in Unix arka uçlarla yapılandırılmış olması gibi belirli koşullar gerekiyor. Adına rağmen "Tailworm" bir solucan değil: kendini kopyalama yok, yalnızca politikanın zaten izin verdiği bağlantılar boyunca yatay hareket var; hedef makinedeki ayrıcalık sınırı ise yanlış çizilmiş durumda.

Neden önemli

Tailscale SSH'nin kullanıcı başına eşlemesinin dayandığı önkabul, tek bir kimlikle kabul edilen bir eşin başka birinin ayrıcalıklarını kazanamayacağıdır ve bu hatalar tam da o sözü bozdu. Ortadaki örüntü geniş biçimde öğretici: ayrıcalıklı bir daemon özenle doğrulama yapıyor, sonra kullanıcının hiç sahip olmadığı ortam yetkisiyle hareket ediyor. Taklit edilmeye değer olan kısım Tailscale'in tepkisi — düzeltmeler doğrulama eklemek yerine ayrıcalığı bırakıyor: kullanıcı adına yönlendirme, bağlantı anında yeniden doğrulama ve istek başına yetenek izleme.

Ne yapmalı

v1.104.4 veya daha yeni bir sürüme geçin; dört bültenin tamamı bu yönergeyle kapanıyor. Hemen güncelleme yapamayan ama Tailscale SSH'ye bağımlı operatörler, tailscaled servis ortamında TS_SSH_DISABLE_FORWARDING=1 ayarlayıp servisi yeniden başlatarak yönlendirmeyi — ve TS-2026-014'ün root'a giden yolunu — SSH'yi tamamen kapatmadan devre dışı bırakabilir. dev.to yazısı ayrıca politika dosyasının SSH bölümünü gözden geçirmeyi öneriyor; bu hataların her biri ayakta kalabilmek için politika izniyle kurulmuş bir bağlantıya ihtiyaç duyuyordu.