Blog

Cloudflare, container tabanlı barındırma ortamında ortaya çıkan bir cross-tenant (çraz kiracısı) veri açığının teknik ayrıntılarını ve açığın nasıl kapatıldığını yayımladı. Açık, güvenlik araştırmacısı Oren Yomtov tarafından sorumlu biçimde bildirildi ve firma tarafında hızlıca giderildi. Cloudflare, müşteri verilerinin ele geçirildiğine dair bir kanıt olmadığını belirtti. Bu yazıda, çok kirıcılı (multi-tenant) altyapıda paylaşımlı depolamanın yol açabileceği hassas veri riski, açığın çalışma prensibi ve alınan teknik önlemler detaylı biçimde ele alınıyor.

Açığ Tespiti ve Raporlanması

Açık, 4 Eylül 2026 tarihinde Accomplish şirketinden güvenlik araştırmacısı Oren Yomtov tarafından, firmanın yürüttüğü hata ödülü (bug bounty) programı üzerinden sorumlu biçimde bildirildi. Açık, Container hizmetinin yanı sıra bu hizmetin üzerine inşa edildiği Sandbox ortamını da etkiliyor. Bildirimin ardından yapılan incelemede, açığın tamamen giderildiği ve üçüncü taraflara ait herhangi bir verinin ele geçirildiğine dair bir işaret bulunmadığı açıklandı.

Bu tür sorumlu raporlama süreçleri, zafiyetlerin halka açıklanmadan önce çözülmesinde kritik rol oynar. Benzer biçimde, Cloudflare’ın topluluk temelli güvenlik modelleri de araştırmacıların bulguları etik kurallar çerçevesinde paylaşmasını kolaylaştırıyor. Açığın anlaşılması ve hızlıca test edilmesi, araştırmacıların sunduğu detaylı rapor ve kontrollü denemeler sayesinde mümkün olmuştu.

Multi-Tenant Mimarisi ve Dolaylı Riski

Container tabanlı barındırma hizmetleri, iş yüklerini birden fazla müşteri paylaşılan (multi-tenant) bir altyapı üzerinde çalıştırır. Bu mimaride müşteri, iş yükünün hangi fiziksel sunucu üzerinde çalışacağını seçemez; sistem yük dengleme ve kaynak erişilebilirliğine göre otomatik bir atama yapar. İşte tam da bu otomatik atama, güvenlik açısından dikkat edilmesi gereken bir nokta oluşturur.

Sorunun özünde yatan konu, paylaşımlı fiziksel kaynakların bir kullanıcudan diğerine devredilmesi sırasında arta kalan verinin (residual data) temiz şekilde ortadan kaldırılmamasıdır. Bir müşteri hesabından silinen veya yeniden atanmış olan disk bloklarının üzerinde, önceki sahibine ait ham veri kalabiliyor. Buradan hareketle, kötü niyetli bir kullanıcının kendi hesabı dışında bir veriye ulaşma ihtimali teorik olarak doğar.

Depolama Ayırma Nasıl Çalışır

Container ortamlarında kök disk (root disk) sağlanması için genellikle Linux device mapper thin provisioning (dm-thin) teknolojisi kullanılır. Her container, Firecracker adlı sanal makine izleyicisi (VM monitor) tarafından çalıştırılan ayrılmış bir sanal makine içinde barındırılır. Firecracker, bu diski sanal makineye /dev/vdc yoluyla sunar.

Incel ayırma (thin provisioning) tekniğinin temel mantığı, fiziksel depolamanın yalnızca sanal disk önce eşlenmemiş bir bölgeye yazma yaptığı anda tahsis edilmesidir. Yani veri yazılmadıkça fiziksel blok ayrılmaz. Açığın etkilediği depolama havuzları, 64 KiB boyutunda bir thin-blok boyutu kullanıyordu.

Kritik nokta şuydu: Bir container’ın kök diskini oluşturan thin hacmi silindiğinde, hacme ait fiziksel bloklar birden fazla müşteri hesabına hizmet eden ortak bir havuza geri verilirdi. Bu havuz yapılandırmasında aşağıdaki seçenek aktif durumdaydı:

skip_block_zeroing

Bu seçenek yapılandırıldığında, dm-thin bloklara erişime sunulmadan önce onları sıfırlamaz (zeroing yapmaz). Sonuç olarak, daha önce kullanılmış bir 64 KiB blok yeniden atanırken tam blok yazması içeriğin tamamını değiştirir; ancak daha küçük bir yazma yalnızca yazılan kısmı etkiler. Geri kalan kısım, bloğun önceki sahibine ait veriyi taşıyabilir.

Açığ Çalışma Prensibi

Açığ tehlikeli yanı, boşta kalan bir bölgenin okunmasının sıfır döndürmemesidir. Eşlenmemiş bir thin bölge okunduunda, dm-thin fiziksel blok tahsis etmeden doğrudan sıfır (zero) döndürür. Bu durum, rastgele bir okumanın artık veriyi ortaya çıkarmayacağını gösterir.

Örnek bir saldırı (proof of concept) senaryosu, konuk işletim sistemindeki ext4 dosya sisteminin boş alanına karşılık gelen 64 KiB hizalı bölgeleri tespit eder ve her birine hizalı bir 4 KiB yazma gerçekleştirir. Böylece:

• Bir yazma eşlenmemiş bir thin bloğa ulaştığında, dm-thin ortak havuzdan fiziksel bir 64 KiB blok tahsis eder.
• 4 KiB’lik yazma bloğun yalnızca o bölümünü değiştirir.
• Blok sıfırlama kapalı olduğu için, geri kalan 60 KiB bölüm önceki container’dan veri taşıyabilir.
• Sonrasında yapılacak ham (raw-device) okuma, yeni container’ın hiç yazmadığı baytları ortaya çıkarabilir.

Saldırı Senaryosunun Adımları

Uygulanan örnek senaryo şu adımları içeriyordu:

1. Workers Paid hesabını kullanan bir container oluşturmak.
2. Yazılabilir kök diski /dev/vdc üzerinden açmak.
3. Diski okuyup bir temel (baseline) değer kaydetmek.
4. Her seçili 64 KiB bölgeye, ext4 boş alanına karşılık gelen bir 4 KiB bloğu yazmak.
5. Elde edilen blokları tekrar okumak.
6. Yalnızca yeni container tarafından değiştirilmeyen kısımları incelemek.

Bildirime eklenen blok sayıları, ofsetler, boyutlar, sağlanan özet (hash) sonuçları ve kesilmiş önekler vardı. Araştırmacılar ham blokları geri alıp açığı doğrulsalar da, Cloudflare’a ilettikleri materyallerde üçüncü taraflara ait dosya adı, kimlik, kimlik bilgisi, ana bilgisayar adı, adres veya geri alınan içerik değeri bulunmuyordu. Araştırmacılar ayrıca geri aldıkları verileri güvenli biçimde sildiklerini teyit etti.

Açığ Doğrulama Süreci

Araştırmacılar, kendi oluşturdukları test dosya sisteminin bloklarını diğer dosya sistemlerinden ayırmak için ext4 dizin bloğu sağlamlık kontrolünü (checksum) kullandı. Bu sayede, örnek senaryoda ortaya çıkan artık verinin gerçekten kendi test ortamlarına mı yoksa farklı bir sisteme mi ait olduğunu ayırt edebildiler. Doğrulama sürecinin tamamı, üçüncü taraflara ait verilere erişmeden ve bunları işlemeden ilerledi.

Tespit ve Soruşturma Bulguları

Cloudflare, düzeltmeyi Container filosunun tamamında uyguladı ve herhangi bir müşteri tarafı yapılandırma değişikliğine ihtiyaç kalmadı. Firmanın erişimi olan geçmiş disk G/Ç (I/O) telemetrisinde, kötü niyetli bir kullanıma işaret eden bir bulgu tespit edilmedi. Raporlanan tekniğe atfedilebilen faaliyetler yalnızca araştırmacılar ve Cloudflare mühendislerinin yetkili doğrulama çalışmalarından kaynaklanıyordu.

Bu noktada dikkat edilmesi gereken önemli bir ayrıntı, açığın teorik bir tasarım hatası olmasıyla gerçek bir veri ihlali arasında belirgin bir fark olmasıdır. Açığın kullanımı belirli bir müşteriye, iş yüküne, sunucuya veya veriye yöneltilemiyordu; ayrıca artık verinin mevcut olması da garanti değildi. Yani zafiyet bir mimari kusur olarak var olsa da, somut bir veri sızıntısına dönüştüğüne dair kanıt bulunamadı.

Ne Anlama Geliyor ve En İyi Pratikler

Çk kirıcılı ortamlarda paylaşımlı depolamanın güvenli şekilde yönetilmesi, hosting sağlayıcılarının temel sorumluluklarından biridir. skip_block_zeroing gibi performans odaklı seçenekler, maliyet ve hız avantajı sağlasa da, blok seviyesinde veri karışıklığı riskini beraberinde getirebilir. Bu nedenle modern altyapılarda, blok tahsisi sırasında sıfırlamanın varsayılan olarak açık olması veya hassas veri içeren iş yüklerinin izole ortamlarda çalıştırılması önerilir.

Web güvenliği açısından bakıldığında, bu tür altyapı seviyesi açıklar web uygulaması seviyesindeki XSS gibi zafiyetlerden farklı bir katmanda düşünülür. XSS uygulamanın kendisinde oluşurken, burada söz konusu olan fiziksel depolamanın yönetiminden kaynaklanan bir konten dışı erişim riskidir. Her iki durumda da savunmanın derinliği (defense in depth) prensibi geçerlidir.

Kullanıcılar için pratik tavsiyeler şunlardır:

• Hassas veri içeren iş yüklerini mümkün olduğunca izole ve özel ortamlarda çalıştırın.
• Paylaşımlı (shared) hosting yerine kaynak izolasyonu daha güçlü olan VPS çözümlerini değerlendirin.
• Sunucu erişim loglarını ve depolama G/Ç aktivitelerini düzenli olarak izleyin.
• Kritik verileri şifreleyerek, fiziksel blok seviyesinde bir sızıntının bile içeriğin okunamaz kalmasını sağlayın.

Sık Sorulan Sorular

Açık gerçek bir veri ihlali miydi?

Hayır. Açık teorik bir tasarım hatası olarak ortaya çıktı. Cloudflare, geçmiş telemetride kötü niyetli bir kullanıma dair bir kanıt bulmadığını ve müşteri verisinin ele geçirildiğine dair bir işaret olmadığını belirtti.

Açık hangi hizmetleri etkiliyordu?

Açık, Container hizmetini ve bu hizmet üzerine kurulu olan Sandbox ortamını etkliyordu. Düzeltme filo genelinde uygulandı.

Müşterilerin herhangi bir işlem yapması gerekiyor mu?

Hayır. Düzeltme sağlayıcı tarafında, müşteri tarafı bir yapılandırma değişikliğine gerek kalmadan yapıldı.

Açık belirli bir müşteriye yönelik miydi?

Hayır. Saldırı tekniği belirli bir müşteriye, iş yüküne, sunucuya veya veriye yöneltilemiyordu. Artık verinin mevcut olması da garanti değildi.

Bu tür açıklar nasıl önlenir?

Blok seviyesinde sıfırlamanın açık tutulması, hassas iş yüklerinin izole ortamlarda çalıştırılması ve depolama aktivitesinin düzenli izlenmesi en etkili önlemlerdir. Ayrıca kritik verilerin şifrelenmesi, fiziksel blok seviyesinde bir sızıntının bile veri korumasını sağlar.