Firecracker microVM'den kaçış: ana makinede root yetkisi

Firecracker VM kaçışı tam olarak ne yapıyor?

Sonuç net: kod, içinde tutulması gereken microVM'in dışında, ana makinede root yetkisiyle çalışıyor.

Firecracker, AWS'nin güvenilmeyen kodu microVM'lerde çalıştırmak için geliştirdiği hafif sanallaştırma katmanı. Tasarımın tamamı tek bir söze dayanıyor: konuk konukta kalır. PWN.AI Security Research tarafından yayımlanan PwnEscape Part 2, bir Firecracker kurulumunda bu sözün nasıl bozulduğunu anlatıyor.

Yazı, bir zincirin ikinci yarısı. Part 1 ana makine belleğine erişim sağlayan bir ilkel sunuyordu; Part 2 bunu kullanarak Firecracker sürecini bellekte buluyor ve konuk içinden canlı bir iş parçacığını ele geçiriyor. Araştırmacılar sonucu konuktan ana makineye kod çalıştırma olarak tanımlıyor: kötü niyetli konuk microVM sınırını aşıyor ve ana makinede root olarak çalışan bir süreci kontrol ediyor.

Bunu teorik bir makaleden ayıran şey, sonrasında olanlar. Yazıya göre Firecracker çalışmaya devam etti ve VM'e SSH üzerinden erişilebildi. Yani bir çökme değil, sessiz bir devralma.

Zincirin adımlarını sırayla görmek, nerede kırılabileceğini anlamak için en kısa yol:

• Konuk sayfasına nonce yerleştirilir, ana makine belleğinde EPT kökü aranır (guest_page_hpa bulunur).
• Ters sayfa tablosu aramasıyla Firecracker'ın adres uzayı çıkarılır (host_pgd).
• ELF imajı ve write(2) sarmalayıcısı doğrulanır, ASLR sapması hesaplanır (firecracker_base).
• KVM_RUN sırasında saklanan pt_regs çerçevesi bulunur ve dönüş adresi değiştirilir.
• İş parçacığı kullanıcı alanına dönerken saldırganın seçtiği kod root olarak çalışır.

Konuk sayfasından Firecracker sürecine

İlk sorun yön bulmak: konuk ve ana makine farklı fiziksel adres uzayları kullanıyor ve saldırganın elinde yalnızca VM içinde kontrol ettiği bir sayfa var.

Bir sayfanın VM içinde konuk fiziksel adresi, onu barındıran makinede ise ana makine fiziksel adresi var. İkisi arasındaki çeviriyi Genişletilmiş Sayfa Tabloları (EPT) yapıyor. Araştırmacılar konuk sayfasına tanınabilir bir bayt dizisi, yani nonce, yerleştirdi; ardından ana makine fiziksel belleğinde aday EPT köklerini aradı ve her birini bu nonce'ı içeren sayfaya ulaşana kadar yürüdü.

Arama iki aday üretti; iç içe sayfa tabloları doğrulanınca tek aday kaldı. Bu kökü yürümek, kendi konuk sayfalarının ana makine fiziksel adresini verdi; buna guest_page_hpa diyorlar.

Bu bir tutunma noktası, zafer değil. Firecracker konuk belleğini kendi adres uzayına eşliyor, dolayısıyla sonraki adım ana makinenin yerel sayfa tablolarında geriye doğru çalışıyor: sanal adresi fiziksel adrese çevirmek yerine ters eşleyici, bildiği fiziksel sayfaya giden bir eşleme arıyor, sonra sanal adresi ve arkasındaki sayfa tablosu kökünü buluyor. Doğrulanan tek adres uzayı host_pgd olarak saklandı.

İkiliyi bulmak ve ASLR'ı yenmek

Sayfa tablosu kökü elde olunca konuk, Firecracker sürecini bir hata ayıklayıcı gibi okuyabiliyor.

Sonraki çözücü bu eşlemelerde bir ELF imajı arıyor ve Firecracker'ın write(2) sarmalayıcısındaki bilinen bayt dizisini kontrol ediyor. Böylece bulunan adres uzayının başka bir sürece değil, hedeflenen ikiliye ait olduğu doğrulanıyor.

Adres uzayı düzenlemesi rastgeleleştirmesi (ASLR) çalıştırılabilir dosyayı yükleme anında kaydırdığı için eşleyici yükleme sapmasını buluyor: ELF imajındaki bir adres ile çalışma zamanındaki adresi arasındaki fark. firecracker_base denen bu değer, sömürünün çalışan süreçteki kodu bulmasını ve baytların eşleştiğini kontrol etmek için sanal adresleri ana makine fiziksel belleğine çevirmesini sağlıyor.

Üç konum doğrulandı: kanıt üretmek için kullanılan write(2) sarmalayıcısı, KVM ioctl'inden sonraki devam noktası ve temiz dönüş için gereken kısa xor eax,eax; ret dizisi. Her birinin dönüş yolunda bir görevi var.

KVM_RUN neden zayıf nokta?

Bir Firecracker microVM'indeki her vCPU, ana makine sürecindeki bir iş parçacığı ve bu iş parçacığı sürekli konuktan çıkıp geri dönüyor.

İş parçacığı konuğu çalıştırmak için KVM'e giriyor, kullanıcı alanının bir olayı işlemesi gerektiğinde Firecracker'a dönüyor. İş parçacığı bu sistem çağrısında beklerken ana makine çekirdeği, kullanıcı alanı register'larını pt_regs adlı yapıda saklıyor. Komut işaretçisi yürütmenin nereden devam edeceğini, yığın işaretçisi hangi kullanıcı alanı yığınının kullanılacağını söylüyor.

Hedef bu saklı çerçeve. Saldırgan onu bulup değiştirebilirse, iş parçacığı kullanıcı alanına döndüğü anda Firecracker'ın ne çalıştıracağını seçiyor. KVM_RUN'dan dönüşü zorlayan her konuk işlemi tetikleyici haline geliyor.

Çerçeve bulucu, ana makine iş parçacığının saklı durumunu tanımak için host_pgd ve firecracker_base'i kullandı; en işe yarar ipucu dönüş adresiydi. Yazı daha sonra iş parçacığının nereden devam edeceğini değiştirip KVM dönüşünde saldırganın seçtiği bir çağrıyı çalıştırmasını anlatıyor; ardından konuk yığındaki geçici değişiklikleri geri alıyor.

Bulut kullanıcıları için ne kadar ciddi?

Yazı bir teknik gösterim, kitlesel sömürü raporu değil ve öyle okunmalı.

Araştırma CVE-2026-99999 ile ilişkilendiriliyor ve herkese açık bir bulut bölgesinde değil, bir Firecracker kurulumunda çalıştırılmış. Ayrıca Part 1'deki ana makine belleği ilkeline dayanıyor; bu önemli, çünkü tam zincir konuktaki tek bir hatadan fazlasını gerektiriyor.

Önemi mimaride. MicroVM izolasyonu, yabancıların kodunu güvenle çalıştırmayı sağlayan sınır olarak satılıyor ve Firecracker bu güvenin büyük kısmının altında duruyor. Konuktan ana makinede root'a giden gösterilmiş bir yol, tam da bu modelin dışlaması gereken senaryo.

Firecracker'ı doğrudan veya üzerine kurulu çok kiracılı hizmetleri işletenler için yayın, yama seviyelerini ve yalnızca microVM sınırına ne kadar güvendiklerini gözden geçirme çağrısı. Araştırmacılar mevcut materyalde tam bir sömürü zinciri yayımlamadı.

Aynı zayıf halka, yani güvenilen bir sınırın içinden gelen saldırgan, son dönemde başka olaylarda da karşımıza çıktı: Alpine Linux'taki OpenSSH açığında 257 baytlık bir şifreyle herkese giriş yapılabiliyordu. İzolasyonun tek başına yeterli olmadığını gösteren benzer bir tablo.

Türkiye'de durum ne?

Türkiye'de Firecracker'ı doğrudan kullanan şirketler ve geliştiriciler için pratik soru, yamayı kendilerinin mi uygulayacağı. Bulut sağlayıcısından hizmet alıyorsanız güncelleme sağlayıcının sorumluluğunda; kendi altyapınızda çalıştırıyorsanız CVE-2026-99999 için yukarı akış düzeltmesini takip etmeniz ve microVM sınırını tek başına yeterli görmemeniz gerekiyor.

Yerel bulut ve barındırma sağlayıcılarının bu açığa ilişkin henüz kamuya açık bir yanıtı yok. Kaynak materyalde etkilenen sürümler veya yama tarihleri doğrulanmadı; sağlayıcınıza CVE-2026-99999 için yama takvimini sormanız en sağlam adım. Yurt dışı sağlayıcılarda barındırılan Türk şirketleri için de geçerli: sözleşmede yama taahhüdü arayın.

Firecracker'ın itibarı, bu araştırmanın aşılabildiğini söylediği bir sınıra dayanıyor. Zincir karmaşık ve önceki bir bellek ilkeline bağlı, yani tek tıkla bulut kırma değil. Yine de izolasyon katmanının, koruduğu kod kadar sıkı incelenmesi gerektiğinin açık işareti.