Implementasi MOR yang aman

Artikel
03/22/2023

Ringkasan

Perilaku MorLock, revisi 2

Terakhir diperbarui

Agustus 2020

Berlaku untuk

Windows 10
Vendor OEM dan BIOS yang ingin mendukung fitur Credential Guard Windows 10.

Spesifikasi resmi

Bacaan yang disarankan

Gambaran Umum

Topik ini menjelaskan perilaku dan penggunaan untuk MemoryOverwriteRequestControlLock variabel UEFI, revisi 2.

Untuk mencegah serangan memori tingkat lanjut, mitigasi keamanan BIOS sistem yang ada MemoryOverwriteRequestControl ditingkatkan untuk mendukung penguncian untuk bertahan dari ancaman baru. Model ancaman diperluas untuk menyertakan kernel OS host sebagai musuh, sehingga ACPI dan UEFI Runtime Services yang dijalankan pada tingkat hak istimewa kernel tidak tepercaya. Mirip dengan implementasi Boot Aman, MorLock harus diimplementasikan dalam konteks eksekusi firmware istimewa yang tidak dapat diubah oleh kernel OS host (misalnya, Mode Manajemen Sistem, TrustZone, BMC, dan sebagainya). Antarmuka ini dibangun di atas layanan variabel UEFI, yang dijelaskan dalam Spesifikasi UEFI versi 2.5, Bagian 7.2 bernama "Layanan Variabel".

Mitigasi ini, yang disebut MorLock, harus diimplementasikan pada semua sistem baru dan tidak hanya terbatas pada sistem dengan Modul Platform Tepercaya. Revisi 2 menambahkan kemampuan baru, membuka kunci, untuk mengurangi masalah performa boot, terutama pada sistem memori besar.

Mengenai metode kontrol ACPI _DSM untuk mengatur status bit MOR (seperti yang dijelaskan dalam Bagian 6 Spesifikasi Mitigasi Serangan Reset Platform Grup Kerja Klien PC, Versi 1.10 (unduhan PDF)), sebaiknya hapus metode _DSM ini dari implementasi BIOS modern.

Namun, jika BIOS menerapkan metode _DSM ini, bioS harus menghormati keadaan MorLock. Jika MorLock dikunci, dengan atau tanpa kunci, metode _DSM ini harus gagal mengubah MOR dan mengembalikan nilai 1 yang sesuai dengan "Kegagalan Umum". Tidak ada mekanisme ACPI yang didefinisikan untuk membuka kunci revisi MorLock 2.

Perhatikan bahwa Windows belum secara langsung memanggil metode _DSM ini sejak Windows 7 dan menganggapnya tidak digunakan lagi. Beberapa BIOS secara tidak langsung memanggil metode _DSM ini ketika Windows memanggil ACPI _PTS sebagai implementasi Deteksi Otomatis MOR dari Matikan Bersih (seperti yang dijelaskan dalam Bagian 2.3 dari PC Client Work Group Platform Reset Spesifikasi Mitigasi Serangan, Versi 1.10 (unduhan PDF)).

ACPI ini _PTS implementasi Deteksi Otomatis MOR kekurangan keamanan dan TIDAK boleh digunakan.

MemoryOverwriteRequestControlLock

BIOS yang berisi mitigasi yang ditingkatkan membuat variabel UEFI ini selama boot awal:

VendorGuid:{BB983CCF-151D-40E1-A07B-4A17BE168292}

Nama:MemoryOverwriteRequestControlLock

Atribut: NV+BS+RT

Nilai GetVariable dalam parameter Data : 0x0 (tidak terkunci); 0x1 (terkunci tanpa kunci); 0x2 (dikunci dengan kunci)

Nilai SetVariable dalam parameter Data : 0x0 (tidak terkunci); 0x1 (terkunci)

Mengunci dengan SetVariable

Pada setiap boot, BIOS harus menginisialisasi MemoryOverwriteRequestControlLock ke nilai byte tunggal 0x00 (menunjukkan tidak terkunci) sebelum fase Pemilihan Perangkat Boot (BDS) (DRIVER#####, SYSPREP####, BOOT####, *RECOVERY*, ...). Untuk MemoryOverwriteRequestControlLock (dan MemoryOverwriteRequestControl), BIOS harus mencegah penghapusan variabel dan atribut harus disematkan ke NV+BS+RT.

Ketika SetVariable untuk MemoryOverwriteRequestControlLock pertama kali dipanggil dengan meneruskan nilai non-nol yang valid dalam Data, mode akses untuk keduanya MemoryOverwriteRequestControlLock dan MemoryOverwriteRequestControl diubah menjadi baca-saja, menunjukkan bahwa nilai tersebut dikunci.

Implementasi revisi 1 hanya menerima satu byte 0x00 atau 0x01 untuk MemoryOverwriteRequestControlLock.

Revisi 2 juga menerima nilai 8-byte yang mewakili kunci rahasia bersama. Jika ada nilai lain yang ditentukan dalam SetVariable, panggilan gagal dengan status EFI_INVALID_PARAMETER. Untuk menghasilkan kunci tersebut, gunakan sumber entropi berkualitas tinggi seperti Modul Platform Tepercaya atau generator nomor acak perangkat keras.

Setelah mengatur kunci, pemanggil dan firmware harus menyimpan salinan kunci ini di lokasi yang dilindungi kerahasiaan, seperti SMRAM pada IA32/X64 atau prosesor layanan dengan penyimpanan yang dilindungi.

Mendapatkan status sistem

Dalam Revisi 2, ketika MemoryOverwriteRequestControlLock variabel dan MemoryOverwriteRequestControl dikunci, pemanggilan SetVariable (untuk variabel tersebut) pertama kali diperiksa terhadap kunci terdaftar dengan menggunakan algoritma waktu konstan. Jika kedua kunci ada dan cocok, variabel beralih kembali ke status tidak terkunci. Setelah upaya pertama ini atau jika tidak ada kunci yang terdaftar, upaya berikutnya untuk mengatur variabel ini gagal dengan EFI_ACCESS_DENIED untuk mencegah serangan brute force. Dalam hal ini, reboot sistem akan menjadi satu-satunya cara untuk membuka kunci variabel.

Sistem operasi mendeteksi keberadaan MemoryOverwriteRequestControlLock dan statusnya dengan memanggil GetVariable. Sistem kemudian dapat mengunci nilai MemoryOverwriteRequestControl saat ini dengan mengatur nilai ke MemoryOverwriteRequestControlLock 0x1. Atau, ini dapat menentukan kunci untuk mengaktifkan pembukaan kunci di masa depan setelah data rahasia dihapus dari memori dengan aman.

Memanggil GetVariable untuk MemoryOverwriteRequestControlLock mengembalikan 0x0, 0x1, atau 0x2 untuk menunjukkan tidak terkunci, terkunci tanpa kunci, atau dikunci dengan status kunci.

Pengaturan MemoryOverwriteRequestControlLock tidak berkomitmen untuk berkedip (hanya mengubah status kunci internal). Mendapatkan variabel mengembalikan status internal dan tidak pernah mengekspos kunci.

Contoh penggunaan oleh sistem operasi:

if (gSecretsInMemory)
{
    char data = 0x11;
    SetVariable(MemoryOverwriteRequestControl, sizeof(data), &data);
}

// check presence
status = GetVariable(MemoryOverwriteRequestControlLock, &value);  

if (SUCCESS(status))
{
    // first attempt to lock and establish a key
    // note both MOR and MorLock are locked if successful

    GetRNG(8, keyPtr);
    status = SetVariable(MemoryOverwriteRequestControlLock, 8, keyPtr);

    if (status != EFI_SUCCESS)
    {
        // fallback to revision 1 behavior
        char data = 0x01;
        status = SetVariable(MemoryOverwriteRequestControlLock, 1, &data);
        if (status != EFI_SUCCESS) { // log error, warn user }
    }
}
else
{
    // warn user about potentially unsafe system
}

// put secrets in memory

// … time passes …

// remove secrets from memory, flush caches

SetVariable(MemoryOverwriteRequestControlLock, 8, keyPtr);