Zenbleed tekniği

 (lock.cmpxchg8b.com)
2 puan yazan GN⁺ 2023-07-25 | 1 yorum | WhatsApp'ta paylaş
  • Zenbleed, AMD Zen 2 ailesinde hatalı tahmin edilen vzeroupper geri yüklemesini kötüye kullanarak aynı fiziksel çekirdeğin vektör kayıt dosyasında kalan verilerin okunabilmesini sağlayan bir zafiyettir
  • CVE-2023-20593 olarak kaydedilmiştir ve Ryzen 3000/4000/5000 with Radeon Graphics/7020 with Radeon Graphics, Ryzen PRO, Threadripper 3000, EPYC “Rome” gibi Zen 2 ürün aileleri etki kapsamına girer
  • Saldırı, XMM Register Merge Optimization, register rename ve hatalı tahmin edilen vzeroupper'ın dar bir zaman penceresi içinde art arda gelmesiyle mümkün olur; strlen, memcpy, strcmp gibi temel işlemler de gözlemlenebilir hedefler olabilir
  • Optimize edilmiş varyant, çekirdek başına saniyede yaklaşık 30KB sızdırabilir ve VM, sandbox, container, process sınırlarını aşarak aynı fiziksel çekirdekteki kayıt dosyası paylaşımı sorun yaratır
  • AMD mikro kod güncellemesinin uygulanması önerilir; geçici olarak DE_CFG[9] chicken bit ayarlanabilir, ancak performans maliyeti olabilir ve yalnızca SMT'yi devre dışı bırakmak yeterli değildir

Zenbleed'in hedef aldığı yürütme birimi

  • x86-64 CPU'larda 128 bit XMM vektör kayıtları bulunur ve modern CPU'lar bunları 256 bit YMM, 512 bit ZMM'ye kadar genişletir
  • Vektör kayıtları yalnızca sayısal hesaplamalarda değil, glibc'nin strcmp, memcpy, strlen gibi standart C kütüphanesi fonksiyonlarında da kullanılır
  • glibc'nin AVX2 ile optimize edilmiş strlen uygulaması, bir dizgede ilk nul baytının konumunu bulmak için birden çok vektör komutunu birleştirir
    • vpxor xmm0,xmm0,xmm0 ile ymm0'ın alt kısmını 0 yapar
    • vpcmpeqb ymm1,ymm0,[rdi] ile dizge baytlarını 0 baytla karşılaştırır
    • vpmovmskb eax,ymm1 ile karşılaştırma sonucunu genel amaçlı kayda taşır
    • tzcnt eax,eax ile ilk nul baytının konumunu hesaplar

vzeroupper ve kayıt dosyası

  • vzeroupper, vektör kayıtlarının üst bitlerini 0 yapan bir komuttur
  • XMM ve YMM kayıtları birlikte kullanıldığında XMM kayıtları tam genişliğe yükseltilir ve bu süreçte üst bit bağımlılıkları oluşabilir
  • glibc, gereksiz duraksamaları önlemek için vzeroupper kullanarak sonraki sonucun üst bitlere bağımlı olmamasını sağlar
  • CPU, her kaydı sabit bir fiziksel konumda tutmaz; fiziksel kayıt ataması Register File ve Register Allocation Table ile yönetilir
  • XMM kaydını 0 yaparken CPU gerçek bitleri depolamak yerine RAT içinde z-bit işaretini ayarlayabilir
    • Bu işaret, YMM kaydının üst ve alt kısımlarına bağımsız olarak uygulanabilir
    • vzeroupper, z-bit ayarlandıktan sonra kayıt dosyasındaki ilgili kaynağı serbest bırakabilir

Spekülatif yürütme geri yüklemesinde ortaya çıkan zafiyet

  • Modern CPU'lar spekülatif yürütme kullandığı için hatalı tahmin edilen dallarda çalıştırılan işlemler geri alınmalıdır
  • Sorun şu ki, hatalı tahmin edilen vzeroupper çalıştıktan sonra geri yükleme yapılırken yalnızca z-bit'in geri alınması, önceden serbest bırakılmış kayıt dosyası kaynak durumunu doğru şekilde geri getirmeye yetmez
  • Hassas zamanlama ile bazı işlemcilerin hatalı tahmin edilen vzeroupper sonrasında yanlış şekilde geri yükleme yapması sağlanabilir
  • Bu teknik CVE-2023-20593'tür ve tüm Zen 2 ailesini etkiler
    • AMD Ryzen 3000 Series Processors
    • AMD Ryzen PRO 3000 Series Processors
    • AMD Ryzen Threadripper 3000 Series Processors
    • AMD Ryzen 4000 Series Processors with Radeon Graphics
    • AMD Ryzen PRO 4000 Series Processors
    • AMD Ryzen 5000 Series Processors with Radeon Graphics
    • AMD Ryzen 7020 Series Processors with Radeon Graphics
    • AMD EPYC “Rome” Processors

Saldırı koşulları ve sızıntı kapsamı

  • Hatanın tetiklenmesi için XMM Register Merge Optimization, register rename ve hatalı tahmin edilen vzeroupper'ın hassas bir zaman penceresinde arka arkaya gelmesi gerekir
  • Örnek komut dizisi şu yapıyı kullanır
    • vcvtsi2s{s,d} ile merge optimization tetiklenir
    • vmovdqa ile register rename tetiklenir
    • Koşullu dal gerçekte taken olsa da CPU not-taken yolunu tahmin ederse vzeroupper hatalı tahminle çalışır ve hata ortaya çıkar
  • strlen, memcpy, strcmp gibi temel işlemler de vektör kayıtları kullandığı için sistemin herhangi bir yerinde çalışırken gözlemlenebilir hedefler olabilir
  • Aynı fiziksel çekirdekte register file paylaşıldığı için başka VM'ler, sandbox'lar, container'lar ve process'ler de etki alanına girer
  • İki hyperthread aynı fiziksel register file'ı paylaşır
  • Optimize edilmiş saldırı varyantı çekirdek başına saniyede yaklaşık 30KB sızdırabilir; bu hız, oturum açmış kullanıcıların şifreleme anahtarlarını ve parolalarını izlemek için yeterlidir
  • Teknik danışmanlık ve ilgili kodlar Google'ın security research repository deposunda yayımlanmıştır
  • Test kodu Linux için sağlansa da hata belirli bir işletim sistemine bağlı değildir; tüm işletim sistemleri etkilenir

Keşif yöntemi: CPU fuzzing ve Oracle Serialization

  • Zafiyet fuzzing ile keşfedildi
  • CPU endüstrisi de donanım kusurlarını bulmak için silikon üretimi sonrasında doğrulama (Post-Silicon Validation) yapar
  • Genel coverage tabanlı fuzzing'in aksine CPU'larda kod kapsamasına doğrudan karşılık gelen bir ölçüm yoktur
  • Bunun yerine performance counters kullanılarak ilginç mimari olaylar fuzzer'a geri bildirim olarak verilir
    • Bu yöntemle tesadüfen bulunması zor komut dizileri keşfedilebilir
    • merge optimization gibi özellikler otomatik olarak bulunabildi
  • Yazılım fuzzing'i genelde crash arar, ancak rastgele üretilmiş CPU programlarında crash'in kendisi doğru davranış da olabilir
  • Mevcut yaklaşımlardan biri olan reversi, her rastgele komut için ters işlemi üretir ve son durumun başlangıç durumundan farklı olup olmadığını kontrol eder
    • x86 gibi CISC mimarilerinde test senaryosu üretimi karmaşık hale gelir
  • Başka bir yöntem, oracle kullanarak test CPU'sunun sonuçlarını başka bir CPU veya simülatörle karşılaştırmaktır
  • Oracle Serialization bu iki fikri birleştirir
    • Rastgele program üretildikten sonra otomatik olarak serileştirilmiş biçime dönüştürülür
    • store/load barrier, speculation fence, cache line flush gibi serileştirme öğeleri eklenir
    • Orijinal ve serileştirilmiş program farklı performans özelliklerine sahip olsa da aynı çıktıyı üretmelidir
  • Son durumlar eşleşmiyorsa bu bir mikro mimari yürütme hatası olabilir; işte bu tutarsızlık Zenbleed'in bulunmasına yol açtı

Önlemler ve tespit sınırlamaları

  • Zafiyet 15 Mayıs 2023'te AMD'ye bildirildi
  • AMD, etkilenen işlemciler için mikro kod güncellemesi yayımladı
  • BIOS veya işletim sistemi sağlayıcınız bu güncellemeyi içeren yamayı zaten sunuyor olabilir
  • Önerilen önlem mikro kod güncellemesini uygulamaktır
  • Güncelleme uygulanamıyorsa yazılımsal geçici çözüm olarak DE_CFG[9] chicken bit ayarlanabilir
    • Performans maliyeti olabilir
    • Linux'ta msr-tools ile tüm çekirdeklere uygulanabilir
    • FreeBSD'de cpucontrol(8) kullanılır
    • Diğer işletim sistemlerinde MSR ayarlama yöntemi bilinmiyorsa üretici desteği gerekir
  • Yalnızca SMT'yi devre dışı bırakmak yeterli değildir
  • Güvenilir bir saldırı tespit tekniği bilinmemektedir
    • Çünkü özel bir sistem çağrısı veya ek yetki gerektirmez
    • vzeroupper'ın uygunsuz kullanımını statik olarak tespit etmek de mümkün değildir

İlgili okumalar

1 yorum

 
GN⁺ 2023-07-25
Hacker News görüşleri

  • Bu gerçekten harika ve VM’de çalıştırmanın güvenli olduğu anlamına gelmediğinin klasik bir örneği sayılabilir
    VM’den kaçış hep bilinen bir şeydi, ama bu kez kaçış olmadan da çalıştırması basit, getirisi yüksek, geniş ölçekli bir açık söz konusu
    Bu hatanın microcode ile düzeltilmesi, benzer başka hataların olmadığı anlamına gelmez. Birçok 0-day, kamuya açıklanmadan çok önce paralı black hat’ler tarafından biliniyor olabilir
    Son yıllarda keşfedilen CPU açıkları:
    https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
    https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
    https://aepicleak.com/
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#SGAxe
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#LVI
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#Plundervolt
    https://en.wikipedia.org/wiki/Software_Guard_Extensions/…
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#Enclave_attack
    https://en.wikipedia.org/wiki/Software_Guard_Extensions/…
    https://www.vusec.net/projects/crosstalk/
    https://en.wikipedia.org/wiki/Hertzbleed
    https://securityweek.com/amd-processors-expose-sensitive-data-new-squi…

    • Sorun, VM’in artık gerçek bir sanal makine olmamasında
      Komutları büyük bir switch ifadesiyle yorumlamak yerine gerçek CPU üzerinde çalıştırıyor ve CPU’nun veri ya da komutların çakışmadığını garanti ettiğini varsayan bazı donanım bayraklarına dayanıyor. CPU söz veriyor, ama pratikte bu tür sözleri tutmak zor
    • Meltdown/Spectre ile karşılaştırma biraz yanıltıcı olabilir
      Onlarda CPU yapması gerekeni tam olarak yaptığı halde zamanlama tabanlı olarak mümkün hale gelen tamamen yeni bir saldırı türü vardı; Zenbleed ise olmaması gereken verinin register’da kalması şeklindeki geleneksel bir hataya daha yakın
    • Güvenilmeyen kodu sandbox’ta, container’da ya da VM’de nerede çalıştırırsanız çalıştırın, en azından Rowhammer’dan beri güvenli değildi
      Bu açıkların çoğunun yazılım tarafıyla donanım tarafının birbiriyle düzgün konuşmamasından kaynaklandığını düşünüyorum. Yazılım tarafı izolasyon garantileri hakkında varsayımlarda bulunuyor, donanım tarafı ise bu varsayımlar ortaya çıktığında yeterince uyarıda bulunmuyor
    • Sonuçta bunların çoğu branch prediction ile ilgili değil mi diye düşünüyorum
      Branch prediction doğası gereği o kadar karmaşık ki her zaman bu tür açıklara maruz kalmaya mahkûm olabilir; ya da kod yollarını ve komut yürütmeyi sezgisel olarak anlama biçimimizden o kadar farklı ki, çok geç olmadan sınır koşullarını akla getirmek zorlaşıyor gibi geliyor
      CPU mimarisinin karmaşıklığı bir noktadan sonra akıl yürütmeyi fazla zorlaştırıp, daha basit tutmanın performans kaybını kabullenmemize yol açar mı?
    • Bazı şirketlerde internete açık/DMZ VM’leri ile dahili VM’lerin aynı hypervisor üzerinde karıştırıldığını gördüm
      Bunu işaret edip ayrı hypervisor’larla air gap yapılmasını önerdim, ama her seferinde görmezden gelindi. Sonunda zararı onlara olacak gibi

  • Exploit tar dosyasının README’sinde daha fazla ayrıntı ve kamuya açıklama takvimi yer alıyor
    2023-05-09 CPU doğrulama hattının bir bileşeni anormal sonuç üretti
    2023-05-12 Sorun başarıyla izole edilip yeniden üretildi, inceleme sürdü
    2023-05-14 Sorunun kapsamı ve ciddiyeti anlaşıldı
    2023-05-15 Kısa bir durum raporu hazırlanıp AMD PSIRT ile paylaşıldı
    2023-05-17 AMD raporu doğruladı ve yeniden üretilebilir olduğunu kabul etti
    2023-05-17 Güvenilir bir PoC geliştirmesi tamamlanıp AMD ile paylaşıldı
    2023-05-19 Başlıca kernel ve hiper yönetici sağlayıcılarına bildirilmeye başlandı
    2023-05-23 AMD’den Rome için beta mikro kod güncellemesi alındı
    2023-05-24 Güncellemenin sorunu düzelttiği doğrulanıp AMD’ye bildirildi
    2023-05-30 AMD, iş ortaklarına güvenlik duyurusu gönderdiğini bildirdi
    2023-06-12 Durum ve ayrıntıları görüşmek üzere AMD ile toplantı yapıldı
    2023-07-20 AMD, mutabık kalınan ambargo tarihinden önce yamayı habersiz yayımladı
    2023-07-21 Düzeltme yayımlandığı için, başlıca dağıtımlara firmware paket güncellemesi hazırlamalarının gizli olarak bildirilmesi önerildi
    2023-07-24 Kamuya açık disclosure

  • Bu gerçekten korkutucu. Zen 2 makinem olan Ryzen 3600’de exploit’i yetkisiz kullanıcı olarak çalıştırdım; arka plandaki metin düzenleyiciye (Kate) bir string kopyalayıp yapıştırınca birkaç saniye içinde o string’in parçaları zenbleed çıktısına kaydedildi
    Neyse ki bu exploit belirli bir assembly rutinine büyük ölçüde bağlı, bu yüzden tarayıcıdaki JS veya WASM üzerinden kötüye kullanılmasının çok zor olacağını düşünüyorum. Aksi hâlde, kötü amaçlı bir sekmeyi birkaç saat arka planda açık bırakmak bile kolayca sızıntıya yol açardı
    Fedora bakımcısının yeni mikro kodu dağıtmasını ve kernel’in bunu önyükleme sırasında güncelleyebilmesini bekliyorum

    • Buradaki en az bir kişi bunun JavaScript ile de yeniden üretilebildiğini söylüyor: https://news.ycombinator.com/item?id=36849767
    • Kendi Zen 2 makinemde de denedim; aynı saldırı KVM içinde çalıştırıldığında da işe yarıyor
    • JS’te yöntem bir kez bulunursa oldukça geniş şekilde uygulanma ihtimali var gibi görünüyor
      Aynı zamanda V8 ve SpiderMonkey için yazılım yamalarının daha erken gelip ek hafifletme sağlamasını umuyorum
      Yine de JS exploit’inin veriyi dışarı sızdırmak için de bir yönteme ihtiyacı olacak; bunu tamamen gizlemek epey zor görünüyor
    • PoC’nin nasıl build edileceğini bilmiyorum. Ubuntu’da "No such file or directory" ve error 127 alıyorum

  • OpenBSD’nin son 3 gün içinde AMD mikro kod yüklemeyi eklemiş olması tesadüf değilmiş gibi geliyor
    https://news.ycombinator.com/item?id=36838511

  • AMD’nin etkilenen işlemciler için mikrokod güncellemesi yayımladığı ifadesi pek doğru görünmüyor
    AMD, family 17h model 0x31 ve 0xa0 için mikrokod güncellemesi[0] yayımladı; WikiChip[1]’e göre bunlar Rome, Castle Peak ve Mendocino’ya karşılık geliyor
    Şu ana kadar Renoir, Grey Hawk, Lucienne, Matisse, Van Gogh için mikrokod güncellemesi görünmüyor. Neyse ki yeni kernel bunlar için yalnızca chicken bit’i ayarlayabiliyor ve gerçekten de bunu yapıyor[2]
    [0] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
    [1] https://en.wikichip.org/wiki/amd/cpuid#Family_23_.2817h.29
    [2] https://github.com/torvalds/linux/commit/522b1d69219d8f08317...

  • İlgili kısma bakınca, bu teknik CVE-2023-20593 ve tüm Zen 2 sınıfı işlemcilerde çalışıyor; en azından şu ürünler buna dahil
    AMD Ryzen 3000 Series Processors
    AMD Ryzen PRO 3000 Series Processors
    AMD Ryzen Threadripper 3000 Series Processors
    AMD Ryzen 4000 Series Processors with Radeon Graphics
    AMD Ryzen PRO 4000 Series Processors
    AMD Ryzen 5000 Series Processors with Radeon Graphics
    AMD Ryzen 7020 Series Processors with Radeon Graphics
    AMD EPYC “Rome” Processors

    • Bunun “yalnızca Zen 2’de doğrulandı” anlamına mı geldiğini, yoksa sorunun kesin olarak yalnızca bu mimariyle sınırlı olduğu anlamına mı geldiğini merak ediyorum
      Aynı tekniğin ya da benzer bir tekniğin daha eski Zen/Zen+ veya daha sonraki Zen 3 çekirdeklerinde de çalışma ihtimali var ama henüz kanıtlanmamış olabilir mi?
    • Benim 2700X’im kıl payı kurtulmuş gibi. 7020 serisinin etkilenip 7000 serisinin etkilenmediği varsayımı doğruysa tabii
    • PlayStation 5 için durum ne, merak ediyorum. Xbox ve Valve’ın o cihazı için de aynı şekilde
    • Radeon’suz Ryzen 5000 savunmasız değil mi? Bu işlemciler Zen 3 gibi görünüyor
      Benim AMD Ryzen 9 5950x Desktop Processor da Zen 3 göründüğüne göre sorun yok gibi
      Güvenilmeyen işler çalıştırmıyorum ama şans hazırlıklı olandan yanadır derler
    • Bu arada Ryzen 3000 APU Zen 2 değil

  • Site trafik altında çöküyor: https://web.archive.org/web/20230724143835/https://lock.cmpx...

    • Basit bir statik HTML sayfası; 2023’te bir statik sitenin trafikten ölmesi nasıl mümkün, bilmiyorum
      Çoğu durumda HN trafiği saniyede 100 sayfa görüntülemeye bile pek yaklaşmaz
    • Daha hızlı bağlantı: https://archive.is/QAwvQ
    • Orijinal de sonunda yükleniyor. Ortama göre değişebilir

  • https://www.amd.com/en/resources/product-security/bulletin/a...
    AMD güvenlik duyurusuna göre EPYC dışı CPU’lar için firmware güncellemesi yıl sonuna kadar gelmeyecek. O zamana kadar kullanıcıların chicken bit’i kapatıp performans kaybını göze alması mı gerekiyor?

    • AMD aklını mı kaçırdı? Bu orta seviye ciddiyet değil

  • Harika olduğu kadar korkutucu. 10 MB’lık örneği 1 dakika çalıştırınca Bitwarden parolamın bir kısmını, ssh oturum açma parolamı ve banka kimlik bilgilerimin parçalarını “sızdırabildim”; kolayca yeniden oluşturulabiliyorlardı

  • Yazı gerçekten çok iyiydi. Rastgele üretim programının doğru çalışıp çalışmadığının nasıl anlaşılabileceğini ele alan kısmı özellikle beğendim
    Bariz yaklaşım, bunu başka bir işlemci ya da simülatör gibi bir oracle üzerinde çalıştırıp aynı şekilde davranıp davranmadığına bakmaktır
    Ancak dar bir zamanlama aralığındaki mikro mimari etkileri kontrol etmek için aynı programı çeşitli stall, fence, nop vb. ekleyerek de yazabilirsiniz. Tek iş parçacıklı kodda bunlar çıktıyı etkilememelidir, ancak CPU içinde mikro mimari düzeyde oldukça farklı işler yapılmasına yol açar. Böylece CPU kendi kendisinin oracle’ı olabilir

    • Bu kısım gerçekten ilginçti; özellikle yazılım fuzzing’i ile donanım fuzzing’i arasındaki fark hoşuma gitti
      chicken bit de hoşuma gitti