VirtualBox’ın heap zafiyeti hala ortalıkta dolaşıyor.
2017 yılına ait bir belge, VirtualBox’ın NAT ağ yığınındaki CVE-2017-3558 numaralı açığı ortaya çıkarıyor. Bu açık, bir konuk VM’nin ana makinenin kullanıcı alanına (userspace) sızmasına imkan tanıyor. Sekiz yıl sonra bile kod yapısının ürkütücü derecede benzer kalması, günümüzün konteyner yoğun dünyasında yeni bir inceleme gerektiriyor.
VirtualBox’ın Slirp Heap’i İzolasyonu Nasıl İhanete Uğratıyor?
QEMU ve VirtualBox’ta NAT desteği sağlayan klasik kullanıcı modu ağ emülatörü Slirp, konuk VM’nin emüle edilmiş ağ kartından gelen ham IP paketlerini alıp yeniden paketleyerek ana makinenin soketleri üzerinden gönderiyor. Bunun için çekirdek (kernel) ayrıcalıklarına ihtiyaç duymuyor. Kulağa akıllıca geliyor, değil mi? Ancak VirtualBox bu yapıyı ciddi şekilde değiştiriyor: portlar soyuluyor, özel bellek ayırıcılar (allocator) ekleniyor.
Her NAT arayüzü kendine özel bir zone ayırıcısı kullanıyor; her biri 3.072 adet, 2.048 baytlık chunk’tan oluşuyor (nmbclusters=1024+32*64). Boş chunk listesi (freelist) yüksekten başlayıp aşağı doğru ilerliyor. Her chunk’ın başına satır içi meta veriler ekleniyor:
struct item {
uint32_t magic; // (her zaman 0xdead0001)
uma_zone_t zone; // (zone'a işaretçi; uma_zone_t struct uma_zone * tipinde)
uint32_t ref_count;
struct {
struct type *le_next; // (bir sonraki eleman)
struct type **le_prev; // (bir önceki le_next'in adresi)
} list; // (freelist'teki veya kullanılan chunk listesindeki (used_items) bir öğe)
};
Bellek boşaltma işlemleri zincirleme ilerliyor: m_freem → m_free → mb_free_ext → uma_zfree → uma_zfree_arg → slirp_uma_free.
İşte kritik nokta burası. uma_zfree_arg() fonksiyonu başlık bilgilerini kontrol ediyor gibi görünüyor:
void uma_zfree_arg(uma_zone_t zone, void *mem, void *flags) {
struct item *it;
[...]
it = &((struct item *)mem)[-1];
Assert((it->magic == ITEM_MAGIC));
Assert((zone->magic == ZONE_MAGIC && zone == it->zone));
zone->pfFree(mem, 0, 0); // (zone->pfFree, slirp_uma_free fonksiyonudur)
[...]
}
Ancak sürüm derlemelerinde (release builds) - VirtualBox’ın indirme sayfasındaki sürümler gibi - Assert() komutları kaldırılıyor. Bu durumda sihirli sayı (magic) kontrolü ve zone doğrulaması da ortadan kalkıyor.
Ardından slirp_uma_free() fonksiyonu, it->zone‘a körü körüne güvenerek pfFini fonksiyonunu çağırıyor ve şunları yapıyor:
{saldırgan tarafından kontrol edilen işaretçi}({saldırgan tarafından kontrol edilen işaretçi}, {paket verisine işaretçi}, {saldırgan tarafından kontrol edilen 32-bit tam sayı});
Bu, konuk tarafından kontrol edilen heap’ten rastgele fonksiyon çağrısı yapılmasına olanak tanıyor.
Saldırganlar Bunu 2025’te Hala Kullanabilir mi?
Kodun değişmeden kalması en büyük sorun. Raporda belirtildiği gibi: “Açıklanan kodun büyük bir kısmı o zamandan beri pek değişmemiş gibi görünüyor.” VirtualBox 7.0 kaynak kodlarına hızlı bir göz attığımızda, slirp_uma_free‘nin temel yapısının hala durduğu görülüyor. Sürüm derlemelerinde Assert()‘in kaldırılması hala geçerli. Linux ana makinelerde, yeniden konumlandırılamayan ikili dosyalar (non-relocatable binaries) durumu daha da kötüleştiriyor; gerekirse ROP (Return-Oriented Programming) saldırıları için memcpy() kalıpları işe yarayabilir.
Konuk tarafından gönderilen özel hazırlanmış Ethernet çerçeveleri, heap’i taşırabilir ve bir chunk’ın item yapısını bozabilir. Ardından it->zone işaretçisi saldırganın verisine yönlendirilebilir. pfFini fonksiyonu yazılabilir bir ‘gadget’e (kod parçası) işaret edebilir. Böylece ana makinenin kullanıcı alanı ele geçirilmiş olur. Çekirdeğe (kernel) yükselme ise işin tamamlanmamış kısmı; yetki yükseltme (privesc) için VBoxDrv üzerinden bir yol düşünülebilir.
Risk? Paylaşımlı barındırma (shared-hosting) yapılan VM’ler, sızma testleri veya kırmızı takım (red-team) laboratuvarları için yüksek. NAT’ın cazibesi — konukları güvenlik duvarından geçirme — ters tepebiliyor.
Heartbleed’in bellek ayırıcı (allocator) hatalarıyla paralellik gösteriyor. Satıcılar belirtileri düzeltiyor, kök nedeni görmezden geliyor. VirtualBox’ın bu konudaki yanıtı ise sessizlik; 2017 dışındaki bir duyuru yok.
Kullanıcı alanına (userspace) kaçış, çekirdek düzeyinde rastgele kod çalıştırma (kernel RCE) değil, ancak bunun için bir başlangıç noktası. Oradan itibaren Linux ana makine zafiyetleri bolca mevcut — Dirty COW’un yankıları gibi?
Tahmin: Ulus devletler, hava boşluklu (air-gapped) operasyonlar için bu açığı yeniden keşfedecektir. Çekirdek düzeyinde sıfır gün (day-zero) açığıyla uğraşmak neden zahmetli olsun ki, kullanıcı alanı daha hızlı dönüt sağlıyor.
VM Ağları Neden Hala Mayın Tarlası?
NAT modu, konuk trafiğini ana makinenin trafiği gibi gösteriyor. Güvenlikten çok kolaylık sağlıyor. Slirp’in kullanıcı alanı avantajı, heap spreyi (heap spray) saldırılarıyla çöküyor.
Alternatifler? Köprülenmiş (bridged) ağ, konukları doğrudan maruz bırakır — güvenlik duvarları zorunlu hale gelir. Ya da politika uygulamak için ana makinenin eBPF’ini kullanın. Ancak alışkanlıklar baskın; milyonlarca kişi her gün VBox NAT’ı çalıştırıyor.
Oracle’ın yönetim süreci eleştirileri de beraberinde getiriyor. Ücretsiz ve özellik dolu olmasına rağmen, yamalar gecikiyor. Bu 2017 tarihli hayalet bunu kanıtlıyor: VM hipervizörleri kale değil.
Şimdi önlem alın. Mümkün olduğunca NAT’ı devre dışı bırakın. Derleme yapıyorsanız sıkı yapılmış sürümleri (strict builds) çalıştırın. Konukları denetleyin — kötü amaçlı yazılımlar paket selinden hoşlanır.
VM’den ana makine kullanıcı alanına giden yamalanmamış yol. Korkutucu derecede basit.
🧬 İlgili İçgörüler
- Daha Fazla Okuyun: Geçen Yıl İngiltere’deki Fabrikaların %78’i Siber Saldırıya Uğradı – Yönetim Kurulları Aldırmıyor
- Daha Fazla Okuyun: GRU’nun Basit Yönlendirici Hilesi 18.000 Ağı Kapsamında Microsoft Token’larını Ele Geçirdi
Sıkça Sorulan Sorular
VirtualBox’taki CVE-2017-3558 nedir? NAT modunda Slirp üzerinden meydana gelen heap bozulması (heap corruption) ile konuk VM’den ana makine kullanıcı alanına kaçış sağlayan ve rastgele kullanıcı alanı çağrılarına izin veren bir açık.
VirtualBox NAT 2025’te güvenli mi? Tam olarak değil — temel zafiyetler devam ediyor; bunun yerine köprülenmiş (bridged) veya yalnızca ana makineye özel (host-only) modları kullanın.
VM kaçışlarına karşı nasıl korunulur? Hipervizörleri sanal ortamda (sandbox) çalıştırın, gereksiz ağ bağlantılarını devre dışı bırakın, heap kullanımındaki anormallikleri izleyin.
