Intel Trusted Execution Teknolojisi ve BluePill Saldırısı

Intel TXT, TPM ve VT-d ile birlikte 'measured launch' kavramını donanım düzeyine taşıyor. Joanna Rutkowska'nın 2006'da gösterdiği Blue Pill saldırısının üzerinden dört yıl geçti, sanallaştırma güvenliği bugün nerede?

Sanallaştırılmış altyapıların yaygınlaşmasıyla birlikte güvenlik tartışmaları da gerçek bir dönüşüm yaşıyor. Eskiden tek bir işletim sisteminin tek bir donanım üzerinde çalıştığı dünyada güvenlik soruları görece basitti. Bugün ise tek bir fiziksel sunucu üzerinde onlarca sanal makine, onların altında bir hipervizör, hipervizörün altında ise BIOS/firmware ve donanım katmanları yer alıyor. Bu yığın derinleştikçe, “ben gerçekten benim yüklediğim hipervizörü mü çalıştırıyorum, yoksa altında oturmuş başka bir şey mi var?” sorusu kritik bir hale geliyor.

İşte tam bu sorunun donanım tarafındaki cevabı olarak Intel Trusted Execution Technology (TXT) birkaç yıldır vPro işlemcilerin bir parçası olarak hayatımızda. Bu yazıda TXT’nin ne yaptığını, neden 2006’da Joanna Rutkowska’nın Black Hat sahnesinde gösterdiği Blue Pill saldırısının bu hikâyenin merkezinde olduğunu ve sanallaştırma güvenliği için bunun ne anlama geldiğini incelemek istiyorum.

Blue Pill: 2006’da neyi gösterdi?

Hikâyeyi anlamak için 2006’nın yazına gidelim. O zamanlar Coseinc’te araştırmacı olan Joanna Rutkowska, Black Hat USA konferansında “Blue Pill” adını verdiği bir proof-of-concept rootkit sundu. Adını Matrix’teki “kırmızı hap / mavi hap” sahnesinden alıyordu, kullanıcıya gerçekliği fark etmeden bir simülasyonu yaşatma fikri.

Saldırının teknik özü şuydu: o yıllarda AMD, AMD-V (kod adıyla SVM) sanallaştırma uzantılarını yeni piyasaya sürmüştü. Bu uzantılar normalde hipervizörlere donanım yardımı sağlamak için tasarlanmıştı. Rutkowska, çalışmakta olan bir Windows Vista çekirdeğinin altına çalışma zamanında ince bir hipervizör yerleştirebileceğini gösterdi. Yani: kullanıcı Vista’yı normal şekilde açıyor, çalıştırıyor, antivirüsünü güncelliyor; arka planda Vista artık bir sanal makinedir ve onun altına yerleştirilen “ultra ince hipervizör” tüm sistemi kontrol etmektedir. İşletim sistemi bunu fark edemez çünkü hipervizör, donanım sanallaştırma uzantılarını kullanarak işletim sisteminin gördüğü “sahte donanım” katmanını mükemmele yakın taklit eder.

Önemli noktası şu: Blue Pill, sistem yeniden başlatılmadan, donanımın imzasını bozmadan, çekirdeğin bilinen rootkit denetimlerinin hiçbirine takılmadan kurulabiliyordu. Rutkowska bunu “%100 tespit edilemez kötü amaçlı yazılım” olarak sunmadı (zamanla bunun mümkün olduğu/olmadığı tartışıldı), ama tespit etmenin son derece zor olduğunu ve geleneksel güvenlik araçlarının bu katmana ulaşamadığını net biçimde ortaya koydu.

Bu gösterim, sanallaştırma uzantılarının yalnız iyi niyetli kullanım için değil, agresif saldırı modelleri için de kullanılabileceğine dair sektördeki ilk büyük uyarıydı. Akabinde Intel ve AMD cephesinde “platformun gerçekten bizim güvendiğimiz katmanı çalıştırdığını nasıl kanıtlarız?” sorusu acil bir mühendislik gündemi haline geldi.

Intel TXT’nin temel fikri: measured launch

Intel TXT (eski kod adıyla LaGrande Technology), bu sorunun cevabı olarak tasarlandı. TXT’nin tüm felsefesi tek bir kavrama dayanır: measured launch, yani “ölçülmüş başlatma”.

Geleneksel açılışta sıralama şudur: güç gelir, BIOS çalışır, bootloader çalışır, çekirdek çalışır, hipervizör veya işletim sistemi çalışır. Bu zincirde her halka bir sonrakini yükler; ama hiçbiri kendinden öncekinin gerçekten “olması gereken” şey olduğunu kanıtlamaz. Eğer BIOS’a, bootloader’a veya çok erken yüklenen bir sürücüye kötü amaçlı bir parça yerleşmişse, üzerine kurulan tüm güvenlik katmanı bu temel üzerinde yanlış varsayımlarla çalışır.

TXT bu zincire dinamik bir güven kökü (Dynamic Root of Trust for Measurement, DRTM) ekler. Önemli bileşenleri tek tek inceleyelim.

TPM (Trusted Platform Module)

TPM, anakart üzerinde yer alan kurcalamaya dirençli bir kripto yongasıdır. Yongacık, içinde özel anahtarlar barındırır ve dış dünyaya bu anahtarlarla yapılmış imzaları/şifreleri sunar; ama anahtarların kendisi yongadan dışarı çıkmaz. TXT için TPM’in en önemli özelliği PCR’lardır (Platform Configuration Registers): çalışmakta olan kodun SHA-1 özetlerini biriken bir hash zincirinde tutan özel kayıtlar. PCR’lara doğrudan istediğiniz değeri yazamazsınız; yalnızca “extend” işlemiyle eski değer + yeni ölçüm hashlenerek bir sonraki değer hesaplanır. Yani bir kez “iyi” bir değeri bozmadan içine başka bir şey enjekte etmek mümkün değildir.

SINIT ACM

TXT açılışında işlemci, Intel tarafından imzalanmış bir Authenticated Code Module (ACM), genellikle SINIT, yükler. SINIT modülü, BIOS ve chipset’in TXT için doğru yapılandırıldığını doğrular, MTRR’ları kilitler, DMA bölgelerini izole eder ve hipervizör/çekirdek için ölçülen bir “açılış noktası” hazırlar. SINIT, Intel imzasını taşıdığı için işlemci bu modülü ancak imza geçerliyse çalıştırır.

GETSEC[SENTER]

TXT’nin kalbinde yatan komut budur. İşlemci GETSEC[SENTER] ile özel bir “ölçülmüş başlatma” moduna geçer: tüm CPU çekirdekleri senkronize edilir, kesmeler bastırılır, SINIT ACM yüklenir ve onun ölçümü TPM’in PCR 17’sine yazılır. Ardından SINIT, asıl yüklenecek hipervizörün (veya çekirdek bileşeninin) imzasını alır, PCR 18’e ölçümünü extend eder ve kontrolü ona devreder.

Bu zincirin sonunda elinizde TPM tarafından imzalanabilen bir ölçüm seti olur. Diğer bir deyişle, sisteminizin “şu anda fiilen çalışmakta olan hipervizör katmanı şu SHA-1 hash’idir” diyebilirsiniz ve bunun kanıtı TPM’in özel anahtarıyla imzalanmıştır.

Intel VT-d

Hikâyenin DMA tarafını da kapatmak için TXT, Intel VT-d (Virtualization Technology for Directed I/O) ile birlikte çalışır. VT-d olmasaydı kötü amaçlı bir PCI cihazı, DMA üzerinden ölçülen hafıza bölgesine yazarak güveni bozabilirdi. VT-d, IOMMU üzerinden DMA bölgelerini izole eder ve bu saldırı vektörünü büyük ölçüde kapatır.

TXT, Blue Pill’i nasıl bozar?

Blue Pill’in temel varsayımı, çalışan bir işletim sistemine “fark ettirmeden” altına bir hipervizör yerleştirebilmekti. Bu mümkündü çünkü işletim sistemi, kendisinin altında bir hipervizör çalışıp çalışmadığına dair güvenilir bir ölçüme sahip değildi. TXT bu varsayımı yıkar:

  1. Açılışta ölçüm. Hipervizör TXT ile birlikte SENTER üzerinden başlatıldığında, ölçümü TPM’in PCR’ında saklanır. Sistem yöneticisi (veya uzaktaki bir doğrulama sunucusu) bu değeri okuyarak gerçekten istediği hipervizörün çalışıp çalışmadığını anlayabilir.
  2. Remote attestation. TPM, içerdiği AIK (Attestation Identity Key) ile PCR değerlerini imzalayıp uzak bir sunucuya gönderebilir. Böylece bir veri merkezindeki bir host’un gerçekten “onaylı hipervizör imajını” çalıştırdığını ağ üzerinden kanıtlayabilirsiniz. Beklenmeyen bir ölçüm, sisteme iş yükü atanmamasına yol açar.
  3. Sealed storage. TXT, anahtarların ve sırların yalnızca belirli PCR değerlerinde açılmasını sağlayan “sealing” mekanizmasını mümkün kılar. Yani altına bir hipervizör enjekte edilmiş sistemde TPM, üst katmanlardaki anahtarları açmayı reddeder.

Çalışma zamanında bir Blue Pill enjeksiyonu için bile durum zorlaşır: yeni bir SENTER çağrılmadan TPM’in PCR’ları “geriye” yeniden yazılamaz; yeni bir SENTER ise yeni bir ölçüm yaratır ve kontrolden kaçırılamaz.

Sınırlar ve eleştiriler

TXT’yi sihirli bir değnek olarak sunmamalı. Birkaç önemli sınır var:

  • Implementation flaws. 2009’da Rutkowska ve Wojtczuk, Invisible Things Lab’da TXT’nin spesifik implementasyon hatalarından yararlanan saldırılar gösterdiler, SMM (System Management Mode) üzerinden TXT’nin ölçüm sürecini atlatma denemeleri. Intel bu açıkları SINIT güncellemeleriyle kapatma yoluna gitti, ama hikâye, TXT’nin “felsefe olarak doğru tasarım ≠ kusursuz uygulama” gerçeğini hatırlatıyor.
  • TXT, runtime saldırılarını çözmez. Measured launch yalnızca başlatma anındaki bütünlüğü kanıtlar. Çalışan hipervizörde sonradan ortaya çıkan açıklar (örneğin VM escape) TXT’nin kapsamı dışındadır.
  • Operasyonel karmaşıklık. TPM provisioning, SINIT güncellemeleri, attestation sunucularının yönetilmesi, bunlar bugün için pek çok kurumun operasyonel olgunluğunun ötesinde gerekiyor.

Sanallaştırma güvenliği için ne demek?

Veri merkezinde çalıştığımız hipervizörlerin doğruluğunu donanım düzeyinde kanıtlayabilmek, multi-tenant bulut altyapıları için kritik bir yapıtaşı. Kurumun veri merkezinde fiziksel erişim kontrolü iyiyse, “altımdaki hipervizör tam olarak yüklediğim şey mi?” sorusu marjinal kalabilir; ama bir bulut sağlayıcının veri merkezinde çalışan müşteri için aynı soru çok daha keskin bir hâl alıyor. TXT, ilerleyen yıllarda bulut sağlayıcılarının müşterilerine sunabileceği “platform bütünlüğü kanıtı” hizmetlerinin altyapısı olacak gibi duruyor, örneğin VMware vSphere 4.1’de TXT desteği gelmiş durumda, Xen ve KVM tarafında da tboot tabanlı entegrasyonlar mevcut.

Blue Pill bize “donanım sanallaştırma uzantıları neden tek başına yetmez” diye sordu; TXT, “çünkü güvenin bir kökü olmalı, ve o kök silikondadır” diye cevap veriyor. Mükemmel bir cevap değil, ama doğru yönde önemli bir adım. Önümüzdeki yıllarda bu tartışmanın bulut tarafında daha çok somut ürün doğuracağını öngörüyorum.