· kaynak Cloudflare blog
Cloudflare, Containers'taki kiracılar arası veri sızıntısını sıfırlanmamış disk bloklarına dayandırarak kapattı
Bir bug bounty raporu, sıfırlanmamış ince sağlanmalı (thin-provisioned) disk bloklarının Cloudflare Containers müşterilerinin diğer kiracıların kalıntı verilerini okuyabilmesine imkân verdiğini ortaya koydu; açıklık tamamen giderildi ve istismar edildiğine dair belirti yok.

Cloudflare, Cloudflare Containers'ı ve Containers üzerine kurulu Cloudflare Sandboxes ürününü etkileyen kiracılar arası veri ifşası açıklığını tamamen giderdi. Cloudflare bloguna göre bu kusur, 4 Eylül 2026'da Accomplish'ten güvenlik araştırmacısı Oren Yomtov tarafından Cloudflare'nin bug bounty programı üzerinden bildirildi. Açıklık, Workers Paid hesabına sahip bir müşterinin, aynı ana makinede diğer müşterilerin container'larının daha önce kullandığı kalıntı disk bloklarını kurtarabilmesine imkân verebilirdi. Cloudflare, müşteri verilerinin tehlikeye girdiğine dair bir kanıt bulunmadığını belirtiyor.
Depolama kusuru nasıl çalışıyordu
Cloudflare Containers, çok kiracılı altyapıda çalışır; platform iş yüklerini uygun sunuculara otomatik olarak atar, müşteriler temeldeki ana makineyi seçemez. Her container, Linux device mapper thin provisioning (dm-thin) ile gerçeklenen yazılabilir bir root disk alır ve diskin /dev/vdc olarak göründüğü ayrı bir Firecracker sanal makinesinde çalışır.
Thin provisioning, fiziksel depolamayı yalnızca sanal bir disk daha önce eşlenmemiş bir bölgeye yazdığında tahsis eder; etkilenen havuzlar 64 KiB'lik ince blok boyutu kullanıyordu. Bir container'ın ince birimi silindiğinde, fiziksel blokları birden çok müşteri hesabından iş yüklerinin paylaştığı bir havuza geri dönerdi.
Temel yanlış yapılandırma, havuz ayarlarındaki skip_block_zeroing seçeneğiydi. Bu seçenek etkinleştirildiğinde dm-thin, yeni tahsis edilen blokları bir container'a sunmadan önce temizlemiyordu. Bloğun tamamını kapsayan bir yazma işlemi eski içeriğin yerine geçiyordu; ancak daha küçük bir yazma yalnızca yazılan kısmı değiştiriyor, geri kalanı bloğun önceki sahibinden gelen verileri taşıyordu. Eşlenmemiş bir bölgeyi yalnızca okumak, hiçbir şey tahsis etmeden sıfırlar döndürüyordu; bu nedenle kusurun tetiklenmesi için bir yazma işlemi gerekiyordu.
Kavramsal ispat
Cloudflare'nin aktardığına göre araştırmacı, Workers Paid hesabıyla bir container oluşturdu, /dev/vdc konumundaki ham root diski açtı ve bir temel okuma kaydetti. İstismar, daha sonra guest'in ext4 dosya sistemindeki boş alana karşılık gelen her hizalı 64 KiB'lik bölgeye hizalı tek bir 4 KiB blok yazdı. Her yazma işlemi dm-thin'i paylaşılan havuzdan yeni bir fiziksel 64 KiB blok tahsis etmeye zorluyor ama yalnızca 4 KiB'ini üzerine yazıyordu; böylece sonraki bir ham okuma, dokunulmamış 60 KiB'yi inceleyebiliyordu.
Kurtarılan blokları atfetmek için araştırmacılar, dosya sistemi ve inode'a özgü değerleri içeren metadata_csum özelliğiyle etkinleştirilen ext4 dizin bloğu sağlama toplamlarını kullandı. Altı üretim yerleşimi genelinde, test edilebilir 5.614 dizin bloğunun tamamı yabancı dosya sistemlerine aitti ve hiçbiri kendi dosya sistemlerine ait değildi; 2.700 farklı yabancı dizin inode'u tanımlandı. Bilerek oluşturup sildikleri bloklarla yapılan bir kontrol testi, 162 bloğun tamamını doğru şekilde atfetti.
Kalıntı malzeme, dört kıtaya yayılan 22 temel düğümün 20'sinde, 24 yerleşimin 18'inde görüldü; kurtarılan blok türleri arasında dizin yapıları, veritabanı sayfaları ve yapısal olarak eksiksiz SQLite veritabanları yer aldı. Cloudflare, gönderilen materyallerin yalnızca toplam sayılar, ofsetler, boyutlar ve kısaltılmış hash önekleri içerdiğini — üçüncü taraflara ait dosya adları, tanımlayıcılar, kimlik bilgileri, ana makine adları veya kurtarılan içerik değerleri bulunmadığını — ve araştırmacıların kurtarılan verilerin güvenli şekilde silindiğini, HackerOne ifşa politikasıyla uyumlu olarak doğruladığını vurguluyor.
Saldırının sınırları
Teknik, belirli bir müşteriyi, iş yükünü, ana makineyi veya veriyi hedefleyemiyordu ve kalıntı verinin var olması garanti değildi. Saldırgan etkin şekilde bağlı bir diske erişemiyordu; araştırmacılar başka bir müşterinin canlı verisinin değiştirilmesini veya iş yükü kullanılabilirliği üzerinde herhangi bir etki göstermedi.
Cloudflare bunu nasıl düzelti
İlk hafifletme adımı, filodaki dm-thin havuz yapılandırmalarından skip_block_zeroing seçeneğini kaldırarak, yeni tahsis edilen blokların bir container'a sunulmadan önce temizlenmesi varsayılan davranışını geri getirdi. Araştırmacılar bu değişiklikten sonra kavramsal ispatın artık çalışmadığını bağımsız olarak doğruladı.
Yeni tahsisleri sıfırlamak, mevcut ince aygıtlara zaten eşlenmiş blokları sterilize etmez — yeni container'ların bu blokları yeniden tahsis etmeden devralabileceği, OCI imaj katmanları için hazırlanmış dm-thin anlık görüntülerinin ana makine önbellekleri dahil — bu yüzden Cloudflare ayrıca düzeltmeden önce oluşturulan önbellekteki imaj anlık görüntülerini kaldırdı ve çalışan her container diskini emekliye ayırdı. Ana makineler yoğun olmayan saatlerde boşaltıldı, VM'ler yeniden başlatıldı ve imaj önbellekleri temizlendi; böylece diskler ve önbellekteki katmanlar sıfırlanmış tahsislerden yeniden inşa edildi. Bu temizlik Containers filosunun tamamında tamamlandı ve müşteri tarafında herhangi bir yapılandırma değişikliği gerekmedi.
İstismar edildiğine dair kanıt yok
Cloudflare, araştırmacıların kavramsal ispatını ve dahili bir yeniden üretimi referans desenler olarak kullanarak, container altyapısından elde edilen geçmiş disk-G/Ç telemetrisini inceledi. Bildirilen tekniğe atfedilebilen tek etkinlik, yetkili doğrulama yürüten araştırmacılardan ve Cloudflare mühendislerinden kaynaklandı; şirket kötü niyetli istismara dair hiçbir belirti bulamadı.
Neden önemli
Bu olay, tek bir depolama katmanı performans seçeneğinin — blok sıfırlamayı atlamanın — paylaşımlı altyapıda kiracı izolasyonunu sessizce nasıl bozabileceğinin somut bir örneği. Guest VM içinde ham aygıt erişimi standart ve meşru bir yetenek olduğundan, bu durum teorik değil gerçekçi bir saldırı yüzeyi oluşturuyordu. Olay ayrıca eşgüdümlü ifşanın değerini vurguluyor: müşteri verisini açığa çıkarmayan, dikkatle kapsamlandırılmış bir kavramsal ispat, Cloudflare'nin sorunu hızla doğrulamasını, düzeltmesini ve teyit etmesini sağladı; iki aşamalı giderim — önce yapılandırmayı düzeltmek, ardından var olan her eşlemeyi temizlemek — kiracılar arasında ince sağlanmalı depolama çalıştıran her operatör için yararlı bir şablondur.
- #cloudflare
- #security
- #containers
- #cloud
- #bug-bounty