Güvenlik araştırmacısı Thomas Ptacek, VSCode'un Remote-SSH agent'ını ve geniş host erişimini sorguluyor

VSCode uzak bir host'a gerçekte ne kuruyor

VSCode ile SSH üzerinden uzak bir makine açtığınızda, editör mevcut oturumunuz üzerinden komut çalıştırmaktan çok daha fazlasını yapar. Fly.io blogunda yazan ve yazısı Hacker News ana sayfasına çıkan güvenlik araştırmacısı Thomas Ptacek'e göre Remote-SSH özelliği, hedef host'ta küçük bir Bash stager çalıştırarak başlıyor. Bu stager, yanında paketlenmiş binary Node.js kurulumu da içeren tam bir agent indiriyor; agent daha sonra VSCode pencerenize geri doğru bir WebSockets bağlantısı açıyor ve bu bağlantı port-forward edilmiş SSH üzerinden taşınıyor.

İlgili kaynak kodu olduğunu düşündüğü yere işaret eden Ptacek, bu bağlantı üzerindeki protokolün neler yapabileceğini sıralıyor: uzak dosya sisteminde gezinmek, rastgele dosyaları düzenlemek, pseudo-terminal üzerinde kendi shell süreçlerini başlatmak ve makine üzerinde kalıcı hale gelmek. Güvenlik sektörünün, dikkat çektiğine göre, tam olarak bu yetenek profiline sahip araçlar için standart bir adı var. Ptacek bunu açıkça söylemek yerine şaka yollu bu terimin "murid" olduğunu söylüyor — sıçanları da içeren kemirgen familyasına bir gönderme ve RAT, yani remote access trojan'a pek de incelikli olmayan bir ima.

Emacs Tramp ile karşıtlık

Ptacek yazıyı, uzun süredir var olan Emacs uzak düzenleme eklentisi Tramp ile bir karşılaştırmaya oturtuyor. Tramp, Emacs'ı Bourne shell komutları verebildiği interaktif bir oturumla (genellikle SSH üzerinden) erişilebilen herhangi bir host'a genişletebilir; bağlantının kendisinin sunduğuyla çalışır. VSCode ters yaklaşımı benimsiyor: boru hattından shell komutları göndermek yerine, kendi runtime'ı olan kalıcı bir servis kuruyor.

Ptacek'ın huzursuzluğu bu tasarımdan kaynaklanıyor. Her yere dosya yazabilen, süreç başlatabilen ve kurulu halde kalabilen kalıcı bir bileşen, bağlantıyı kestiğinizde sona eren bir shell oturumundan bambaşka bir şeydir.

Fly.io bunlara neden bakıyordu

Yazı pratik bir çalışmadan doğdu. Fly.io, hızlı başlayan Linux makinelerinin, VSCode kullanıcılarının — ve giderek artan biçimde LLM odaklı VSCode fork'larının kullanıcılarının — halihazırda içinde bulunduğu uzak düzenleme akışına bağlanmasını istiyor. Ptacek'ın savunusu şu: LLM kodlama agent'ları, üretilen kodun çalıştırıldığı ve ortaya çıkan hataların yeni bir tur için geri beslendiği kapalı bir döngüde en etkili şekilde çalışır.

Bu döngünün, o iddiasına göre, bir geliştiricinin dizüstü bilgisayarında çalışmaması gerekir; çünkü bir agent, kendisi yalnızca ele aldığı projeyle sınırlı kalmak yerine üzerinde yaşadığı makineyi memnuniyetle yeniden yapılandırır. Tek kullanımlık bir uzak instance daha güvenli bir ortamdır. Özellikle ekip, standart agent mekanizmasını hiç devreye sokmadan VSCode'u bir Fly makinesine bağlayabildiklerini fark etmişti ve yazı, araştırma sırasında ekibin öğrendiklerini aktarma amacıyla çerçevelenmiş durumda.

Neden önemli

Paylaşımlı geliştirme sunucularını yöneten herkes için Ptacek'ın değerlendirmesi net: böyle host'larda insanların VSCode uzak düzenlemesini kullanması konusunda huzursuz olurdu; bir olayın ortasında bir üretim sistemine karşı kullanılsaydı çok daha kızardı. Kaygı niyetten çok yetenekle ilgili — rastgele dosya yazma, süreç başlatma ve kalıcılığa sahip, tanımadığınız bir bileşen, tam olarak bir kesinti sırasında haber vermeden gelmesini istemeyeceğiniz şeydir.

Yazı ayrıca birçok geliştiricinin zihnindeki model için faydalı bir düzeltme. "Uzak düzenleme" kulağa SSH üzerinde ince bir shell gibi geliyor; VSCode durumunda ise geniş erişimi olan kurulu bir servis. Bu bilgi, bir editörün bağlandığı herhangi bir makine için ekiplerin kimlik bilgilerini, ağ erişimini ve host politikalarını nasıl kapsamlandıracağını şekillendirmeli — özellikle de agentic kodlama araçları giderek aynı uzak yolun üzerinde ilerlerken.

Belirtmek gerekir ki yazı, bir güvenlik açığı raporu değil bir araştırmacının tasarım hakkındaki betimlemesi ve kaynak materyalde satıcı yanıtının yer almadığı görülüyor. Ptacek'ın kendi çerçevesi şöyle: Bunların hiçbiri sonuçta Fly.io entegrasyonunu engellememiş; yayınlama amacı sadece ekibin bunu öğrenmek zorunda kalmasıydı ve şimdi okuyucular da öğreniyor.