- Branch Privilege Injection, Intel CPU'larda dal tahmincisindeki yarış durumu nedeniyle yaklaşık 6 yıldır kullanılan Spectre-BTI sınıfı donanım savunmalarını yeniden aşılabilir hale getiren bir zafiyettir
- Saldırının özü, dal tahmincisi güncellemelerinin komut akışından bağımsız olarak eşzamansız işlenmesi ve belirli koşullarda onlarca ila yüzlerce çevrim gecikmeyle uygulanabilmesidir
- Yetki geçişi veya IBPB çalıştırılması sırasında gecikmiş güncellemeler kalırsa, bunlar daha sonra yanlış güvenlik alanına bağlanarak eIBRS ve IBPB'nin güvenlik garantilerini bozabilir
- Araştırmacılar, Ubuntu 24.04 üzerinde tüm varsayılan azaltımlar açıkken Intel 13. nesil Raptor Lake'te rastgele belleği 5.6KiB/s hızla sızdıran uçtan uca bir saldırı gösterdi
- Intel'in mikrokod güncellemesi, Alder Lake değerlendirmesinde zafiyet tespit primitive'ini engelledi ve en fazla %2,7 ek yük gösterdi
Branch Privilege Injection'ın mümkün olduğu koşullar
- Branch Privilege Injection, bir dal hedefi enjeksiyonu saldırısıdır; yani Spectre-BTI'nin etkisini Intel ortamında yeniden mümkün kılar
- Intel'in donanım azaltımları yaklaşık 6 yıldır bu tür saldırıları engelliyordu, ancak bu araştırma Intel CPU'lardaki bir yarış durumunun bu savunmayı sarsabildiğini gösteriyor
- Saldırı iki gözleme dayanıyor
- Intel işlemcilerde dal tahmincisi komut akışından eşzamansız olarak güncelleniyor
- Belirli koşullarda güncellemeler onlarca veya yüzlerce çevrim gecikebiliyor
- Eşzamansız güncellemenin kendisi bir zafiyet değil, bir özellik
- Güvenlik açısından kritik işlemler sırasında dal tahmincisi ile komut akışı arasında yeterli senkronizasyon yok
- Kullanıcı modundan çekirdeğe, konuktan hipervizöre geçiş sırasında güncellemeler hâlâ sürüyor olabilir
- IBPB çalıştırılırken de devam eden güncellemeler kalabilir
- Bu güncellemeler yetki geçişinden sonra ulaşırsa, önceki yetki yerine yeni yetki moduna bağlanır
- Intel işlemcilerde dal tahmincisi komut akışından eşzamansız olarak güncelleniyor
- Bu zafiyet sınıfının adı Branch Predictor Race Conditions'dır
Bozulan azaltımlar ve etki kapsamı
- eIBRS, Intel'in 9. nesil Coffee Lake Refresh sonrasında tüm işlemcilere getirdiği Spectre-BTI azaltımıdır
- Amaç, dolaylı dal tahminlerini farklı güvenlik alanları arasında ayırmaktır
- Her tahmini üretildiği alanla ilişkilendirecek ve sonrasında yalnızca mevcut alanın tahminlerini kullanacak şekilde tasarlanmıştır
- Yetki geçişi sırasında devam eden güncellemeler yeni güvenlik alanına bağlanırsa bu ilişkilendirme manipüle edilebilir
- IBPB, aynı donanım güvenlik alanı içinde sandbox'ları veya birbirine güvenmeyen sanal makineleri ayırmak için kullanılan bir mekanizmadır
- Tüm dolaylı dal tahminlerini geçersiz kılma işlevi sağlar
- Devam eden güncellemeler IBPB ile temizlenmediği için, geçersiz kılmadan sonra da dal tahmincisinde depolanabilir
- Etki kapsamı, nesil ve mimariye göre farklılık gösteriyor
- Intel 9. nesil Coffee Lake Refresh ve sonrasındaki tüm işlemciler Branch Privilege Injection'dan etkileniyor
- IBPB atlatan tahminler 7. nesil Kaby Lake'e kadar gözlemlendi
- Değerlendirilen AMD ve ARM sistemlerinde sorun bulunmadı
- Kavram kanıtlama saldırısı Linux için hazırlanmış olsa da temel sorun donanımda olduğundan, etkilenen donanım üzerinde çalışan işletim sistemleri de etkilenir
Azaltımlar, performans maliyeti ve açık materyaller
- En güncel işletim sistemi ve BIOS güncellemelerinin kurulması öneriliyor
- Intel, etkilenen işlemciler için mikrokod güncellemeleri geliştirdi ve araştırmacılar bunu Alder Lake üzerinde değerlendirdi
- Mikrokod azaltımı, zafiyet tespit primitive'ini engelledi
- Alder Lake'te en fazla %2,7 ek yük gösterdi
- Yazılım tabanlı alternatif azaltımlar da değerlendirildi
- Coffee Lake Refresh'te %1,6 ek yük
- Rocket Lake'te %8,3 ek yük
- Ayrıntılı teknik bilgiler makalede bulunabilir
- Branch Privilege Injection makalesi USENIX Security 2025'te sunulacak; ayrıca Black Hat USA 2025 sunumu da planlanıyor
- Saldırı ve deneylerin kaynak kodu github üzerinde açıklandı
1 yorum
Hacker News yorumları
Araştırmacıların blog yazısı: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
Makale: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf
Saldırı senaryosunda, eninde sonunda CPU belleğinin tamamındaki bilgilerin yanlış ellere geçmesi yalnızca zaman meselesi oluyor
İyi bir yazı. Özetle, dal tahmincisi güncellemesi dal komutu emekliye ayrıldıktan (retire) epey sonrasına ertelenebiliyor
Aksi halde dal komutunun emekliye ayrılması daha uzun sürerdi; bu yüzden mantıklı. Dispatch serileştirme komutları da tahminci durumundaki bekleyen güncellemeler yüzünden pipeline'ı durdurmuyor gibi görünüyor; bu da “dal komutu sonucunu commit etme” ile “tahmin sonucunu commit etme”yi zaten ayırmış oldukları için doğal
Yetki değiştiren komutlar da bekleyen güncellemeler yüzünden pipeline'ı durdurmuyor; bu ise yalnızca tahmin oluşturulurken ve commit edilirken yetki seviyesinin tutarlı olduğu garanti edilebiliyorsa makul. Aksi halde bir yetki seviyesindeki kodun oluşturduğu tahmin, başka bir yetki seviyesinde kullanılan duruma commit edilebilir
Muhtemelen pipeline içinde geçerli yetki seviyesi tek ve net bir değer olmadığı için zor bir problem de olabilir
Kaveh Razavi'yi görmek sevindirici. Eskiden Amsterdam'daki Vrije Universiteit'te ders verirdi; Hardware Security dersi bu konuları derinlemesine ele aldığı için gerçekten harikaydı
Resmî kayıtlar ya da notlar çevrim içi var mı merak ediyorum
Bunun az önce yayımlanan Training Solo saldırısıyla nasıl bir ilişkisi olduğunu bilen var mı? https://www.vusec.net/projects/training-solo/
Training Solo, çekirdeğe girip yetki seviyesini değiştirdikten sonra “kendi kendine eğitim” ile dalları disclosure gadget'a doğru yanlış tahmin ettirerek belleği sızdırıyor
Branch predictor race conditions ise öğrenilmiş dal tahmincisi güncellemesi hâlâ işlenirken çekirdeğe girip, bu güncellemenin yanlış yetki seviyesine bağlanmasına yol açıyor. Sonra bunu kullanarak çekirdekteki dalları disclosure gadget'a yönlendirip belleği sızdırıyor
CPU dal tahmincisi tampon sınırları ve kodun yetki seviyesi hakkında denetim yapacak bilgiye doğrudan erişebilseydi, bu tür sorunları engellemek çok daha kolay olurdu
Ama C programcılarının soğuk ellerinden
void*alınmadan ve işaretçilere önemli bilgiler eklenmeden bu olacak gibi görünmüyorİstediğin şeyi yapmak için tüm load/store işlemlerinin sınır bilgisini saklayan bir tür “zenginleştirilmiş adres” üzerinden geçmesini gerektiren bir donanım mimarisi gerekir
Yani aslında 80286 segmentasyonu istiyorsun; bu zaten vardı ve istediğin şeyi yapamadı. Nedeni, o segment descriptor'ların da yazılım tarafından doğru yüklenmesi gerekmesiydi. Yazılım açısından sonuçta yine “sadece bir işaretçi” olduğu için aynı hatalara açıktı
Spekülatif yürütme söz konusu olduğunda, o zafiyeti gerçekten bir şey için kullanmak akıl almaz ölçüde hazırlık gerektirir. Pratikte işe yarar neredeyse tek yol, ilgili bilgisayara doğrudan erişip düşük seviyeli kod çalıştırmaktır. Tarayıcıda çalışan JS koduyla rastgele sırları sızdırmak gibi bir şey değil
Eğer özel bir sivil kuruluşun ya da devlet destekli bir yapının gerekli araştırma ve hedeflemeyi yapmasına değecek kadar değerli bir sistemse, en baştan yetkisiz rastgele kodun çalıştırılmasını engelleyen bir düzene sahip olmalıdır
Kişisel olarak performans artışını gerçekten hissettiğim için tüm azaltma önlemlerini kapatıyorum
Intel güvenlik duyurusu: https://www.intel.com/content/www/us/en/security-center/advi...
AMD donanımında da benzer bir açık olup olmadığını merak ediyorum. Spekülatif yürütme, paylaşımlı işlemci alanında yamaması çok zor bir zafiyet gibi göründüğünden, AMD’nin bundan nasıl kaçınabildiğini merak ediyorum
Değerlendirilen AMD ve ARM sistemlerinde sorun bulunmadığı söyleniyor
Kaynak: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
Bu belirli zafiyet Meltdown gibi Intel’e özgü görünüyor, ancak AMD de baştaki Spectre’ye karşı savunmasızdı
Ancak spekülatif yürütme motoru karmaşık olduğundan hatalar ve zafiyetler çok yaygın
AMD ve ARM’de de benzer hataların olması çok muhtemel. Intel’de bu tür hataların ne kadar uzun süre bulunmadan kaldığını düşünmek yeterli
Ne yazık ki gerçek çözüm, modern sistemlerde çalışan kodu yalıtamayacağımız gerçeğini kabul etmek; bu da bazı çok zengin şirketlerin iş modelleri için ölümcül olabilir
Yazılımda ortaya çıkabilecek bir sorunla aynı çözüm değil mi?
“Bu tür açıkları kapatmak için işlemci mikrokodunun özel bir güncellemesi gerekir. BIOS veya işletim sistemi güncellemesiyle yapılabildiğinden, Windows’un en son toplu güncellemelerinden biriyle PC’ye kurulması gerekir” deniyor; neden yalnızca Windows’tan bahsediliyor? Linux kullanıcıları ne olacak?
Dağıtımlar bunları buradan alıp otomatik dağıtacak şekilde yapılandırılmış durumda
Ancak bu belirli azaltımın zaten dahil edilip edilmediğini doğrulamak için neye bakmak gerektiğini pek bilmiyorum
CONFIG_MICROCODE/CONFIG_MICROCODE_INTEL) varAncak Intel’in, dağıtım yöneticilerinin paketi güncelleyebilmesi için gerekli mikrokod dosyalarını yayımlaması gerekiyor; sonrasında sistem güncellemesine dahil edilecektir
Intel’in toparlanmanın bir yolunu bulup bulamayacağını merak ediyorum. Piyasada kayda değer bir ürünü yok, Ar-Ge uzun zaman alıyor ve dökümhane işi rakiplerinin gerisinde kaldığı için sürekli bir zarar kaynağı
Üstelik x86, ARM donanımı karşısında giderek geriliyor ve artık Çin kaynaklı RISC-V de büyüyor. Elbette bir de ABD yarı iletken perspektifi var. Özellikle Covid sırasında yaşanan sorunlardan sonra ABD, Intel gibi kilit bir üreticinin çökmesine izin verir mi?
Durum iyi değil, ama sansasyonel anlatım gülünç düzeyde
Oyuncular Intel ürün kullanıcılarının yalnızca birkaç yüzdesini oluşturuyor, ama en çok bu taraftaki hikâyeleri duyuyoruz. Bir iki veri merkezi siparişi, Intel’in bir yılda sattığı tüm oyun CPU’larından daha büyük. Intel hâlâ veri merkezi pazarında iyi dayanıyor
Buna ek olarak Intel kurumsal dizüstü pazarını da hâlâ domine ediyor ve bu pazar da oyuncu pazarından epey daha büyük
Arm’ın geçen yıl veri merkezi pazar payı yalnızca %15’ti ve Windows pazarında da henüz büyük bir ilerleme kaydetmiş değil
Ürünlerden ayrı olarak, hissedar/iş perspektifinde günümüz finansal performansının nihai ürünleri giderek daha az yansıttığını düşündüğüm için bunu ayrı değerlendirmeye çalışıyorum; Intel’i batmasına izin verilmeyecek kadar büyüke yakın görüyorum
Doğru anlayıp anlamadığımı kontrol etmek istiyorum: Şu an itibarıyla başlıca tüm işletim sistemlerinde bu sorunu azaltan veya ilgili mikrokodu uygulayan yamalar yayımlanmış durumda mı?