Büyük dil modelleri (LLM'ler) üzerine uygulama geliştiren her ekip, eninde sonunda aynı özelliği ekler: çalışma alanları (workspaces). Kiracı, ekip, proje, organizasyon... adı ne olursa olsun, vaat aynıdır: sizin bilgi tabanınız, sohbet geçmişiniz, belgeleriniz, aynı örnek üzerindeki diğer herkesten ayrılmış duvarlarla korunur. İşte bu duvar, çok kiracılı (multi-tenant) bir ürünün asla yanlış yapmaması gereken tek şeydir. Son birkaç aydır, sistematik olarak bu duvarın nerede çatladığını aradım.
200'den fazla çok kiracılı AI ve SaaS ürününün kaynak kodlarını belirli bir hata sınıfı için inceledim ve 78'inde kiracılar arası veri sızıntısını doğruladım: bir kiracının, diğer bir kiracının verilerini okuyabildiği (ve bazı durumlarda değiştirebildiği veya silebildiği) tespit edildi. Bu, 78 üründe toplam 84 bulguya karşılık geliyor ve bunların 31'i GitHub Güvenlik Danışmanlığı (Security Advisory) olarak dosyalandı. Neredeyse tamamı aynı hatayı içeriyor ve bu hata, okuma uç noktalarında (read endpoints) yaşıyor.
Bu yazı, söz konusu hatayı, düzeltilmiş olanları ve geri kalanların güncel listesini açıklıyor. Henüz ismi verilmeyenler, düzeltme yayınlanana kadar bu şekilde kalacak. Kullanıcılar korunmadan saldırganlara canlı bir hedef vermeyeceğim.
Uzmanların Görüşleri
Test yöntemim iki aşamalıydı. İlk aşamada 200'den fazla ürünü taradım: her aday için, yazma yolunda (write path) uygulanan ancak komşu okuma yolunda (read path) atlanan bir yetkilendirme kontrolü aradım. Çoğu ürün ya bu hataya sahip değil, ya açık kaynak sürümünde gerçekten çok kiracılı değil ya da tüm kardeş uç noktaları çoktan düzeltmiş. Bunlar çoğunluğu oluşturuyor ve 78'in anlamlı olmasını sağlayan payda bunlar. İkinci aşamada, kaynak taraması gerçek bir açık tespit ettiğinde, bunu doğruladım: Kendi donanımımda Docker ile temiz bir örnek kurdum, iki kiracı (A ve B) oluşturdum, sentetik hesaplar ve kanarya verileri (canary data) ekledim. Sectum AI adlı açık kaynaklı bir çok kiracılı izolasyon doğrulayıcı kullanarak kiracılar arası okuma, değiştirme veya silme işlemini yeniden ürettim ve veritabanı gerçekliğine karşı doğruladım. Ardından imzalı bir kanıt paketi hazırlayıp koordineli ifşa (90 günlük bekleme) kapsamında özel olarak bakım ekibine bildirdim.
Sistem Güvenliği
Desen neredeyse mekanikti: yazma yolu doğru bir şekilde kiracıya kapsamlandırılmışken, hemen yanındaki okuma yolu kapsamlandırılmamıştı. Geliştirici 'bu öğeyi sil' eklerken sahiplik kontrolünü eklemiş, ancak 'bu öğeyi görüntüle' veya 'bu öğenin gömme vektörlerini listele' gibi okuma uç noktalarında kontrolü kopyalamayı unutmuş. Liste/get/search uç noktası, ham bir ID ile kiracı filtresi olmadan veri çekiyor. ID'ler genellikle ardışık tamsayılar veya tahmin edilebilir olduğundan, 'öğe 5'i görüntüle' komutu başka bir kiracının 5. öğesini döndürebiliyor. Bu hatayı 'retrofit edilmemiş okuma kardeşleri' olarak adlandırmaya başladım. Ayrıca daha sinsi bir varyant daha var: kontrol çalışıyor, ancak yanlış şey üzerinde. İşleyici, istediğiniz nesne yerine sağladığınız yolu yetkilendiriyor.
Gelecekte Ne Bekleniyor?
Beş ürün için düzeltme yayınlandı ve kamuya açıklandı. En hızlı hareket eden ekipler şunlar: [burada düzeltilen ürünlerin isimleri yer alacak, ancak metinde belirtilmemiş; benzer bir liste oluşturulabilir: örn. Open WebUI, Langfuse, LibreChat, Outline, PraisonAI]. Ayrıca, birkaç ürün mevcut sürümlerinde izolasyonu başarıyla sağlıyor: Open WebUI, Langfuse, LibreChat, Outline, PraisonAI, Onyx, LangWatch, Khoj. Bunlardan bazıları eski sürümlerde çapraz kiracı CVE'lerine sahipti ancak güncel sürümlerde temiz. Açık kaynak sürümünde çok kiracılı olmayanlar (kurumsal özellik veya paylaşılan tasarım): Flowise, Mem0, MaxKB, vLLM.
AI üzerine inşa ediyorsanız üç önemli çıkarım: 1) Okumaları, yazmaları yetkilendirdiğiniz gibi yetkilendirin. Liste/get/search uç noktası 'düşük riskli' değildir; veri sızdırma uç noktasıdır. Bir sahiplik kontrolü eklediğinizde, aynı nesneye dokunan tüm kardeş uç noktaları grep ile bulun ve aynı kontrolü ekleyin. Daha iyisi, kiracı kapsamlandırmasını işleyicinin unutamayacağı bir katmanda (sorgu önleme, satır düzeyi politika, ara katman) zorunlu kılın. 2) Gömme vektörlerini (embeddings) ve önbellek anahtarlarını kiracı verisi olarak ele alın. Bazı sızıntılar belge değil, RAG vektörleri ve yanıt önbellekleriydi; anahtarlar kiracıyı içermiyordu. 3) Aynı hatayı 84 kez görmek, bunun bir tasarım kusuru olduğunu gösteriyor. 'Önce yazma yolunu, sonra okumayı düşünürüm' yaklaşımı başarısız oluyor. İzolasyonu en baştan, her uç nokta için varsayılan olarak tasarlayın.
Nasıl Önlem Alınmalı?
Bu çalışma, çok kiracılı AI ürünlerinde yaygın bir güvenlik açığı desenini ortaya koyuyor. Kendi kendine barındırılan (self-hosted) AI araçları kullanıyorsanız, kiracı izolasyonunuzu kontrol etmeniz kritik önem taşıyor. Sectum.ai/research adresinde güncel liste ve danışmanlıklar yayınlanıyor. Unutmayın: duvar, yalnızca yazma işlemlerinde değil, okuma işlemlerinde de sağlam olmalıdır.
Kaynak: dev.to
