inter-VM Transparent Page Sharing (TPS) servisinin devre dışı bırakılması.

inter-VM Transparent Page Sharing (TPS) servisinin devre dışı bırakılması.
Adem YETİM tarafından 3 sene önce eklendi. 5,466 kez okundu.
Ciddi bir çalışmanın ardından yeni ve yine çok doyurucu olduğunu düşündüğüm bir makaleyi sizlere takdim etmek istiyorum.
VMware güvenlik nedenlerinden dolayı inter-VM Transparent Page Sharing (TPS) servisini devre dışı bıraktı başlığıyla yakaladığımız bir haber üzerine yapmış olduğum derinlemesine araştırma neticesinde bu konunun üzerine yazılması gereken bir başlık olduğunu düşünerek ve konuyla ilgili makale sonunda referans olarak verilen makalelerin dikkatlice taranması sonucunda aşağıdaki çalışmayı yayınlıyorum. Umarım her seviyeden “sanallaştırma” meraklısının kendine uygun ve faydalı bilgiler bulabileceği bir çalışma olmuştur. Şimdi sıra sizde…Kolay gelsin…

Muhtemelen hepimiz vSphere’nin gelecek versiyonlarından varsayılan olarak devre dışı bırakılan inter-VM(!!) TPS (transparent page sharing) duyurusunu ve mevcut versiyonlarda bunu devre dışı bırakma önerilerini görmüşüzdür. Bunun nedeni de yüksek oranda kontrollü koşullar altında veriye nasıl ulaşılabileceğini gösteren bir araştırma raporudur, Bu makale TPS kullanımı sırasındaki güvenlik kaygılarının detaylarını açıklamaktadır. Makalenin özeti;

Art

VMware bununla beraber gelecekteki ESXi sürümlerinde, güvenlik kaygıları nedeni ile TPS’in varsayılan olarak devre dışı olacağını duyurdu. VMware KB2080735(güvenlik gerekçeleri ve inter-Virtual Machine Transparent Page Sharing izninin kaldırılması)

VMware Bilgilendirme Makalesi:

Bu makale Transparent Page Sharing’in (TPS) yüksek kontrollü koşullar altındaki verilere yetkisiz erişimi artırdığı yönündeki bilimsel çalışmalara dayanmakta ve VMware’in gelecekteki sürümlerde TPS’i aktive etmeme önlemi alacağını dökümante etmektedir. Şu anda VMware, sanal makineler arası TPS nedeni ile bir açıklama bildirisi yayımlamanın gerçek dünya kullanımı dâhilinde pratik olmadığına inanmaktadır. Yayımlanmış akademik makaleler göstermiştir ki eğer Transparent Page Sharing aktif ise temizliğe zorlayarak ve cache belleğini yeniden yükleyerek hostun aynı fiziksel işlemcisi üzerinde çalışan bir başka sanal makinenin kullanımdaki AES şifreleme anahtarını elde etmek için bellek zamanlamalarını ölçümlemek mümkündür. Bu teknik sadece standart olmayan konfigürasyon kullanan ve yüksek oranda kontrollü çevrelerde çalışmaktadır. Her ne kadar VMware bilginin gerçek dünya koşullarında açıklanmasının realistik olmadığına inanıyor olsa da ihtiyat gerekliliği nedeni ile ilerideki ESXi Update sürümlerinde sanal makineler arası TPS varsayılan olarak devre dışı olacak.

Aşağıdaki sürümlerde TPS varsayılan olarak devre dışı olacaktır:

  1. ESXi 5.5 Update release (Q1/ 2015)
  2. ESXi 5.1 Update release (Q4/ 2014)
  3. ESXi 5.0 Update release (Q1/ 2015)
  4. ESXi’nin bir sonraki majör versiyonu      (ESXi 6.0)

Bu güncellemelerde önce VMware ilave TPS yönetim yeterlilikleri sunan ve mevcut inter VM TPS (Bkz. KB2091682) ayarlarını DEĞİŞTİRMEYEN yamalar yayımlayacaktır. KB2080735’de belirtildiği üzere planlanan ESXi yaması sürümleri:

  1. ESXi 5.5 Patch 3
  2. ESXi 5.1
  3. ESXi 5.0

ESXi 5.0 ve 5.1 için yamalar 2014’ün son çeyreği için planlanmaktadır. ESXi 5.5 için halihazırda bir yama mevcuttur (ESXi550-201410401-BG).

Şunu belirtmemde fayda var: Birkaç yıl önce TPS’in deaktivasyonu ölümcül olabilirdi. Bugün ise, performanstan önce güvenlik kaygısı nedeniyle, bu doğru bir seçim olarak görünüyor. Eğer sistem tasarımınız ciddi şekilde TPS’e dayanmakta ise tasarımınızı gözden geçirmenizde fayda var; çünkü vSphere tasarımında %20-30 over-commitment oranının TPS’e atfedilmesi genellikle görülür. Ancak gerçekte bu oranlar IT organizasyon izleme süreçleri nedeni ile asla görülmezler. Peki neden? Çünkü TPS artık eski vSphere öncesi (ESX 2.x ve 3.x) altyapılarında olduğu frekanslarla aynı frekansta kullanılmamaktadır. Gerçekte vSphere modası geçmiş over-commitment oranlarını kaldırmıştır. Sadece bazı bellek kullanım eşikleri geçildiğinde TPS’i desteklemektedir. Tipik olarak belirtmek gerekirse güvenlik hassasiyeti olan mimarlar, ortamlarını %96’lık bellek kullanımı eşiklerine ulaşmak için tasarlamazlar.

Hızlı bir giriş oldu farkındayım ama bu yazımda, bahsettiğimiz güvenlik zafiyeti ve VMware’in bu zafiyete karşı olan tutumlarına detaylıca değinmeye çalışacağım fakat tabi ki sanallaştırma dünyasına girmiş herkese hitap edebilmek için biraz frenleyelim ve TPS’e giriş yapalım…

TPS nedir?

TPS’nin açılımı Transparent Page Sharing’dir ve VMware bellek yönetim teknolojilerinden birisidir. VMware ESX(i) host ve guest bellek kaynaklarını (daha fazla bilgi için VMware KB2017642’i inceleyin) yönetmek için 4 değişik teknoloji kullanmaktadır. Tercihler TPS’ten swapping’e kaymaktadır.

  1. Transparent page sharing (TPS)
  2. Ballooning
  3. Bellek Kompresyonu
  4. Swapping

TPS, bellek sayfalarının fazlalık kopyalarının elimine edildiği bir teknolojidir. TPS’i bir tür “bellek ikiliklerinin elimine edilmesi” olarak görebilirsiniz. Hipervizör, belleği paylaşılması muhtemel bellek sayfaları için düzenli olarak tarar. Her aday bellek sayfası için bir hash hesaplanır ve hash tablosuna kaydedilir. Eğer ikinci bir aday sayfa aynı hashı kullanıyor ise her iki sayfa için de tam bit-by-bit karşılaştırma tetiklenir. Eğer her iki bellek sayfası da aynı ise sadece bir sayfa kaydedilir ve diğer bellek sayfası iade edilir. TPS varsayılan olarak devrededir ve iyi sonuçlar verir, özellikle de VDI veya terminal server ortamlarındaki gibi çok sayıda VM aynı OS üzerinde çalışıyorsa.

TPSYeni hardware destekli bellek sanallaştırma sistemlerinde, tıpkı Intel EPT veya AMD RVI gibi VMware da, TPS’in davranış şeklini ve misafir belleğin fiziksel belleğe nasıl yedekleneceğini değiştirmiştir. Guest bellek daha iyi performans için artık daha büyük sayfalara yedeklenmekteydi(4 KB yerine 2MB). Ancak 4 KB’lık sayfalar halen 2 MB sürekli bellek yok ise kullanılmaktaydılar, bellek overcommitment veya bellek kırılımı gibi durumlarda. 2 MB bellek sayfalarını kullanmanın bazı avantajları yanında TPS açısından 2 dezavantajı vardır:

  1. İki aynı bellek sayfasını bulma şansının      az olması
  2. 2 MB sayfalarda bit-by-bit      karşılaştırmanın maliyeti 4 KB olanlara kıyasla çok daha fazla olması

Hardware destekli bellek sanallaştırma sistemlerinde can alıcı nokta ise TPS’in sadece eğer host bellek baskısı altında ise aktif olarak kullanılmasıdır. Ancak  halen oradadır ve çalışmaktadır. Dikkat ediniz ki bu bir real-time süreç değildir, ancak bir zaman dilimi sürecidir: ESXi hostları periyodik olarak paylaşılan bellek sayfaları için guest fiziksel belleklerini tarar. Çalıştırmak zaman alır ve etkileri zamanla görülür. (ama TPS ve çoğu eski versiyonlarda da geçerlidir).

Büyük sayfalar ve işlemci mimarileri;

AMD ve Intel donanım destekli bellek sanallaştırma özelliklerini (RVI ve EPT) tanıttığında VMware mühendisleri hızlı şekilde kernelin bellek kullanımını düşürürken sanal makine performansının arttığını keşfetmişlerdir. Bununla beraber ortada bir overhead mevcuttu ve bu da büyük sayfalar kullanılarak çözülebilirdi. Çünkü normal bir bellek sayfası 4KB iken büyük sayfa ise 2MB boyutundadır.

Bununla beraber büyük sayfalar TPS ile kombinlenemiyordu ve bu 2 MB’lik blok alanları tararken overhead ortaya çıkıyordu. Aynı büyük sayfaların bulunması olasılığı overhead’in düşük bellek tasarruf potansiyeline değmeyeceğinin anlaşılmasını sağladı. Performans artışı yaklaşık %30 civarında hesaplanırken paylaşım kaybının etkisi minimal idi, nitekim bellek alanları fiziksel makinelerde her yıl artma eğiliminde idi. Zaten bu nedenle vSphere provizyonlu sanal makineler, CPU donanım destekli bellek sanallaştırma özelliklerini destekleyen donanım-MMU kullanmaktadırlar.

vSphere’in büyük sayfalar kullanmasına karşın TPS halen aktiftir. Büyük sayfa içindeki tüm sayfaları bellek kullanım baskısını azaltmak için bellek eşiğine ulaşıldığında tarar ve hash eder. Büyük sayfalar hakkındaki bir diğer ilgi çekici şey ise en iyi performansı sağlama eğilimidir. Kernel büyük sayfaları ayırır ve bellek baskısı boyunca sayfaları paylaşır, ancak bellek baskısı yokken yeni gelen sayfalar büyük sayfalarda depolanacaktır. Potansiyel olarak büyük sayfalar oluşturmak ve dekonstrükte etmenin döngüsel sürecini ortaya çıkarır.

NUMA;

Bellek paylaşım potansiyeli üzerindeki bir diğer etki de NUMA işlemci mimarisidir. NUMA, bellek sayfalarını CPU’ya olabildiğince yakın depolayarak en iyi performansı sunmaktadır. Sayfalar iki ayrı CPU sistemi arasında paylaştırılırken TPS bellek paylaşımı performansı düşebilirdi.

numa

Kapasite planlama etkisi;

TPS’i varsayılan olarak devre dışı bırakmanın etkisi bazılarının beklediği kadar büyük olmayacaktır. Benim ilgi çekici bulduğum şey ise güvenlik özeni. Kesinlikle katılmaktayım ki burada hedeflenen alışılmışın dışındaki güvenlik hayati önemde, ama olasılığı ele aldığımızda ben olsam diğer güvenlik uzmanları gibi, vMotion ağına man-in-the-middle atağı yapmayı tercih ederdim, ağ boyunca temiz veriyi okur, ardından TPS’in belleği göçürmesini beklerdim. Ki bu da beni vMotion trafiği için şifrelemenin ne zaman olacağını düşünmeye itiyor.

Sistemleriniz veya tasarımlarınız üzerindeki olası etkileri hakkında detaylı bilgiyi makalemin ilerleyen bölümlerinde vereceğim.

Genel olarak çoğu sanallaştırma mimarı, ortamlarını ölçütlendirirken %20-30 bellek paylaşımını hesaba katarlardı. Inter-VM TPS devre dışında iken bu haliyle seçenek dışı. TPS varsayılan olarak kullanılmaz, sadece zorlanma durumunda kullanılır…

Eğer bir host altında ise TPS ilk bellek talep eden teknik olduğundan, bana sorarsanız, bu baskı altında kısmı önemli. Eğer TPS bellek baskısını etkin şekilde düşüremezse balooning ortaya çıkar ve ardından da kompresyon ve swapping gelir. Kişisel olarak neye mal olursa olsun swappingden kaçınmayı tercih ederim, tercihen kompresyondan da elbette. Ballooning genellikle büyük performans kayıplarına neden olmadığından kabul edilebilirdir ancak TPS ise büyük sayfaları küçük sayfalara dönüştürdüğünden ve mümkün olduğunda çökerttiğinden benim tercih edeceğim bir şeydir. Mevcut vakada performans kaybını ölçmek oldukça zor. Elbette ki TPS, sadece VM içinde değil VMler arasında sayfalar paylaşılabildiğinde daha efektif bir yol olacaktır.

Her neyse, eminim aklınızdaki mevcut soru (inter-VM) TPS devre dışı olmalı mı yoksa olmamalı mıdır?

Riski değerlendirirken kendinize ilk sormanız gereken “sanal makinenize kimin erişebileceği” olmalıdır, nitekim teknik sanal makinenizde oturum açmanızı gerektirmektedir. Senaryolara geçmeden önce inter-VM TPS ilerideki versiyonlarda tamamen devre dışı değil. Inter-VM paylaşım varsayılan olarak devre dışı ancak devreye de alınabiliyor.

Şimdi 3 senaryoya bakalım:

  1. Server sanallaştırma (özel)
  2. Public cloud
  3. Sanal masaüstleri

Server sanallaştırma durumunda, senaryoların çoğunda, benim beklediğim, sanal makinelere sadece sistem adminlerinin ve/veya uygulama sahiplerinin erişebilmesidir. Şimdi soru ise sanal makinelere zaten erişimleri varsa neden bu seviyelere kadar gitsinler? Server Sanallaştırmasının kullanımdaki vaka olduğu ve sanal makinelerinize erişimin sadece sınırlı sayıda insana verildiği bir senaryoda inter-VM TPS’i devreye almayı kesinlikle yeniden düşünürdüm.

Ancak public cloud ortamında tamamen farklıdır elbette. Düşünün ki bir hacker bir sanal makine satın alıyor ve AES şifreleme anahtarını elde etmeye çalışıyor. Elbette daha sonra (hackerin) bununla ne yapacağı halen soru işaretidir. Cloud sağlayıcısının güvenlik/networking bakış açısı ile katılımcıların birbirlerine erişimlerinin engellenmesini sağladığı umulmaktadır. Eğer bunu yapıyorlarsa hackerların yapacakları çok şey yok gibi durmakta. Ancak yine de sisteme sızabilmek için bazı adımlar atmaları gerekir ki ben risk düşük olsa da bu riski almak istemem. Bu da inter-VM TPS’i devre dışı bırakmak isteyeceğim senaryolardan birisidir.

Üçüncü ve son senaryo da Sanal Masaüstleridir. Sanal masaüstü senaryosunda pek çok farklı kullanıcının sanal makinelere erişimi vardır. Burada sorun AES şifrelemesini güçlendiren uygulamalar çalıştırıp çalıştırmadığınız veya bunlara erişip erişmediğinizdir. Bunu sizin adınıza yanıtlayamayacağımdan bu konuyu biraz havada bırakıyorum… Bu riski sizin değerlendirmeniz gerekecektir.

Bence (inter-VM) TPS’i devrede mi devre dışında mı bırakmanız gerektiğiniz sorusunun yanıtı her zaman olduğu gibi “duruma göre değişir” olacaktır. Neden TPS’in devre dışı bırakıldığını anlıyorum, ana risk düşük ise onun yeniden aktive etmeyi de düşünebilirim.

Peki VMware vSphere TPS güvenlik açığının büyük mesele olmasının nedeni ve tam olarak etkileri nelerdir?

 TPS VMKernel’in Sanal Makine Monitörü (VMM) bileşeninin fazlalık VM bellek sayfaları için fiziksel host belleğini taramasını sağlayan bir süreçtir. TPS’in hostun faydaları fiziksel bellek kullanımını düşürmesini sağlamak, bu sayede aynı hosta daha fazla VM sıkıştırılmasına olanak tanımaktır, nitekim hostun en çok sıkıntı yaratan kısmı bellek kısıtıdır. TPS temel olarak RAM için depolama tekilleştirilmesine eşittir ve belirttiğim gibi 4 KB blok düzeyinde çalışır. Bu klasik V13 bellek sayfasında nasıl çalıştığını kısaca açıklayacak olursak;

Çoklu sanal makineler çalışırken bunlardan bazıları aynı bellek içeriği setlerine sahip olabilirler. Bu da sanal makineler arasında bellek paylaşılması olanağını sağlamaktadır (tıpkı tek sanal makine içinde paylaşım gibi). Örneğin bazı sanal makineler aynı misafir işletim sistemi üzerinde çalışabilir, aynı uygulamalara sahip olabilir veya aynı kullanıcı verilerini içeriyor olabilirler. Sayfa paylaşımı ile hipervizörler fazlalık kopyaları silebilirler ve sadece tek bir kopya saklayabilirler ki bu da host fiziksel belleğindeki çok sayıdaki sanal makine tarafından kullanılır. Sonuç olarak toplam sanal makine host bellek kullanımı düşer ve daha yüksek bellek TPSovercommitment olası hale gelir.

Şuna dikkat etmek önemlidir: TPS özelliği V13 ile 2006 yılında tanıtılan vSphere için yeni bir şey değildir ama görünen o ki bazıları bunu keşfetmiş ve ondan başarı ile faydalanmayı sonunda fark etmiş. Peki neden bu büyük bir mesele? Çünkü bir sanallaştırma mimarisi VM izolasyonu gerektirir ve bu da sanallaştırma için en önemli güvenlik gereksinimidir. Bir host üzerinde çalışan her VM guest’in diğer bir VM guest’e erişmesine izin verilmemelidir. Bunların tamamı erişim anahtarlarının sadece hipervizörde olduğu ayrı kilitli bölümlerde saklanmalıdır.

Bunu göstermek için bir gerçek yaşam senaryosu kullanalım; bir otele kayıt olduğunuzu düşünün, gizlilik ve izolasyon ve diğer misafirlerin odanıza girememesini beklersiniz. Bununla beraber odanızın bitişikteki oda ile ortak bir kapısı vardır ama her iki misafir de bu kapıyı kullanamaz, sadece otel yönetimi kapıyı açabilir. Ancak bir şekilde bir misafir bu kapıyı açmanın ve sizin özelinize girmenin bir yolunu bulsun, sizce de bu büyük bir sorun değil midir?

VMware zırhındaki zayıf noktaları kapatıyor gibi görünmekte, işte bu nedendendir ki zayıflıklarını açıklayan ve hostları üzerindeki TPS’i nasıl devre dışı bırakabileceklerini müşterilerine açıklayan bir KB makalesi yayımladılar. VMware KB makalesinde güvenlik zafiyetine neden olan kaynağın tam adını vermemektedir, yazımın en başında da belirttiğim gibi sadece “akademik bir makale” olarak refere etmektedir. Akademik makalenin başlığı “Wait a minute! A fast, Cross-VM attack on AES” idi ve Worcester Politeknik Enstitüsü’nden bir grup birey tarafından 2014 yılında yazılmıştı. National Science Foundation fonundan desteklenmişti ve oldukça teknik, baş döndürücü bir yazı idi ve çok sayıda matematiksel formül içeriyordu. Bir göz atmaya değer, nitekim bazı parçaları kullanılabilir ve atak senaryoları ve sonuçları hakkında açıklama sunmaktadır. Makalenin genel bakışında belirtilmektedir ki:

Bu çalışmada –Flush + Reload tekniğini kullanarak – ilk defa gerçekçi cloud benzeri server ortamında sanal makineler boyunca pratik full key recovery atağına olanak sağlayan AES üzerinde cache bazlı side-channel atağını sunuyoruz. Bu atak, VMware sanallaştırma motoru tarafından kullanılan ve bu çalışmanın odak noktası olan Transparent Page Sharing adı verilen bir tekilleştirme mekanizmasından yararlanmaktadır. Atak çekirdekler arasında harika iş çıkarmıştır, örneğin cloud sistemlerinde sıklıkla bulunan çok çekirdekli high-end server senaryolarında oldukça iyi çalışmaktadır. [13] ile kıyaslandığında atak minimal derecede invazifti, karşı tarafın gerekliliklerini ciddi şekilde düşürüyordu: bellek erişimleri minimal düzeydeydi ve erişimler de victim sürecinin işletilmesini kesintiye uğratmayı gerektirmiyordu. Bu da aynı zamanda atağın mağdur açısından tespitinin zor olduğu anlamına gelmektedir. Son ama en önemlisi de atak bir şimşek gibi hızlı idi: şifreleme serverının saldırıya uğradığı gerçekçi bir senaryo üzerinde çalışıldığında bütün anahtarın çekirdekler arasında bir sanallaştırılmamış ortamda (örneğin spy süreci kullanarak) 10 saniyeden kısa süre içerisinde ve VM sınırları içerisindeki sanallaştırılmış alanda da 1 dakikadan kısa sürede kurtarıldığını göstermekteyiz.

Yazıyı okurken yazının sonuna geldiğimde referanslar kısmında belki de herkes gibi benim de dikkatimi çeken şey makale yazarlarının 2014 yılının ilk aylarında “Fine grain Cross-VM Attacks on Xen and VMware are possible!” başlıklı bir yazı daha yazmış olmaları idi. Görünen o ki yazarlar teorik bir araştırmanın gerçek hayattaki bir atağa uygulanmasını araştırmışlar ve ikinci bir yazının yazılacağını öngörmüşlerdir.

Şuna da dikkat etmek önemlidir ki bu çok da kolay faydalanılabilir bir açık değildir ve risk aslında öylesine küçüktür ki pek çok ortamın bundan etkilenmemesi bile gerekir.

V13’e kadar tüm vSphere versiyonları kullanımdan zedelenebilir ancak VMware ise sadece 5.x versiyonlarını desteklemektedir ve 4.x versiyonları Mayıs 2014 itibariyle resmi desteği kaybedeceklerdir. Bu yamaların sadece varsayıla olarak şu anda aktif olan TPS’i devre dışı bıraktığına dikkat ediniz, açığı çözümlemiyorlar. Yüksek ihtimalle VMware’in TPS’in istismar edilmeyeceği şekilde nasıl çalışacağını bulması zaman alacaktır. Yani eğer kendi TPS’inizi devre dışı bırakırsanız aslında yamaya ihtiyacınız yok. Makalemin başlarında da belirttiğim gibi VMware states KB makalesinde belirtmektedir ki “Adminler istedikleri zaman eski duruma dönebilirler”, yani bu konuda çok da endişeli değiller.

TPS’in sunduğu faydalar VM iş yüklerine bağlı olarak ortama göre değişkenlik göstermektedir. Yani eğer güvenlik paronayağı iseniz muhtemelen onu devre dışı bırakmak isteyeceksinizdir. Ne kadar fayda sağladığınızı görmek için vCenter’da “shared” ve “sharedcommon” bellek sayaçlarına bakarak TPS’in etkinliğini görebilirsiniz. Her host için KB makalesinde belirtildiği şekilde gelişmiş ayarları değiştirerek mevcut sisteminizde TPS’i devre dışı bırakabilirsiniz, güncelleme ayarları elbette basit ancak etkili olmasını sağlamak sıkıcı bir iş:

  1. ESX\ESXi veya vCenter Server’a vSphere Client kullanrak giriş yapın.
  2. Eğer vCenter Server’a bağlıysanız ilgili ESX\ESXi hostu seçin.
  3. Konfigürasyon sekmesinde Yazılım başlığı altındaki Gelişmiş Ayarlar’ı tıklayın.
  4. Gelişmiş Ayarlar penceresinde Mem’i tıklayın.
  5. Mem.ShareScanGHz’i bulun ve değeri 0’a ayarlayın.
  6. OK’i tıklayın.
  7. Aşağıdakilerden birini yaparak TPS      değişikliğinin hemen aktif olmasını sağlayabilirsiniz:
    • Tüm sanal makineleri kümedeki bir başka hosta taşıyın ve sonra orijinal hosta geri döndürün.
    • Tüm sanal makineleri kapatın ve yeniden açın.

Her ne kadar etkisi ve maruziyet kısa sürse de birisinin VMler arasındaki bu katı duvarı yıkmış olduğu gerçeği büyük bir sorun. VMware bunu resmi olarak “süreçler arası side channel sızıntısı” olarak niteliyor ve KB makalesinde şu şekilde bahsediyor:

Ortak işlemci üzerinde çalışan süreçler arasında paylaşılan kaynaklardan bilgi sızıntısından istifade eden side channel atakları birkaç yıldır keşfedilmiş olan bir araştırma konusudur. Her ne kadar geniş oranda teorik olsa da teknikler sürekli olarak gelişmektedirler, nitekim araştırmacılar birbirlerinin çalışmalarının üzerine koyarak ilerlemektedir. Her ne kadar bu sorun VMware teknolojisine özgü olmasa da VMware bu sorunların tamamen anlaşıldığından emin olmak ve ürünlerimize uygun şekilde uygulama yapmak için araştırma komitesi ile birlikte çalışmaktadır.

Dikkat ederseniz bu tür güvenlik zafiyetlerinin yıllardır “keşfedildiğinden” bahsetmektedirler ki bu da bunun sanal ortamın hacklenmesinin bir tür kutsal kâsesi olması nedeni ile pek çok insanın bu duvarları yıkmayı yıllardır denediği anlamına gelmektedir. Düşünün ki birisi daha az önemdeki bir VM’yi riske atmış olsun. En azından risk ve güvenlik zafiyeti bu tek VM’de olacaktır, ama eğer birisi bir şekilde bu riske atılmış VMyi hosttaki diğer VM’lere atak yapmak için sıçrama tahtası olarak kullanırsa bu büyük bir sorun olur. Gerçek şudur ki bu tür güvenlik zafiyetleri VMware ve onların güvenlik tabanlarını etkileyene kadar teorik olarak kalırlar.

Neden varsayılan olarak devrede olmayacak?

Toparlayacak olursak, bu makalede açıklanan temel neden güvenlik gerekçesi ile ilgilidir: bazı akademik makaleler TPS’in veriye yetkisiz erişimi kolaylaştırdığını ortaya koymaktadır. Bu nedenle VMware mümkün olan her yerde “varsayılan olarak güvenli” olmaya özen göstermektedir, her ne kadar TPS’i devreye almakla ilişkilendirilen risk düşük olsa bile. Daha fazla bilgi için KB 2080735.

Ancak hâlen TPS kullanmak için (örneğin bellek overcommit sunumunun kullanışlı olabileceği VDI ortamlarında) bazı ilgi çekici gelişmeler KB 2091682’de tanımlanmıştır: yeni host konfigürasyon seçeneği Mem.ShareForceSalting’in saltingi açabildiği veya kapayabildiği tanıtıldı (iki VMnin bir sayfayı paylaşması için, hem saltlarının hem de sayfa içeriğinin aynı olması gereklidir; salt değeri manuel olarak her makine için ayarlanabilen bir vmx değeridir).

Ama bu güvenlik gerekçesi, TPS’in neden devre dışı bırakılabildiği/bırakılması gerektiğinin açıklaması değildir.

Bir diğer neden donanım MMU sistemleriyle ve geniş sayfalı TPS ile alakalıdır ve KB 1021095 ve bazı blogger gönderilerinde güzel şekilde açıklanmıştır: “Temel olarak TPS geniş sayfaları olan bir sistemde bu kadar kullanışlı olamazdı (her ne kadar uygulanabilir olsa da), nitekim birbirleri ile aynı olan iki geniş sayfa bulma olasılığı çok düşüktür. Aynı nedenlerle, sertleşen bellek yönetimleri olan son dönem işletim sistemleri (örneğin Windows ASLR ile adres randomizasyonu için) TPS’ten pek de fayda elde edemezler (TPS’in Windows XP ve Windows 7 veya 8’de nasıl çalıştığını karşılaştırabilirsiniz).”

Başka bir neden ise ne şekilde çalıştığını gösteren ilk makaleden beri tarif edildiği şekilde TPS kullanımının operasyonel maliyetleri ile ilişkilidir: genellikler bellek sayfaları sayfanın içeriğini özetleyen hashler kullanarak karşılaştırılır, ama ardından başarılı bir karşılaştırma sayfaların gerçekten eş olduğunu teyit edecek olan tam sayfa içerikleri karşılaştırmasınca takip edilir. Bu da çok zaman kaybettiren işlemler demektir (her ne kadar her serverda daha çok çekirdek olsa da ve hem çekirdekler hem de bellek çok daha hızlı olsa da hostlardaki bellekler de çok daha büyük bir hale gelmiştir!).

Ayrıca bir de vMotion operasyonları ile ilişkili boyut vardır: bir VM’i hostlar arasında hareket ettirdiğinizde tüm bellek sayfaların paylaşılmış olmasına bakılmaksızın kopyalanacaktır (aynı sayfaları paylaşan iki VMi hareket ettirseniz bile). Bu da bakım sırasında kullanılan RAM’in hızla artabileceği (TPS sadece talep üzerine devreye girer ve çiftli sayfaları tekilleştirmek zaman alır) ve buna dikkat etmeniz gerektiği anlamına gelmektedir. Aynısı yüksek dinamikliği olan ortamlar için de geçerlidir ki buralarda çok sayıda VM yaratılır, silinir veya reboot edilir.

İlginç olan tarafı ise TPS’in sadece ESXi’De (ve ESX’de) bulunan ayırt edici bir özellik olması ve diğer hipervizörlere hiç uygulanmamış olmasıdır: artık bu açık belki de bunu devre dışı bırakacak olan VMware tarafından kapatılabilir.

Genel olarak vSphere oldukça güvenli bir platformdur ve bu platform güvenliğe ne kadar önem verildiğini ispatlayan bir dizi ciddi testten geçmiştir. VMware bu durumda da öğrenmekten çekinmeyecektir ve daha iyi bir hale getirmek için vSphere’nin güvenliğini geliştirecektir. Bununla birlikte bunun sonuçlarından birisi de onların VM verilerini karıştırarak hipervizör kaynaklarını daha etkin hale getirmek istemesi olacaktır. İlerlerken çok dikkatli olmaları gerekiyor, nitekim vSphere’i optimize etmek için sürekli yeni yollar arıyorlar ve bunu güvenlikten taviz vermeden ve VMler arasında risk oluşturmadan yapmaları gerekiyor.

Referanslar;

Frank Denneman Future direction of disabling TPS by default and its impact on capacity planning
Magnus Andersson Changes in ESXi Transparent Page Sharing (TPS) behaviour
Kenneth van Surksum VMware decides to disable TPS in future ESXi releases by default
Marcel van den Berg VMware wil disable Transparant Page Sharing by default in future ESXi releases
Andrea Mauro Bye bye Transparent Page Sharing
Chris Wahl Transparent Page Sharing Vulnerable, Yet Largely Irrelevant
Duncan Epping (Inter-VM) TPS Disabled by default, what should you do?
IACR Wait a minute! A fast, Cross-VM attack on AES

 

 

  • Burhan Abdiler: Elinize sağlık Fatih Bey , detaylı incelemeniz konuyu tamamen açıklayıcı nitelikte ....
  • Tufan ULU: Adem kardeşim, tebrik ediyorum ve başarılarının devamını diliyorum,...
  • Rafet Arslanyı lmaz: Adem Hocam, Tebrikler.. Umarım devamıda gelir :)...
  • Serkan ERSAN: Çok başarılı ve güzel bir anlatım olmuş. Emeğinize sağlık, teşekkürler....
  • Adrenalin .: Teşekkürler Adem Bey....

2 Yorum Bulunuyor

  1. Rafet Arslanyilma z
    Kasım 11, 2014 - 8:25 am

    Adem Hocam,

    Yine harika bir makale olusturmussun ellerine sağlık.

  2. Erkan TUĞRAL
    Kasım 13, 2014 - 10:36 pm

    Merhaba,

    Gördüğüm kadarıyla hem VMware’in konu hakkındaki resmi açıklamasını hem de önde gelen Vmware blogger larının konuyla ilgili görüşlerini bir arada toplamış ve görüşleri güzel bir Türkçe ile çevirip bir araya getirmişsiniz. Oldukça güzel bir hizmet olmuş öncelikle elinize sağlık.

    Ancak bana göre TPS güvenlik konusunun çok fazla üzerinde durulup ciddi bir korku yaratacak bir durum olmadığını düşünüyorum. Sizin ve diğer blogger ların defalarca belirttiği gibi çok özel şartlarda oluşturulabilen bir güvenlik riski ortaya çıkarıyor Inter VM TPS’in aktif olması.

    Burada Vmware’in yaptığı ufak bir ihtimal de olsa default olarak güvenli olmayan bir config sunuyor olmamak için bu özelliği gelecek sürümlerde devre dışı bırakmak bence.

    Genel olarak konuya en iyi yaklaşım sunan makale , sizin de referanslar arasında linkini verip çevirisini yaptığınız Duncan Epping’in ilgili makalesi olduğunu düşünüyorum.

    Inter-VM TPS sizin de makale de ayrıntıları verdiğiniz gibi oldukça faydalı bir bellek kullanım özelliği. Public Cloud kullanımı ve diğer çok kritik güvenlik önlemleri isteyen ortamlar hariç , devre dışı bırakmak yerine aktifleştirip kullanmayı tercih ederim ve öneririm.

    Erkan TUĞRAL
    ——————————-
    http://www.erkantugral.net

Yorum ekleyin

Doğrulama Kodunuz : 41210669

ÖNEMLİ:
Yorumlarınızı eklerken lütfen girmiş olduğunuz bilgilerin size ait olduğundan emin olunuz. Geçersiz posta adresleri iel yapılan yorumlara yanıt vermek istenildiğinde size ulaşamayacağımız için, geçerli / aktif olarak kullandığınız posta adresiniz ile yorum eklemeniz daha sağlıklı olacaktır. Her yorum yazarı tarafından sorumlu tutulur.

Sayfa başı

Güncellemeler, yeni eklenen içeriklerden anında haberdar olmak için mail listemize adınızı soyadınızı ve posta adresinizi yazarak abone olabilirsiniz.

Adınız Soyadınız
E posta adresiniz
Kaydol