AWS Firecracker VMM'nin Mikro Mimari Güvenliği: Mikro Mimari Saldırı ve Savunmaların Analizi

Bağlantı Tablosu

• Özet ve Giriş
• Arka plan
• Tehdit Modelleri
• Havai Fişek Muhafaza Sistemlerinin Analizi
• Firecracker Mikrovm'lerinde Mikro Mimari Saldırı ve Savunmaların Analizi
• Sonuç, Teşekkür ve Referanslar

5. Havai Fişek MİKROVMLERİNDE MİKROMİMARİ SALDIRI VE SAVUNMALARIN ANALİZİ

Bu bölümde, Firecracker mikroVM'leri üzerindeki bir dizi mikro mimari yan kanal ve spekülatif saldırı PoC'lerine ilişkin analizimizi sunuyoruz. Bu PoC'leri çıplak donanımda ve Firecracker örneklerinde test ediyoruz ve ilgili mikro kod savunmalarını çeşitli senaryolarda test ediyoruz. Testlerimizi Intel Skylake 4114 CPU'lu bir sunucuda gerçekleştiriyoruz

sanallaştırma donanım uzantılarına sahip ve SMT etkin. CPU, 0x2006b06[2] mikro kod sürümünde çalışır. Ana işletim sistemi, Linux 5.10 çekirdeğine sahip Ubuntu 20.04'tür. Hızlı başlangıç kılavuzunu[3] takip ederken Amazon tarafından sağlanan Linux çekirdeği 5.4 ile bir Ubuntu 18.04 misafirini çalıştırmak için Temmuz 2023 itibarıyla en son sürüm olan Firecracker v1.0.0 ve v1.4.0'ı kullandık.

Özetle, AWS Firecracker ile sağlanan önerilen üretim ana bilgisayar kurulumu, kiracıları kötü niyetli komşulardan koruma konusunda yetersizdir. Bu nedenle Firecracker iddia ettiği izolasyon garantilerini sağlamada başarısız oluyor. Bunun nedeni ise

(1) yalnızca mikroVM'lerde çalıştırıldığında yararlanılabilir hale gelen bir Medusa varyantını belirliyoruz. Ayrıca önerilen karşı önlemler, yan kanalı veya diğer Medusa varyantlarının çoğunu hafifletmek için gerekli adımları içermemektedir.

(2) önerilen karşı önlemleri uygularken kiracıların Spectre-PHT veya Spectre-BTB yoluyla tetiklenen bilgi sızıntılarına karşı gerektiği gibi korunmadıklarını gösteriyoruz. Spectre-PHT çeşitleri, SMT devre dışı bırakıldığında bile sorun olmaya devam ediyor.

(3) Firecracker v1.0.0 ve v1.4.0 arasında PoC performansı açısından hiçbir fark gözlemlemedik.

Firecracker'ın sağladığı sanallaştırma katmanının mikro mimari saldırılar üzerinde çok az etkisinin olduğu ve Firecracker'ın sistem güvenliği önerilerinin yetersiz olduğu sonucuna varıyoruz.

5.1 Medusa

Medusa [37] yan kanalları için Moghimi'nin PoC'lerini [35] (Intel tarafından MDS'nin MLPDS varyantları olarak sınıflandırılmıştır [25]) test sistemimizin çıplak metali üzerinde ve Firecracker VM'lerinde değerlendirdik. Bölüm 2.4.2'de açıklanan bilinen üç varyantın her biri için sızdıran bir PoC vardır. PoC kütüphanesinden iki kurban programı kullandık:

• “Blok Yazma” programı büyük miktarda ardışık veriyi bir döngüye yazar (böylece işlemci tekrarlanan depoları belirleyip bunları birleştirir).

• “REP MOV” programı benzer bir işlemi gerçekleştirir, ancak bir döngüde daha küçük veri bloklarını hareket ettiren birçok talimat yerine REP MOV talimatı kullanır.

5.1.1 Sonuçlar. Tablo 1, çekirdekteki tüm mikro mimari korumaların devre dışı bırakılmasıyla verilerin başarıyla sızdırıldığı durumları göstermektedir. Soldaki iki sütun, üç Medusa PoC'nin ve dahil edilen iki kurban programının olası kombinasyonlarını göstermektedir. Sağdaki sütunlar, hangi yapılandırmaların çıplak donanımda ve paralel Firecracker örneklerinde çalışan gizli ve sızdıran programla çalıştığını gösterir. En önemlisi, Önbellek Dizine Ekleme varyantında Blok Yazma sırrı yalnızca Firecracker ile çalışır. Bunun nedeni muhtemelen sanal makinenin sağladığı bellek adresi sanallaştırmasıdır: konuk yalnızca KVM tarafından eşlenen sanal bellek bölgelerini görür ve KVM, bellek erişim talimatlarını yakalar ve konuk adına işlemleri yönetir.

Çıplak metal ve Firecracker VM'lerinde saldırgan ve kurban PoC'sinin her kombinasyonuna karşı mds ve nosmt savunmalarının etkinliğini test ettik. Tablo 2, çıplak metal ve Havai Fişek senaryolarında Medusa saldırılarını önlemek için gerekli korumaları listelemektedir. Firecracker'daki dört güvenlik açığından yalnızca biri yalnızca nosmt tarafından hafifletilir ve çoğu Linux dağıtımı varsayılan olarak etkinleştirilmiş olarak gönderilse de AWS, mds korumasının etkinleştirilmesini açıkça önermez. Yani çok kiracılı bir bulut platformu, Firecracker'ı AWS'nin önerilen güvenlik önlemleriyle uyumlu bir şekilde kullanıyor olabilir ve yine de Firecracker VMM'nin kullanıcının verilerini sızdırdığı durum da dahil olmak üzere Medusa değişkenlerinin çoğuna karşı savunmasız olabilir. aksi takdirde sızdırılamaz.

5.2 RIDL ve Daha Fazlası

Bu bölümde, van Schaik ve arkadaşlarının 2019 makalesinin [50] yanı sıra sağlanan RIDL PoC programlarının [51] bir değerlendirmesini sunuyoruz. RIDL, CPU içindeki arabelleklerden (önbellekten veya bellekten değil) gelen spekülatif yüklerden yararlanan bir MDS saldırıları sınıfıdır. RIDL PoC deposu ayrıca makalenin sonraki eklerinde yayınlanan saldırı örneklerinin yanı sıra Fallout MDS saldırısının bir çeşidini de içerir.

5.2.1 Sonuçlar. Tablo 3, test ettiğimiz RIDL PoC'ler hakkında bazı temel bilgileri ve ilgili karşı önlemlerin saldırıları önlemedeki etkinliğini göstermektedir. Amazon'un Firecracker microVM sisteminin artırılmış donanım güvenliğine ilişkin iddialarını değerlendirmek için çıplak donanıma ve Firecracker'a yapılan saldırıları karşılaştırdık. Firecracker sistemi üzerindeki testler için, ana sistem (H) ve Firecracker konuk çekirdeği (VM) üzerinde etkinleştirilen karşı önlem bayrakları arasında ayrım yapıyoruz. Nosmt ve mds çekirdek bayraklarının yanı sıra kaslr, pti ve l1tf dahil diğer ilgili bayrakları da test ettik (bkz. bölüm 2.4.4, [21]), ancak bunların bu programların herhangi biri üzerinde bir etkisi olduğunu bulamadık. Üzerinde test ettiğimiz CPU, tsx_async_abort çekirdek işaretini gereksiz kılan mds azaltmayı içerdiğinden tsx_async_abort azaltmasını hariç tuttuk [20].

Genel olarak mds korumasının RIDL saldırılarının çoğuna karşı yeterince koruma sağlamadığını gördük. Ancak SMT'nin devre dışı bırakılması bu istismarların çoğunu azaltır. Bu, Intel'in [25] ve Linux geliştiricilerinin [21] hiper iş parçacığı üzerinden MDS saldırılarını önlemek için SMT'nin devre dışı bırakılması gerektiğine dair açıklamalarıyla tutarlıdır. Bu PoC'ler arasındaki iki aykırı değer, ana bilgisayarda hem nosmt hem de mds gerektiren hizalama_yazma ve yalnızca mds karşı önlemleriyle hafifletilen pgtable_leak_notsx'tir. Hizalama_yazmasına dayanan sızıntı, spekülasyonu tetiklemek için sayfa tablosu hatası sızıntısı yerine bir hizalama hatası kullanır [50]. RIDL makalesi [50] ve Intel'in ilgili VRS istismarına ilişkin belgeleri [26], bu saldırıyı diğer PoC'lerde bulunan sayfa hatası tabanlı MFBDS saldırılarından tam olarak neyin farklılaştırdığı konusunda belirsizdir, ancak deneysel bulgularımız sızıntının mikro mimari mekanizmasının belirgin. pgtable_leak_notsx davranışının basit ve makul bir açıklaması vardır ve bu, bu PoC'ler arasında tek bir önemli nedenden ötürü benzersizdir: bu, tek bir iş parçacığından sızmak yerine, güvenlik sınırlarını aşan (sayfa tablosu değerlerini çekirdekten sızdıran) tek istismardır. başka bir konu. Çoklu iş parçacığının devre dışı bırakılmasının bu tek iş parçacıklı istismar üzerinde çok az etkisi olacağı açıktır. Bununla birlikte, mds karşı önlemi, aynı iş parçacığı içinde çekirdek ayrıcalığı yürütmesinden kullanıcı ayrıcalıklı yürütmeye geçmeden önce mikro mimari arabellekleri temizler ve saldıran kullanıcı kodunun sızdırmasından önce çekirdek kodu tarafından erişilen sayfa tablosu verilerini LFB'den siler.

Medusa'nın aksine, bu PoC'lerin çoğu AWS'nin smt'yi devre dışı bırakma önerisiyle hafifletiliyor. Ancak Medusa'da olduğu gibi Firecracker VMM'nin kendisi de bu saldırılara karşı hiçbir mikro mimari koruma sağlamamaktadır.

5.3 Hayalet

Daha sonra Spectre güvenlik açıklarına odaklanıyoruz. Spectre saldırılarının ilk keşfedilmesinden bu yana pek çok karşı önlem geliştirilmiş olsa da bunların birçoğu ya (önemli) bir performans cezasıyla birlikte geliyor ya da saldırıyı yalnızca kısmen hafifletiyor. Öyleyse,

sistem operatörleri sıklıkla performans ve güvenlik arasında bir tercih yapmak zorunda kalır. Bu bölümde, daha önce açıklanan her iki tehdit modelinde de Firecracker kiracılarının kullanabileceği Spectre saldırı yüzeyini değerlendiriyoruz. Geniş Spectre saldırı yelpazesini değerlendirmek için [15]'te sağlanan PoC'lere güveniyoruz. Spectre-PHT, Spectre-BTB ve SpectreRSB için deponun her biri dört PoC içerir. Saldırganın BPU'yu yanlış yönlendirme şekli bakımından farklılık gösterirler. Dört olasılık şunlardır: (1) aynı süreç - saldırgan, BPU'yu yanlış yönlendirmek için kurban süreci veya girdileri üzerinde kontrole sahiptir - (2) çapraz süreç - saldırgan, şube tahminlerini etkilemek için kendi kodunu ayrı bir süreçte çalıştırır. kurban süreci – (a) yerinde – saldırgan, kurban sürecinde yanlış tahmin edilmesini istediği hedef dalla aynı sanal adreste bulunan dal talimatıyla BPU'yu yanlış yönlendirir – (b) kurban sürecinde yanlış tahmin edilmesini ister yer – saldırgan, kurban sürecindeki hedef dallarla uyumlu adreslerde bulunan şube talimatlarıyla BPU'yu yanlış yönlendirir.

(1) aynı süreç: Saldırganın, BPU'yu yanlış yönlendirmek için kurban süreci veya girdileri üzerinde kontrolü vardır,

(2) çapraz süreç: saldırgan, kurban sürecinin dal tahminlerini etkilemek için kendi kodunu ayrı bir süreçte çalıştırır,

(3) yerinde: Saldırgan, kurban sürecinde yanlış tahmin edilmesini istediği hedef şubeyle aynı sanal adreste bulunan şube talimatıyla BPU'yu yanlış yönlendirir.

(4) yerinde olmayan: saldırgan, kurban sürecindeki hedef dallarla uyumlu adreslerde bulunan şube talimatlarıyla BPU'yu yanlış yönlendirir.

İlk iki ve son iki durum diktir, dolayısıyla her PoC bunlardan ikisini birleştirir. Spectre-STL için yalnızca aynı işlem varyantları bilinmektedir, bu nedenle bu durumda depo yalnızca iki PoC sağlar. VM'ler arası deneyler için, yanlış eğitim için kullanılan uyumlu adresleri bulmayı kolaylaştırmak amacıyla ana bilgisayar ve konuk çekirdeklerin yanı sıra ana bilgisayar ve konuk kullanıcı düzeyi için devre dışı bırakılan adres alanı düzeni rastgeleleştirmesi.

5.3.1 Sonuçlar. Ana bilgisayar sisteminde ve Firecracker VM'lerinde AWS tarafından önerilen karşı önlemlerin [8] (kullanılan Linux çekirdekleri için varsayılan değer, bkz. Şekil 5) etkinleştirilmesiyle, Spectre-RSB'nin hem ana bilgisayarda hem de VM'lerin içinde ve genelinde başarılı bir şekilde hafifletildiğini görüyoruz. (bkz. Tablo 4). Öte yandan Spectre-STL, Spectre-BTB ve Spectre-PHT belirli durumlarda bilgi sızıntısına izin verdi.

Spectre-STL için PoC'ler sızıntıyı gösteriyor. Ancak sızıntı yalnızca aynı süreç ve aynı ayrıcalık düzeyinde meydana gelir. Hiçbir çapraz süreç değişkeni bilinmediğinden Spectre-STL için çapraz VM senaryosunu test etmedik. Kullanıcıdan kullanıcıya tehdit modelimizde, çapraz süreç değişkenleri bilinmediğinden Spectre-STL olası bir saldırı vektörü değildir. İki kiracı iş yükü aynı VM içinde süreç içi izolasyonla yalıtılsa bile Spectre-STL hala geçerli bir saldırı vektörü olabilir. Kullanıcıdan ana bilgisayara modelinde Spectre-STL, mevcut Linux çekirdeklerinde bulunan ve varsayılan olarak etkin olan karşı önlemlerle hafifletilir.

Spectre-PHT için çekirdek karşı önlemleri arasında kullanıcı işaretçilerinin temizlenmesi ve ayrıcalık seviyesi anahtarlarında bariyerlerin (güvenlik) kullanılması yer alıyor. Bu nedenle SpectrePHT'nin ana bilgisayar sistemine çok az tehdit oluşturduğu veya hiç tehdit oluşturmadığı sonucuna vardık. Ancak bunlar

Azaltmalar, aynı fiziksel çekirdek üzerinde paralel olarak yürütülürlerse iki hiper iş parçacığını birbirinden korumaz. Dört Spectre-PHT mistraining varyantının tamamının hem ana bilgisayar sisteminde hem de Firecracker VM'lerinde tamamen işlevsel olmasının nedeni budur. Tablo 4'te görülebileceği gibi, SMT devre dışı bırakılsa bile bu durum geçerliliğini korur[4]. Aslında, her iki VM'nin de aynı fiziksel iş parçacığına sabitlenmesi, Spectre-PHT'nin çapraz işlemler arası yerinde olmayan sürümünü mümkün kılarken, SMT durumunda sızıntı gözlemlemedik. Bu, Spectre-PHT'yi kullanıcıdan kullanıcıya önemli bir tehdit haline getirir.

Spectre-BTB PoC'ler, AWS tarafından önerilen karşı önlemler etkinleştirildiğinde kısmen işlevseldir. BTB'yi aynı süreçte ve aynı adreste yanlış eğiten orijinal varyant tamamen işlevseldir, aynı süreçte yerinde olmayan yanlış eğitim ise tamamen işlevseldir.

başarıyla hafifletildi. Ayrıca, yerinde olmayan yanlış eğitim yoluyla süreç sınırlarının ötesine bilgi sızdırma girişimlerinin tümü herhangi bir sızıntı göstermedi. Ancak çapraz proses yerinde yanlış yönlendirmeyle sızıntı gözlemledik. Ana sistemde sızıntı SMT'den bağımsız olarak meydana geldi. Bir VM'nin içinde sızıntı yalnızca tüm sanal CPU çekirdeklerinin ayrı bir fiziksel iş parçacığına atanması durumunda meydana geldi. VM'ler genelinde SMT'nin devre dışı bırakılması sızıntıyı ortadan kaldırdı.

Şekil 5'te listelenen karşı önlemlerin yanı sıra, ana bilgisayar çekirdeği, çekirdek bir VM çıkışını yönetirken kötü niyetli misafirlerin ana bilgisayar çekirdeğine saldırmasını tamamen engellemek için VM giriş ve çıkış noktasına[5] derlenmiş Spectre karşı önlemlerine sahiptir.

Özetle AWS Firecracker tarafından önerilen Linux varsayılan karşı önlemlerinin Spectre'ı yalnızca kısmen hafiflettiğini söyleyebiliriz. Tam olarak şunu gösteriyoruz:

• Spectre-PHT ve Spectre-BTB, AWS'nin önerdiği karşı önlemler (SMT'nin devre dışı bırakılması da dahil) uygulandığında misafirden misafire senaryosunda kiracılar arasında bilgi sızdırmaya devam edebilir.

• Ana bilgisayar çekirdeği, VM girişlerini ve çıkışlarını korumak için Linux çekirdeğinde derlenen ek önlemlerle muhtemelen yeterince korunmaktadır. Ancak bu, Firecracker tarafından sağlanan güvenlik önlemlerine paraleldir.

Gözlemlenen tüm sızıntılar, kullanılan Firecracker sürümünden bağımsızdı.

5.3.2 Değerlendirme. Firecracker'ın Spectre'ye karşı azaltıcı önlemlere katkıda bulunmadığını ancak yalnızca ana bilgisayar ve konuk çekirdekler tarafından sağlanan azaltıcı önlemleri ve isteğe bağlı mikro kod güncellemelerini içeren genel koruma önerilerine dayandığını tespit ettik . Daha da kötüsü, önerilen karşı önlemler, sunucusuz uygulamaları diğer kiracılara bilgi sızmasına karşı yeterince koruyamıyor. Bu nedenle, mikro mimari saldırılar, Firecracker tehdit modeli kapsamında değerlendirilse de, Firecracker'ın mikro mimari düzeyde izolasyon hedefine ulaşamadığını iddia ediyoruz.

Uyarı okuyucusu, Spectre-BTB'nin neden STIBP karşı önlemi varken bir sorun olmaya devam ettiğini merak edebilir (bkz. Şekil 5), çünkü bu mikro kod yaması dal tahmininin başka bir ileti dizisinden kaynaklanan tahmin bilgilerini kullanmasını durdurmak için tasarlanmıştır. Bu durum bizi bir süre şaşırttı, ta ki yakın zamanda Google, Linux 6.2'de IBRS etkinleştirildiğinde STIBP azaltımını devre dışı bırakan bir kusuru tanımlayan bir güvenlik tavsiyesi[6] yayınlayana kadar. Sorundan sorumlu olduğu belirlenen kod bölümünün Linux 5.10 kaynak kodunda da mevcut olduğunu doğruladık. Bu nedenle varsayımımız, Google tarafından tanımlanan sorunun aynısının bizim sistemimizde de meydana geldiği yönündedir.

[2] Mikro kodun daha yeni bir sürüme güncellenmesi sistemimizde TSX'i devre dışı bırakacak ve bu da TSX tabanlı MDS varyantlarıyla testleri imkansız hale getirecektir.

[3] https://github.com/firecracker-microvm/firecracker/blob/ dbd9a84b11a63b5e5bf201e244fe83f0bc76792a/docs/getting-started.md

[4] Bu, saldırgan ve kurban sürecinin aynı çekirdeğe sabitlenmesiyle simüle edilir ((1PT))

[5] https://elixir.bootlin.com/linux/v5.10/source/arch/x86/kvm/vmx/vmenter.S#L191

[6] https://github.com/google/security-research/security/advisories/GHSA-mj4w6495-6crx