Giriş
Platform Secure Boot'un, (Bundan sonra PSB olarak anılacaktır.) nasıl çalıştığına, nasıl yapılandırılması gerektiğine ve doğal olarak çeşitli büyük firmaların bunu nasıl yapmadığına dair ilk bakış da dahil olmak üzere PSB'nin en ince ayrıntılarına daha derinlemesine bakacağız.
Mimari
Başlangıç olarak, UEFI önyükleme sürecinin SEC, PEI, DXE, BDS, TSL, RT ve AL olarak adlandırılan çeşitli aşamalara ayrıldığını anlamak önemlidir. Kısacası, PSB'nin rolü, ilk UEFI aşamalarının, özellikle de SEC ve PEI aşamasının düzgün bir şekilde doğrulanmasını ve kurcalanmamasını sağlamaktır. PEI aşaması da DXE aşamasını tescilli ve firmaya özel bir yöntem kullanarak doğrular.
Ortaya çıkan şema aşağıdaki resimde özetlenmiştir:
Sıfırlandığında, yalnızca AMD yongasına gömülü ARM tabanlı bir yardımcı işlemci olan AMD Platform Güvenlik İşlemcisi (PSP) çalışır. Bir donanım güven kökü olarak işlev görür ve UEFI ürün yazılımının SEC ve PEI aşaması bölümlerini doğrular. Doğrulama başarılı olursa, SEC ve PEI aşamasını yürütmeye başlayan ana çekirdekleri serbest bırakır.
Güven Hiyerarşisi
Güven hiyerarşisini daha derinlemesine anlamak için, öncelikle SPI flaşında saklanan UEFI ürün yazılımının nasıl yapılandırıldığına bir göz atacağız. Bunu yapmak için, AMD tabanlı bir Huawei Matebook 16'dan elde ettiğimiz SPI flash çıktısını kullanacağız.
Güvenilir UEFI aracımızla bir SPI flash çıktısını açtığımızda, diğerlerinin yanı sıra genellikle aşağıdaki yapıları göreceğiz:
Ancak UEFI Aracı, UEFI önyükleme sürecinin DXE aşamasında yürütülen kodu içeren ürün yazılımı birimlerini doğru bir şekilde tanımlarken, SEC ve PEI aşamalarında çalışan kod tamamen eksik görünüyor. Bunun nedeni, Gömülü Ürün Yazılımı Yapısı (EFS) adı verilen AMD platformuna özgü bir yapının ayrıştırılmasını desteklememesidir. Bir kez daha, yapı nispeten karmaşık olduğundan, kısalık adına, yalnızca güven zinciriyle ilgili kısımlara odaklanacağız.
EFS SPI, flaşta önceden tanımlanmış konumlardan birinde bulunur ve aşağıdaki pointerleri içerir:
PSP dizin tablosu:
BIOS dizin tablosu da şunları içerir:
Sıfırlamanın ardından PSP ana çekirdekleri tutacak ve güven zincirini aşağıdaki sırayla doğrular:
Bu noktada PSP ana çekirdekleri serbest bırakır ve PEI ürün yazılımı biriminde saklanan SEC+PEI faz kodu yürütülür. Ardından, güven zincirini tamamlamak için satıcıya özgü bir PEI modülü DXE ürün yazılımı birim(ler)ini doğrulayacaktır.
PSB Yapılandırması
Bir sonraki adım, PSB'nin düzgün yapılandırılıp yapılandırılmadığını belirlemek için PSP ile nasıl etkileşime girebileceğimizi anlamaktır. Bu da potansiyel yanlış yapılandırmaları tespit etmek için basit bir araç uygulamak için kullanılabilir.
Burada, önce PSP MMIO temel adresini belirleyerek ve ardından belirli bir ofsette PSB ile ilgili iki registerin değerini okuyarak yapılandırmanın kontrol edilebileceğini bulabiliriz.
PSP MMIO Temel Adresi
İlk olarak, PSP MMIO temel adresi AMD IOHUB Çekirdeğinin (IOHC) bir kaydına belirli bir değer yazılarak elde edilir. Daha spesifik olarak:
17H ailesi, model 30H/70H için
Diğer tüm modeller için
IOHC cihazının
Örneğin, bir Acer Swift 3'te, IOHC'nin
PSB Yapılandırma Kayıtları
PSB fuse kaydı,
Aşağıdakiler gibi çeşitli alanlara sahiptir:
İlginç bir şekilde, PSB etkinleştirme biti 0'a ve müşteri tuş kilidi 1'e ayarlanarak PSB kalıcı olarak devre dışı bırakılabilir. Bu, bir saldırganın sistemi süresiz olarak savunmasız bırakmasını sağlar ve Alexander Ermolov tarafından Intel BootGuard için keşfedilene benzer.
PSB durum kaydı,
Burada sadece PSB durum alanının herhangi bir hata oluşmadıysa
Güvenlik Açıkları
Artık PSB'nin nasıl yapılandırılması gerektiğini anladığımıza göre, yanlış yapılandırma ve uygulama sorunları üzerinden size yol göstermek istiyorum.
Bütünlük açısından, test edilen sistemlerin listesi ve güvenlik açığı olup olmadıkları bu blogun sonundaki bir tabloda bulunabilir.
Yapılandırma kusurları
Aşağıda görülebileceği gibi, Lenovo IdeaPad 1 Gen7'de (BIOS JTCN44WW) PSB fuse kaydı imha olmamış ve PSB durum alanı sıfır olmayan bir değer döndürüyor. Aslında, aynı model diğer tüm savunmasız sistemlerde de gözlemlenmiştir.
Temel nedeni belirlemeye çalışırken, BIOS imzalama anahtarı ve BIOS PEI ürün yazılımı birim imzası gibi PSB'nin doğru çalışması için gerekli olan çeşitli veri yapılarının eksik olduğunu gördüm. Bu durum, ürün yazılımı imajının oluşturulma süreci sırasında bu özelliğin devre dışı bırakıldığını gösteriyor olabilir.
Uygulama hataları
Yapılandırma kusurlarının ötesinde, herhangi bir potansiyel uygulama sorunu olup olmadığını da öğrenmek istedim. AMD, SEC ve PEI aşamasını doğrulayan güven zincirinin ilk bölümünü uygularken, ben DXE aşamasını doğrulayan firmaya özgü bölüme odaklanmaya karar verdim.
Başlangıç olarak, PSB'nin etkin olduğu birkaç sistemden biri olduğu için Lenovo Thinkpad P16s Gen1'i (BIOS v1.32) hedefim olarak seçtim ve UEFI aracı ile ürün yazılımını inceledim. Görünüşe göre, DXE aşamasını doğrulamak için Phoenix tabanlı bir BIOS ve Phoenix hash dosyası adı verilen iyi bilinen bir veri yapısı kullanıyor:
Phoenix hash dosya formatı basittir - temel adres, boyut ve hash'ten oluşan üçlüler kullanılarak kodlanmış SPI flaşın korumalı aralıklarının bir listesidir. Bu korumalı aralıklar, en azından teoride, yüklenecek olan DXE ürün yazılımı birimlerinde depolanan DXE faz kodunu kapsamalıdır.
Ancak, birden fazla ürün yazılımı biriminin kullanıldığını ve bunlardan birinin (GUID 8FC151AE-C96F-4BC9-8C33-107992C7735B) korumalı aralıklar tarafından kapsanmadığını tespit ettim. Bu nedenle, söz konusu birimin içerdiği kod kurcalanabilir ve önyükleme işlemi sırasında otomatik olarak yüklenebilir.
Daha da kötüsü, PSP tarafından doğrulanan BIOS PEI aygıt yazılımı biriminin, aygıt yazılımının başında dolgu bölümünde yer alırken, Phoenix hash dosyasının sonunda yer aldığını ve bu nedenle kurcalanabileceğini fark ettim.
Sorunun gerçekten exploit edilebilir olduğunu doğrulamak için PersistenceConfigDxe DXE sürücüsünü (GUID 27A95D13-15FB-4A2E-91E2-C784BF0D20D3) SMM_KEY MSR'yi yapılandıran ve çalışma zamanında TSEG korumalarını devre dışı bırakmama ve böylece SMM'ye ayrıcalıkları önemsiz bir şekilde yükseltmeme olanak tanıyan kötü amaçlı bir DXE sürücüsü ile değiştirdim.
Lenovo tarafından bu güvenlik açığı (CVE-2023-5078 olarak atanmıştır) için hangi sistemleri etkilediğini ve farklı BIOS güncellemelerinin ne zaman yayınlandığını detaylandıran bir yazı yayınlandığını unutmayın (buraya bakın).
Sonuçlar
Araştırmanın sonuçları, firmaların sistematik olarak platformu düzgün bir şekilde yapılandırmada ya da güven zincirini doğru bir şekilde uygulamada nasıl başarısız olduklarını göstermektedir. Bu sorunun nasıl ele alınması gerektiği açık olmasına rağmen, firmaların yanıtlarına göre, bunu yapmakta isteksiz oldukları görülmektedir.
Bu sorunlar, işletim sisteminde yer edinen bir saldırganın, SPI flash yazma ilkeliyle (örn. CVE-2023-28468) birlikte sisteme ürün yazılımı implantları yüklemesine olanak tanıyacaktır. Bunlar, tasarım gereği, uygulanabilecek işletim sistemi ve Hipervizör düzeyindeki korumaları atlar ve düzgün bir şekilde yapılırsa, geleneksel ürün yazılımı güncellemelerine karşı da dirençli hale getirilebilir.
Ekler
Aşağıdaki tabloda test edilen sistemler ve keşfedilenler listelenir:
Kaynak: Exploring AMD Platform Secure Boot
Platform Secure Boot'un, (Bundan sonra PSB olarak anılacaktır.) nasıl çalıştığına, nasıl yapılandırılması gerektiğine ve doğal olarak çeşitli büyük firmaların bunu nasıl yapmadığına dair ilk bakış da dahil olmak üzere PSB'nin en ince ayrıntılarına daha derinlemesine bakacağız.
Mimari
Başlangıç olarak, UEFI önyükleme sürecinin SEC, PEI, DXE, BDS, TSL, RT ve AL olarak adlandırılan çeşitli aşamalara ayrıldığını anlamak önemlidir. Kısacası, PSB'nin rolü, ilk UEFI aşamalarının, özellikle de SEC ve PEI aşamasının düzgün bir şekilde doğrulanmasını ve kurcalanmamasını sağlamaktır. PEI aşaması da DXE aşamasını tescilli ve firmaya özel bir yöntem kullanarak doğrular.
Ortaya çıkan şema aşağıdaki resimde özetlenmiştir:
Sıfırlandığında, yalnızca AMD yongasına gömülü ARM tabanlı bir yardımcı işlemci olan AMD Platform Güvenlik İşlemcisi (PSP) çalışır. Bir donanım güven kökü olarak işlev görür ve UEFI ürün yazılımının SEC ve PEI aşaması bölümlerini doğrular. Doğrulama başarılı olursa, SEC ve PEI aşamasını yürütmeye başlayan ana çekirdekleri serbest bırakır.
Güven Hiyerarşisi
Güven hiyerarşisini daha derinlemesine anlamak için, öncelikle SPI flaşında saklanan UEFI ürün yazılımının nasıl yapılandırıldığına bir göz atacağız. Bunu yapmak için, AMD tabanlı bir Huawei Matebook 16'dan elde ettiğimiz SPI flash çıktısını kullanacağız.
Güvenilir UEFI aracımızla bir SPI flash çıktısını açtığımızda, diğerlerinin yanı sıra genellikle aşağıdaki yapıları göreceğiz:
- Padding alanları
- Ürün yazılımı birimleri (DXE sürücüleri ve SMM modülleri içerir)
- NVRAM verileri (non-volatile yapılandırma verilerini, yani UEFI değişkenlerini içerir)
Ancak UEFI Aracı, UEFI önyükleme sürecinin DXE aşamasında yürütülen kodu içeren ürün yazılımı birimlerini doğru bir şekilde tanımlarken, SEC ve PEI aşamalarında çalışan kod tamamen eksik görünüyor. Bunun nedeni, Gömülü Ürün Yazılımı Yapısı (EFS) adı verilen AMD platformuna özgü bir yapının ayrıştırılmasını desteklememesidir. Bir kez daha, yapı nispeten karmaşık olduğundan, kısalık adına, yalnızca güven zinciriyle ilgili kısımlara odaklanacağız.
EFS SPI, flaşta önceden tanımlanmış konumlardan birinde bulunur ve aşağıdaki pointerleri içerir:
PSP dizin tablosu:
- BIOS imzalama anahtarı (giriş tipi 0x05)
- BIOS PEI ürün yazılımı birimi (giriş tipi 0x62)
- BIOS PEI ürün yazılımı birim imzası (giriş tipi 0x07)
BIOS dizin tablosu da şunları içerir:
- AMD kök imzalama anahtarı (giriş türü 0x00)
Sıfırlamanın ardından PSP ana çekirdekleri tutacak ve güven zincirini aşağıdaki sırayla doğrular:
- AMD kök imzalama anahtarı, PSP'ye programlanmış bir SHA256 karmasına karşı doğrulanır,
- BIOS imzalama anahtarı AMD kök imzalama anahtarına karşı doğrulanır,
- BIOS PEI ürün yazılımı birimi BIOS imzalama anahtarına göre doğrulanır.
Bu noktada PSP ana çekirdekleri serbest bırakır ve PEI ürün yazılımı biriminde saklanan SEC+PEI faz kodu yürütülür. Ardından, güven zincirini tamamlamak için satıcıya özgü bir PEI modülü DXE ürün yazılımı birim(ler)ini doğrulayacaktır.
PSB Yapılandırması
Bir sonraki adım, PSB'nin düzgün yapılandırılıp yapılandırılmadığını belirlemek için PSP ile nasıl etkileşime girebileceğimizi anlamaktır. Bu da potansiyel yanlış yapılandırmaları tespit etmek için basit bir araç uygulamak için kullanılabilir.
Burada, önce PSP MMIO temel adresini belirleyerek ve ardından belirli bir ofsette PSB ile ilgili iki registerin değerini okuyarak yapılandırmanın kontrol edilebileceğini bulabiliriz.
PSP MMIO Temel Adresi
İlk olarak, PSP MMIO temel adresi AMD IOHUB Çekirdeğinin (IOHC) bir kaydına belirli bir değer yazılarak elde edilir. Daha spesifik olarak:
17H ailesi, model 30H/70H için
0x13E102E0 veya 19H ailesi, model 20h veyaDiğer tüm modeller için
0x13B102E0IOHC cihazının
0xB8 ofsetindeki yazmacına yazılır (00h veriyolunda, 00h cihazında, 00h fonksiyonunda) ve sonuç 0xBC ofsetindeki write eventinden okunur.Örneğin, bir Acer Swift 3'te, IOHC'nin
0xB8 ofsetine 0x13B102E0 değerini yazarız ve 0xBC ofsetinde 0xFDE00000 (maskelemeden sonra) temel adresini okuruz.
PSB Yapılandırma Kayıtları
PSB fuse kaydı,
0x10994 ofsetinde bulunur, gerçek fuse yapılandırmasını yansıtır ve aşağıdaki yapıya sahiptir:
Aşağıdakiler gibi çeşitli alanlara sahiptir:
- Platformu benzersiz bir şekilde tanımlamak için platform satıcı kimliği ve platform model kimliği,
- BIOS anahtar revizyonu ve BIOS imzalama anahtarlarını iptal etmek için geri revoke önleme,
- AMD kök imzalama anahtarı ile imzalanmış bir BIOS'un önyüklenmesini önlemek için AMD devre dışı bırakma anahtarı,
- Özelliği etkinleştirmek için PSB etkinleştirme alanı,
- Fuse'ları kalıcı olarak imha etmek için müşteri anahtar kilidi,
- PSB'nin etkin olduğu sistemlerde, tipik olarak platform satıcı kimliği, platform model kimliği, PSB etkinleştirme biti ve müşteri anahtar kilidinin buna göre yapılandırıldığını gözlemledik. Aslında, BIOS bu özellik etkinleştirilerek derlenmişse, sistem ilk kez açıldığında birleştirme işlemi otomatik olarak gerçekleşir.
İlginç bir şekilde, PSB etkinleştirme biti 0'a ve müşteri tuş kilidi 1'e ayarlanarak PSB kalıcı olarak devre dışı bırakılabilir. Bu, bir saldırganın sistemi süresiz olarak savunmasız bırakmasını sağlar ve Alexander Ermolov tarafından Intel BootGuard için keşfedilene benzer.
PSB durum kaydı,
0x10998 ofsetinde bulunur, PSB durum bilgisini elde etmek için kullanılır ve aşağıdaki yapıya sahiptir:
Burada sadece PSB durum alanının herhangi bir hata oluşmadıysa
0x00 değerini döndürdüğünü biliyoruz; aksi takdirde muhtemelen belirli bir hata koduna karşılık gelen sıfır olmayan bir değer döndürür.Güvenlik Açıkları
Artık PSB'nin nasıl yapılandırılması gerektiğini anladığımıza göre, yanlış yapılandırma ve uygulama sorunları üzerinden size yol göstermek istiyorum.
Bütünlük açısından, test edilen sistemlerin listesi ve güvenlik açığı olup olmadıkları bu blogun sonundaki bir tabloda bulunabilir.
Yapılandırma kusurları
Aşağıda görülebileceği gibi, Lenovo IdeaPad 1 Gen7'de (BIOS JTCN44WW) PSB fuse kaydı imha olmamış ve PSB durum alanı sıfır olmayan bir değer döndürüyor. Aslında, aynı model diğer tüm savunmasız sistemlerde de gözlemlenmiştir.
Temel nedeni belirlemeye çalışırken, BIOS imzalama anahtarı ve BIOS PEI ürün yazılımı birim imzası gibi PSB'nin doğru çalışması için gerekli olan çeşitli veri yapılarının eksik olduğunu gördüm. Bu durum, ürün yazılımı imajının oluşturulma süreci sırasında bu özelliğin devre dışı bırakıldığını gösteriyor olabilir.
Uygulama hataları
Yapılandırma kusurlarının ötesinde, herhangi bir potansiyel uygulama sorunu olup olmadığını da öğrenmek istedim. AMD, SEC ve PEI aşamasını doğrulayan güven zincirinin ilk bölümünü uygularken, ben DXE aşamasını doğrulayan firmaya özgü bölüme odaklanmaya karar verdim.
Başlangıç olarak, PSB'nin etkin olduğu birkaç sistemden biri olduğu için Lenovo Thinkpad P16s Gen1'i (BIOS v1.32) hedefim olarak seçtim ve UEFI aracı ile ürün yazılımını inceledim. Görünüşe göre, DXE aşamasını doğrulamak için Phoenix tabanlı bir BIOS ve Phoenix hash dosyası adı verilen iyi bilinen bir veri yapısı kullanıyor:
Phoenix hash dosya formatı basittir - temel adres, boyut ve hash'ten oluşan üçlüler kullanılarak kodlanmış SPI flaşın korumalı aralıklarının bir listesidir. Bu korumalı aralıklar, en azından teoride, yüklenecek olan DXE ürün yazılımı birimlerinde depolanan DXE faz kodunu kapsamalıdır.
Ancak, birden fazla ürün yazılımı biriminin kullanıldığını ve bunlardan birinin (GUID 8FC151AE-C96F-4BC9-8C33-107992C7735B) korumalı aralıklar tarafından kapsanmadığını tespit ettim. Bu nedenle, söz konusu birimin içerdiği kod kurcalanabilir ve önyükleme işlemi sırasında otomatik olarak yüklenebilir.
Daha da kötüsü, PSP tarafından doğrulanan BIOS PEI aygıt yazılımı biriminin, aygıt yazılımının başında dolgu bölümünde yer alırken, Phoenix hash dosyasının sonunda yer aldığını ve bu nedenle kurcalanabileceğini fark ettim.
Sorunun gerçekten exploit edilebilir olduğunu doğrulamak için PersistenceConfigDxe DXE sürücüsünü (GUID 27A95D13-15FB-4A2E-91E2-C784BF0D20D3) SMM_KEY MSR'yi yapılandıran ve çalışma zamanında TSEG korumalarını devre dışı bırakmama ve böylece SMM'ye ayrıcalıkları önemsiz bir şekilde yükseltmeme olanak tanıyan kötü amaçlı bir DXE sürücüsü ile değiştirdim.
Lenovo tarafından bu güvenlik açığı (CVE-2023-5078 olarak atanmıştır) için hangi sistemleri etkilediğini ve farklı BIOS güncellemelerinin ne zaman yayınlandığını detaylandıran bir yazı yayınlandığını unutmayın (buraya bakın).
Sonuçlar
Araştırmanın sonuçları, firmaların sistematik olarak platformu düzgün bir şekilde yapılandırmada ya da güven zincirini doğru bir şekilde uygulamada nasıl başarısız olduklarını göstermektedir. Bu sorunun nasıl ele alınması gerektiği açık olmasına rağmen, firmaların yanıtlarına göre, bunu yapmakta isteksiz oldukları görülmektedir.
Bu sorunlar, işletim sisteminde yer edinen bir saldırganın, SPI flash yazma ilkeliyle (örn. CVE-2023-28468) birlikte sisteme ürün yazılımı implantları yüklemesine olanak tanıyacaktır. Bunlar, tasarım gereği, uygulanabilecek işletim sistemi ve Hipervizör düzeyindeki korumaları atlar ve düzgün bir şekilde yapılırsa, geleneksel ürün yazılımı güncellemelerine karşı da dirençli hale getirilebilir.
Ekler
Aşağıdaki tabloda test edilen sistemler ve keşfedilenler listelenir:
| Firma Adı | Model | PSB Durumu |
|---|---|---|
| Acer | Swift 3 (SF314-42) | Yapılandırılmamış |
| Acer | TravelMate P4 (P414-41) | Yapılandırılmamış |
| ASUS | Strix G15 (G513QR) | Yapılandırılmamış |
| Lenovo | Thinkpad P16s Gen1 | Yapılandırılmış (ancak savunmasız) |
| Lenovo | IdeaPad 1 Gen7 | Yapılandırılmamış |
| Lenovo | Thinkpad T495s | Yapılandırılmamış |
| Huawei | Matebook 16 | Yapılandırılmamış |
| HP | 15s (15s-eq2xxx) | Yapılandırılmamış |
| Microsoft | Surface 4 | Yapılandırılmış |
| MSI | Bravo 15 (B5DD) | Yapılandırılmamış |
Kaynak: Exploring AMD Platform Secure Boot
Son düzenleme:
