1 puan yazan GN⁺ 2025-05-14 | 1 yorum | WhatsApp'ta paylaş
  • Dal tahminleyicindeki yarış durumu nedeniyle Intel CPU'larda Branch Privilege Injection adlı yeni bir güvenlik açığı keşfedildi
  • Bu saldırı, eşzamansız güncellemeler ve güvenlik etki alanları arasındaki yetersiz senkronizasyon nedeniyle mümkün hale geliyor
  • eIBRS ve IBPB gibi mevcut donanımsal hafifletmeler yarış durumu karşısında etkisiz kalıyor
  • Intel, söz konusu açığı mikrokod güncellemesi ile hafifletiyor; bunun bir performans maliyeti bulunuyor
  • Açık, 9. nesil ve sonrası tüm Intel CPU'ları etkiliyor ve işletim sisteminden bağımsız olarak ortaya çıkıyor

Branch Privilege Injection saldırısına genel bakış

  • Branch Privilege Injection, Spectre-BTI ailesindeki branch target injection saldırılarını yeni bir yöntemle yeniden gündeme getiren bir güvenlik açığıdır
  • Intel CPU'larda donanım düzeyindeki Spectre savunmaları 6 yıldır etkiliydi; ancak bu araştırma, yarış durumu (race condition) ile bunların aşılabildiğini kanıtlıyor
  • Dal tahminleyici, komut akışıyla eşzamansız çalışır ve belirli koşullarda 10 ila 100'lerce çevrim gecikmeli güncellemeler oluşabilir
  • Dal tahminleyici güncellemeleri sürerken bir ayrıcalık geçişi (ör. kullanıcı-çekirdek, misafir-hypervisor) ya da IBPB çalıştırılırsa, bu güncellemeler yanlış şekilde yeni ayrıcalık moduyla ilişkilendirilebiliyor
  • Buna Branch Predictor Race Condition adı veriliyor ve bu durum hassas bellek bilgilerinin sızdırılmasına yol açabiliyor

Saldırı gösterimi ve etkisi

  • Bu saldırı yöntemiyle Ubuntu 24.04 üzerinde (en güncel yamalar ve varsayılan hafifletmeler etkin) rastgele bellek sızıntısı hızı 5.6KiB/s düzeyine ulaşıyor
  • Intel Raptor Lake (13. nesil) CPU üzerinde saldırının başarıyla çalıştığını gösteren bir video demosu bulunuyor

Etkilenen hafifletmeler

  • eIBRS: 9. nesil (Coffee Lake Refresh) ve sonrası Intel CPU'larda sunulan bir güvenlik mekanizmasıdır; dolaylı dal tahminini güvenlik etki alanlarına göre ayırır.
  • IBPB: eIBRS yalnızca donanımsal güvenlik etki alanları arasındaki saldırıları engellediği için, IBPB ek güvenlik sınırları için (ör. güvenilmeyen sanal makineler) tüm dolaylı dal tahminini geçersiz kılan bir işlev sunar
  • Her ikisi de belirli ortamlarda önerilen güvenli varsayılan hafifletmelerdir

Branch Predictor Race Condition ayrıntılı analizi

  • Dal tahminleyicide yarış durumu oluştuğunda eIBRS ve IBPB'nin güvenlik garantileri geçersiz hale gelir
  • Komut yürütme sırasında bir ayrıcalık geçişi yaşandığında, devam eden dal tahmin güncellemesi yanlış şekilde yeni güvenlik etki alanına atanır
  • IBPB çalıştırılsa bile, ilerlemekte olan tahmin güncellemeleri flush edilmeden tahminleyicide kalabilir ve güvenlik sorunu yaratır

Branch Predictor Race Condition için hafifletmeler

  • Intel, etkilenen işlemciler için bir mikrokod güncellemesi geliştirdi ve Alder Lake üzerinde deneysel olarak saldırının engellendiği doğrulandı
  • Bu hafifletme uygulandığında Alder Lake'te en fazla %2,7 performans düşüşü görülüyor
  • Yazılımsal alternatif hafifletme stratejilerinde de deney sonuçlarına göre %1,6 (Coffee Lake Refresh) ile %8,3 (Rocket Lake) arasında performans ek yükü ölçüldü
  • Daha ayrıntılı bilgiler makalede sunuluyor

Ek kaynaklar

  • Branch Privilege Injection hakkındaki temel araştırma makalesinin USENIX Security 2025'te sunulması planlanıyor
  • Black Hat USA 2025'te açığın tespiti ve exploit geliştirmeye odaklanan bir sunum yapılması bekleniyor
  • Saldırı ve deney kaynak kodları github üzerinde yayımlandı

SSS

1. Bilgisayarım etkileniyor mu?

    1. nesil (Coffee Lake Refresh) ve sonrası tüm Intel işlemciler Branch Privilege Injection'dan etkileniyor
  • IBPB'nin etkisiz kalması durumu 7. nesil (Kaby Lake) ürünlerde de doğrulandı

2. Intel dışı CPU'lar da etkileniyor mu?

  • Analiz sonuçlarına göre AMD ve ARM sistemlerinde bu sorun tespit edilmedi

3. Sadece Linux mu etkileniyor?

  • PoC Linux için hazırlanmış olsa da, temel sorun donanımda bulunuyor
  • Bu donanım üzerinde çalışan tüm işletim sistemleri savunmasızdır

4. Ne yapılmalı?

  • İşletim sistemi ve BIOS için en güncel güncellemelerin yüklenmesi öneriliyor

1 yorum

 
GN⁺ 2025-05-14
Hacker News yorumu
  • Harvard'da yayımlanan yazıda, John için talihsiz biçimde dallanmaların şeytan ve kuantum mekaniğiyle anlaşma yapıp gelecek nesil işlemcilere zararlı bir büyü musallat ettiği yönünde esprili bir benzetme yapılıyor; bu büyü de "ölçekleme kaynaklı voltaj sızıntısı" ya da "artan boşa harcanan ısı" gibi adlarla anılıyor

  • James Mickens'in yazılarının her zaman eğlenceli olduğu söyleniyor ve güvenlikten sorumlu Mossad'ın HTTPS gibi şeyleri umursamadığına dair bir şaka alıntılanıyor; verilere ihtiyaçları olursa doğrudan dronla telefonunuzu uranyum maketiyle değiştirip sonunda eşyalarınızı miras satışından satın alarak fotoğraflara bizzat bakacakları şeklinde neşeli bir hayal kuruluyor

  • Çok sayıdaki matrise değinilen kısmın az da olsa umut verdiği söyleniyor ve John'un erkek kardeşinin bu matrislere insan gibi konuşmayı öğretmenin yolunu bulduğundan bahsediliyor

  • Araştırmacı blogu ve makale bağlantısı paylaşılıyor

  • Yukarıdaki bağlantının üniversite basın bülteninden araştırmacı blog yazısına çevrildiğine dair geri bildirim bırakılıyor

  • Yeni açığın etkisine dair, araştırmacının CPU'nun tüm bellek içeriğini tekrar tekrar okuyabildiğini ve saniyede 5.000 bayt hıza ulaşılabildiğini açıkladığı, sonuçta saldırı başarılı olursa CPU'daki tüm bilgilerin sızdırılabileceği belirtiliyor

  • Başlık URL'sinin blog bağlantısıyla değiştirilmesinin iyi olacağı dile getiriliyor

  • Dallanma kestiricisinin çalışma biçimi özetleniyor

    • Kestirici durum güncellemesi, dallanma komutu tamamlandıktan sonra gerçekleşebiliyor
    • Pipeline içinde sonuç commit'i ile kestirim commit'i farklı
    • Yetki dönüşüm komutları da kestirim durumunu beklemeden pipeline'da ilerlediği için, yetki seviyeleri tutarlı değilse sorun çıkabiliyor
    • Pipeline içinde "mevcut yetki seviyesi" tekil olmayabilir; zor kısım da bu
  • Profesör Kaveh Razavi'nin kendi okulunda donanım güvenliği dersi verdiğini ve bu dersin gerçekten harika olduğunu görmekten memnuniyet duyuluyor

  • Birkaç yıl önce bu dersi ve kötü amaçlı yazılımla ilgili başka bir dersi kontrol etmeye çalıştığı ama kamuya açık bilginin neredeyse hiç olmadığını, resmi ders kayıtları ya da notlarının internette olup olmadığını merak ettiği yazılıyor

  • Training Solo saldırısıyla bu açık arasındaki ilişkiyi bilen biri olup olmadığı soruluyor

  • Yonga seti mikrokod yamasına dair açıklamada yalnızca Windows'tan söz edilmesine şaşırılıyor, Linux kullanıcılarının durumunun ne olduğu soruluyor

  • Linux çekirdeğinin de uzun zamandır mikrokod yüklemeyi desteklediği, ancak dağıtımların güncelleyebilmesi için Intel'in mikrokod dosyalarını yayımlaması gerektiği, bunun da sistem güncellemesine dahil edilmesi gerektiği açıklanıyor

  • Intel'in Linux için mikrokod güncellemelerini GitHub'da açık olarak yayımladığı, bu yüzden dağıtımların oradan alıp otomatik biçimde dağıtabildiği, fakat bu özel açığın gerçekten yamalanıp yamalanmadığını uzman olmadığı için bilmediği söyleniyor

  • Intel'in resmi güvenlik tavsiyesi bağlantısı paylaşılıyor

  • AMD CPU'larda da benzer bir açık olup olmadığı soruluyor; branch prediction gibi teknik mekanizmaların CPU güvenlik açıklarının temel nedeni olduğuna dikkat çekilerek AMD'nin bunlardan nasıl kaçındığı merak ediliyor

  • Araştırmacı blogunun özetine dayanarak, bu Branch Privilege Injection açığının AMD ve ARM sistemlerini etkilemediği yanıtı veriliyor

  • AMD'nin bu tür sorunlardan tamamen kaçınmış olmadığı; Spectre ve Meltdown örneklerinde olduğu gibi her açığın kapsamının farklı olduğu, bunun Intel'e özgü olduğu ama AMD'nin de aynı aileden açıklarla (ör. Spectre) karşı karşıya kaldığı belirtiliyor

  • Biraz daha ayrıntılı bir açıklamayla, spekülatif yürütmenin başlı başına bir açık değil modern CPU'larda zorunlu bir mekanizma olduğu vurgulanıyor; iç karmaşıklığın kusurların bulunmasını zorlaştırdığı, bu yüzden AMD ve ARM'de de benzer hatalar olabileceği söyleniyor. Tam çözümün, modern sistemlerde kodun tam yalıtımının imkânsız olduğu gerçeğini kabul etmeyi gerektirdiği; bunun da bazı büyük şirketlerin iş modelleri için yıkıcı olabileceği endişesi dile getiriliyor

  • Bu açığa karşı önlem olarak, branch predictor güncelleme anında yetki seviyesinin bir snapshot'unun alınıp bu değerin birlikte taşınmasının, yazılımda görülen türden bir sorunu benzer şekilde çözebileceği ileri sürülüyor

  • CPU branch predictor'ı tampon sınırlarını ve kodun yetki bilgisini doğrudan görebilse önlemenin kolay olacağı, ancak bunun pointer'lara önemli ek bilgiler iliştirmeyi gerektireceği esprili biçimde söyleniyor

  • Sorunun kapsamının daha net anlaşılması gerektiği, ancak spekülatif yürütme yoluyla yapılan açık saldırılarının gerçekten çok büyük ön hazırlık gerektirdiği ve doğrudan kod çalıştırma yetkisi yoksa pek anlamlı olmadığı, tarayıcıda keyfi JS koduyla keyfi bilgi sızdırmanın mümkün olmadığı; kendisinin performans için tüm mitigation'ları kapattığı söyleniyor

  • CHERI mimarisi öneriliyor

  • Yalnızca pointer yapısını değiştirmenin yeterli olmayacağı belirtiliyor; gerçekten donanım düzeyinde her bellek erişimine adres sınırı bilgisi ekleyen eski x86 segment yaklaşımına (80286) değiniliyor. Bu tür sistemlerde de yazılımın sınır bilgisini doğru işlemesi gerektiği, ama sonunda aynı sınırlara takıldığı ifade ediliyor

  • Şu anda tüm büyük işletim sistemlerinde bu açık için yama (veya ilgili mikrokod) uygulanıp uygulanmadığı soruluyor

  • Evet diye yanıt veriliyor; bilgi ambargosu bugün (13 Mayıs) kalktı