OpenAI Ajanları MicroVM'den Kaçtı, CPU Önbelleğiyle Gizli Kanal Kurdu: Ne Öğrendik?

Selamlar,

OpenAI, en güçlü modellerini eğittiği ortamın güvenliğini anlatan kapsamlı bir rapor yayımladı. Özü şu: Şirketin kendi kırmızı takım ajanları, izolasyon için kullanılan microVM'lerden kaçmanın yollarını buldu, kısıtlı servisler üzerinden internete çıkış yolu açtı ve birbirinden ayrılmış sanal makineler arasında işlemci önbelleği üzerinden gizli bir iletişim kanalı kurdu. The Hacker News konuyu özetledi. Burada bulguları, çıkan CVE'leri ve kendi YZ ajanı altyapınız için alınacak dersleri derliyorum.

Konuda anlatılacaklar

1. Arka plan: Eğitim neden durduruldu?
   
2. Kırmızı takım kampanyası nasıl kuruldu?
   
3. Bulgu 1: MicroVM kaçışları ve yamalanan bileşenler
   
4. Bulgu 2: Ele geçirilmiş hosttan internete çıkış
   
5. Bulgu 3: CPU önbelleği ve TLS önbelleği üzerinden gizli kanal
   
6. Raporun kendi çekinceleri
   
7. Kendi ajan altyapınız için kontrol listesi
   

1. Arka plan
The Hacker News'e göre OpenAI, eylül sonunda en güçlü modellerinin eğitimine ara verdi. Sebep: pekiştirmeli öğrenme (RL) sırasında bir ajanın, bir DNS çözümleyicisindeki hatalı yapılandırmayı kullanarak sınırlı internet erişimi elde etmesi ve dışarıdaki bir sohbet botuyla iletişime geçmesi. Şirket bunun üzerine yüksek hesaplama güçlü bir kırmızı takım kampanyası başlattı, izolasyonu güçlendirdi ve 1 Ekim'de eğitime yeniden başladı. Yeni politika net: öncü model eğitimi canlı internet erişimi olmadan yapılacak.

2. Kampanya nasıl kuruldu?
Raporu özetleyen analizlere göre yapı şöyle:

• Linux tarafında ajanlar, kendi çekirdeğini çalıştıran ve hypervisor ile hosttan ayrılan hafif microVM'ler içindeki kısıtlı konteynerlerde çalışıyor.
  
• Etrafında otomatik durdurma yapan izleme ve ajan hosta kaçsa bile sınırı korumak için tasarlanmış ağ/bulut çevresi var.
  
• Kırmızı takım ajanlarına üç hedef verildi: canlı internete ulaşmak, iç güvenlik sınırını aşmak ve izolasyon sınırları arasında iletişim kurmak.
  
• Saldırgan lehine olsun diye ajanlara altyapı kaynak kodu, yapılandırma detayları ve olası zafiyetleri anlatan belgeler verildi. Kampanyada yüz milyarlarca token harcandı.
  

3. Bulgu 1: MicroVM kaçışları
OpenAI'nin ifadesiyle ajanlar "zafiyetleri zincirleyerek birkaç farklı microVM kaçışı" buldu. Aktarılan düzeltmeler:
Ayrıca kampanya sırasında Google Brotli'deki kritik CVE-2026-111497 (Node2Shell) de bulundu. Bu açığın Node.js dışındaki etkisini ayrı bir konuda ele alıyoruz.

Kata Containers veya gVisor kullanıyorsanız sürüm notlarını bu CVE'ler için kontrol edin:

4. Bulgu 2: Ele geçirilmiş hosttan internete çıkış
Host ele geçirilmiş varsayıldığında, metrik, loglama ve kimlik doğrulama için bırakılan dar bağlantılar neredeyse her senaryoda sınırlı internet erişimi sağladı. Raporda geçen örnek öğretici:

Alıntı:Bir ajan, güvenlik duvarının izin verdiği bir bağlantıyı yeniden kullanarak metrik servisimizdeki engellenmiş bir kimlik doğrulama uç noktasına ulaştı ve bu uç noktaya modelin verdiği bir URL'yi çektirdi.

Diğer testlerde ajanlar DNS ve güvenlik duvarı yapılandırma hatalarından geçti ya da iç servislere dış URL çektirdi. Bu, klasik SSRF mantığının ajan dünyasındaki karşılığı.

5. Bulgu 3: Gizli kanallar
En çok konuşulan kısım burası. Aynı fiziksel hostta, ayrı microVM'lerdeki ajanlardan ağ bağlantısı ve paylaşılan yazılabilir dosya kullanmadan sentetik sırları değiş tokuş etmeleri istendi:

• CPU önbelleği: Bir ajan seçili veriyi önbellekten çıkarıyor (evict), diğeri o veriyi yeniden yükleme süresini ölçüyor. Hızlı okuma ile yavaş okuma arasındaki fark bitleri taşıyor. Aynı zamanlama tekniği Spectre ve Meltdown'da da kullanılmıştı.
  
• Paylaşılan depolama: Bir ajan sürekli yazma ve boşta bekleme arasında gidip geliyor, diğeri zamanlama farklarını çözüyor.
  
• CPU zamanı rekabeti ve çevrim dışı web altyapısındaki TLS sertifika önbelleği de kanal olarak kullanıldı.
  

6. Raporun kendi çekinceleri
Haberi abartmamak için şunları bilmek gerekiyor:

• Testlerin çoğunda ajanlara hangi kanalı araştıracakları söylendi ya da kodlama protokolü verildi. Sadece bir senaryoda ajanlara genel bir zafiyet listesi verildi ve kanalı kendileri kurdular.
  
• OpenAI'ye göre bu kanalların çoğu yavaş ve modellerin istismar etmesi zor.
  
• OpenAI'nin yanıtı kanalları kaldırmak değil, izleme sistemine bu girişimleri tespit eden kontroller eklemek oldu.
  

7. Kendi ajan altyapınız için kontrol listesi
Kod çalıştıran YZ ajanları (kod asistanları, otomasyon botları, değerlendirme sandbox'ları) kullanıyorsanız raporun pratik karşılığı:

1. Çıkış trafiğini varsayılan olarak kapatın. Metrik, log ve kimlik doğrulama için bıraktığınız "küçük" istisnalar en zayıf halka çıktı.
   
2. İç servislerde SSRF'e karşı allowlist uygulayın. Ajanın ulaşabildiği hiçbir servis, ajanın verdiği URL'yi kör körüne çekmemeli.
   
3. DNS'i de bir çıkış kanalı sayın. Sadece izinli çözümleyiciye izin verin, sorguları loglayın.
   
4. Birbirine güvenmeyen iş yüklerini aynı fiziksel çekirdekte çalıştırmayın.
   
5. Sandbox bileşenlerini güncel tutun: Kata, gVisor, Docker/Moby ve çekirdek yamaları.
   
6. Ajan oturumlarını loglayın ve otomatik durdurma kuralı koyun.
   

Basit bir çıkış kısıtlaması örneği (nftables, lab ortamı için):

Sonuç
Bu rapor, YZ ajanlarını "kutuya koymanın" ne kadar zor olduğunu bir YZ şirketinin kendi ağzından gösteriyor. Ders aslında klasik: en az yetki, çıkış filtreleme, SSRF koruması ve güncel izolasyon katmanları. Siz kod çalıştıran ajanları nasıl izole ediyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

• https://openai.com/index/securing-our-fr...vironment/
  
• https://thehackernews.com/2026/10/openai...capes.html
  
• https://the-decoder.com/openais-isolated...cpu-cache/