Foreshadow – L1 Terminal Fault (L1TF) Speculative-Execution

Foreshadow Intel işlemcilerde ortaya çıkmış, ve speculative-execution olarak sınıflandırılan bir donanım açığıdır.  Bu açık, saldırganın kişisel bilgisayarlarda veya üçüncü party cloud’da konumlandırılan hassas bilgileri çalabilmesine olanak sağlıyor. Foreshadow’un iki versiyonu mevcut, orjinal olan atak Intel Software Guard Extensions (SGX)’dan veri çıkarmak üzerine bir dizayna sahip ve ikinci tür olan atak(Foreshadow-NG) ise Sanal makine (VM), hypervisor (VMM) ve işletim sistemleri (OS)’nin kernel ve SMM memorylerini etkilemekte.

Foreshadow :
SGX modern Intel CPU’larda bulunan ve tüm sistem saldırganın kontrolünde olsa dahi bilgisayarın kullanıcı verisini koruyabilmesini sağlayan yeni bir özellik. Spectre ve Meltdown açıklandığında genel bir inanış olarak SGX’in speculative execution saldırılarına karşı korumalı olduğu düşünülüyordu, ancak Foreshadow tüm dünyaya speculative execution’ın SGX-korumalı belleğin okunabildiğini ve aynı zamanda makinenin private attestation key’inin çıkarılabildiğini gösterdi. Daha da kötüsü SGX’in gizlilik özelliği olan attestation raporlarının, raporu imzalayanın kimliği ile bağlantılanamaması durumu. Bu durum, ele geçirilmiş tek bir SGX makinesinin tüm SGX ekosisteminin ele geçirilmesi için yeterli olmasına sebep olmakta.

Foreshadow-NG:

Foreshadow’a sebep olan açık incelenirken, Intel iki bağlantılı açık buldu ve bunları “L1 Terminal Fault” olarak adlandırdı ki biz buna Foreshadow-NG diyeceğiz. Bu atak işlemcinin L1 cache’inde yer alan bilginin okunabilmesine olanak sağlamakta. Bu bilgi SMM, İşletim sistemi kernel’ı veya hypervisor’e ait olabilir. Foreshadow-NG için en yıkıcı olan durum ise aynı third-party cloud ortamında koşan başka sanal makinelerin bilgilerininde okunabilmesine olanak vermekte. Yani bir atlama noktası olabilecek bir VM’e erişim sağlandıktan sonra tüm ortam erişime açık!

Benim Sistemime foreshadow yapılıp yapılmadığını tespit edebilir miyim?

Bu pek mümkün değil. Foreshadow tipik log dosyalarında iz bırakmamaktadır. Malicious bir driver yüklenirken log dosyalarında iz kalsa dahi sonradan bu logları temizlemesi pek ala mümkündür.

AMD/ARM işlemcilerde bu açık var mı?

Bu açık şuanda sadece SGX yapılandırmasını kullanan intel işlemcilerde tespit edilmiş durumda. Diğer vendorlarda benzer bir durum varsa bile şuan için bilmiyoruz.

Spectre & Meltdown için uygulanan patchler foreshadow’u etkiler mi?

Kısaca hayır. Spectre & Meltdown için uygulanan güvenlik önlemleri foreshadow ve foreshadow-NG için kesinlikle etkili değildir.

Bu ataklardan etkilenen CPU listesi:

• SGX yapılandırmasına sahip olan tüm işlemciler (intel atom işlemciler etkilenmemiştir)
• Intel Core™ i3/i5/i7/M processor (45nm and 32nm)
• 2nd/3rd/4th/5th/6th/7th/8th generation Intel Core processors
• Intel Core X-series Processor Family for Intel X99 and X299 platforms
• Intel Xeon processor 3400/3600/5500/5600/6500/7500 series
• Intel Xeon Processor E3 v1/v2/v3/v4/v5/v6 Family
• Intel® Xeon® Processor E5 v1/v2/v3/v4 Family
• Intel® Xeon® Processor E7 v1/v2/v3/v4 Family
• Intel® Xeon® Processor Scalable Family
• Intel® Xeon® Processor D (1500, 2100)

VMware vSphere Perspektifinden bakacak olursak neler yapılmalı ;

vSphere tarafını ilgilendiren Foreshadow-NG tipidir ve VMware tarafından iki adlandırmada sunulmaktadır. Sequential context & Concurrent context. Şuan ki intel işlemci yapısında fiziksel L1 Data Cache, hyperthreading açık bir core’da iki vCPU için paylaşımlı çalışmaktadır. Bu da eş zamanlı scheduling yapılırken ele geçirilmiş bir VM’in erişebildiği core’a gelip gelebilecek tüm VM datalarına erişmesini sağlayabilir.

Atak Tipleri :

• Sequential-context attack vector: kurban olmuş bir VM bu tipde L1’de önceden bulunan veya anlık olarak erişilmiş olan datayı okuma şansına sahiptir.
• Concurrent-context attack vector: kurban olmuş bir VM bu tipde L1’de anlık olarak çalıştırılan kodu (thread) okuma şansına sahiptir. (burada 2vCPU düşünün 1. vCPU da kurban VM 2.vCPU da çalıştırılan başka bir VM’in ya da hypervisorun datasını okuyabilir).

VMware Intel işlemcilerde bulunan bu açığı adreslemiş ve kapatmak için bizlere izlememiz gereken yolu sunmuş durumda:

• vSphere Güncelleme ve yamalarının uygulanması
• “ESXi Side-Channel-Aware Scheduler” isimli yeni özelliğin aktifleştirilmesi

Peki bu yeni özelliğin anlamı nedir?

Kısa bir süre önce CPU affinity konusunu anlatmış ve bizlere sunmuş olduğu kazanımlar/kayıplardan bahsetmiştim. Öyle görünüyor ki Intel’in bu açıklarından korunmak istiyorsak yeni yatırımlar yapmalıyız. Çünkü durum tam da affinity rule yazar gibi bir scheduling senaryosuna geldi. vSphere ortamında foreshadow-NG’yi engellemek için ESXi Side-Channel-Aware Scheduler parametresinin true olarak ayarlanması gerekmekte. Bu parametre ile CPU scheduler artık bir VM’in tek bir sanal core üzerinde çalışmasını garanti ediyor. Yani fiziksel X core’da çalışan bir VM düşünün Hyperthreading açık ve elimizde 2 tane vCPU bulunmakta tam bu durumda VM sadece 1 tanesinde calışacaktır ve diğerine thread göndermeyecektir. Bu da ortalama %70 yük dengesi olan bir ortam için %30 gibi bir potansiyel ek yük anlamına gelecektir ki ciddi bir tradeoff olarak karşımıza çıkmakta. Şimdilik ya güvenlikten ödün vereceğiz ya da fazla kaynak ayıracağız.

Ancak şunu belirtmek isterim ki VMware her zaman kullanıcı tarafında yer alan bakış açısıyla bizlere bu scheduling yapısının değişebileceğini söylemekte, hyperthreading’in sağladığı kazanımları gelecek yamalarda bizlere geri vermeyi görev edinmektedir. Bu yüzden heyecana kapılıp hyperthreading’i kapatmak gibi bir yol seçmenizi önermem. Bir yenisi daha gelene kadar tıpkı Meltdown Spectre gibi foreshadowda tarihin tozlu sayfalarında yerini alacaktır 🙂 Referans için şurayı kullanabilirsiniz : https://kb.vmware.com/s/article/55806

Bu açıkları kapatmak için izlenilmesi gereken yol şu şekilde :

1. Güncelleme Adımı

Gerekli patch’lere ulaşmak için şurayı kullanabilirsiniz : https://www.vmware.com/security/advisories/VMSA-2018-0020.html

2. Planlama Adımı

Bu adımda ESXi Side-Channel-Aware Scheduler enable edildiği takdirde dikkat etmeniz gereken birkaç durum mevcut detaylar şöyle :

• Hosttaki toplam fiziksel core sayısından daha fazla vCPU sahibi olan VM’ler. (Bir VM’e verilmiş vCPU toplam fiziksel core’u geçmemeli)
• CPU affinity veya NUMA ayarlanmış VM varsa bu ayarlar iptal edilmeli veya düzeltilmeli.
• Latency-sensitive VM’ler bu parametreden etkilenecektir.
• Ortalama CPU yükü %70 civarı olan bir hostta yük azaltımına gidilmeli.
• Host bazında custom CPU kaynak yönetimi varsa bunlar kaldırılmalı veya düzenlenmeli.
• Upgradeler uygunlandıktan sonra HA clusterda ortalama CPU kullanımı %100’ü geçebilir

3. Yeni Scheduler’i Aktifleştirme Adımı

Bu ayar host bazında yapılmakta olup her host için tek tek ayarlanması gerekmektedir.

1. vCenter’a bağlanın (web client veya VIClient).
2. Inventoryden hostu seçin.
3. Manage’e tıklayın (5.5/6.0) veya Configure (6.5/6.7).
4. Settings’e tıklayın.
5. Advanced System Settings’e tıklayın.
6. Edit’e basarak VMkernel.Boot.hyperthreadingMitigation parametresini aratın
7. Gelen ayarı true olarak değiştirin (default: false).
8. OK.
9. Bu ayar Reboot gerektirmektedir.

ESXCLI kullanarak aktifleştirmek için :

Hosta SSH ile bağlanarak aşağıdaki adımları uygulayabilirsiniz.

• esxcli system settings kernel list -o hyperthreadingMitigation (mevcut durumu görüntüler)
• esxcli system settings kernel set -s hyperthreadingMitigation -v TRUE (bu komut yeni scheduler’i aktif eder)
• reboot

Sonuç Olarak :

VMware Intel işlemcilerde çıkan bu açığı kapatmak için çok hızlı reaksiyon göstermiş kullanıcılarına gerekli tüm içeriği sağlamış durumda. Ancak spectre meltdown ile başlayan performans kaybı durumu concurrent-context düzeltmesi için aktif edilecek olan scheduler ile birlikte şimdilik kritik boyutlarda.. Aşağıya ilk izlenimlerle birlikte uygulanmış olan benchmark testlerini paylaşıyorum.

İlgili Açıklar kapatıldıktan sonra performans durumu :

Sequential-context açık kapamasından sonra :

Application Workload / Guest OS	Yamalardan sonraki performans kaybı
Database OLTP / Windows	3%
Database OLTP / Linux	3%
Mixed Workload / Linux	1%
Java / Linux	<1%
VDI / Windows	3%

Aşağıdaki test ise neredeyse full kapasite (ortalama 90% ve üzeri) bir hostta Scheduler enable edilirse performans ne olur sorusuna cevap vermekte.

Application Workload / Guest OS	Performans Kaybı
Database OLTP / Windows	32%
Database OLTP / Linux (with vSAN)	32%
Mixed Workload / Linux	25%
Java / Linux	22%
VDI / Windows	30%

OLTP database performans testi :

• 90% maksimum utilization olarak varsayılmıştır.

Yukarıdaki grafikten anlamamız gereken şey eğer mevcut CPU utilization değerimiz %60 civarında veya daha altında ise ufak performans kayıpları ile utilizasyon’u yükseltmeyi göze alarak açıktan kurtulabiliriz. Eğerki değerleriniz 60% üzerinde ise ciddi yavaşlama ile karşılaşmanız pek muhtemel.

Bir yerlerde hata yaptıysam affola derlemek zor oldu..

Referans dökümanlar : geliyor….