ROM-urile suplimentare sunt software-uri încorporate care sunt lansate de BIOS-ul computerului în timpul inițializării platformei. Acestea sunt de obicei stocate pe cardul introdus, deși acestea pot fi, de asemenea, pe placa de sistem.
O singură interfață EFI (UEFI) suportă modul depășit al ROM-urilor suplimentare.
Conform celei mai recente specificații UEFI (actualmente 2.3.1 modificată de C - secțiunea 2.5.1.2), ROM-urile suplimentare ISA (tip mostenit) nu fac parte din specificațiile UEFI. În această discuție vor fi luate în considerare numai ROM-uri suplimentare compatibile cu UEF bazate pe PCI.
Este posibilă utilizarea altor ROM-uri atunci când nu este posibilă încorporarea firmware-ului dispozitivului în firmware-ul calculatorului. Dacă un ROM suplimentar utilizează un driver, furnizorii independenți de hardware pot folosi de asemenea acest driver și pot stoca driverul și dispozitivul în aceeași locație.
Acest document explică de ce trebuie să verificați alte ROM-uri și descrie unele metode pentru efectuarea testului.
Sprijină atât BIOS UEFI, cât și BIOS din versiunile anterioare
Mulți producători creează dispozitive care includ ROMuri suplimentare și firmware pentru multe tipuri de computere. Principalele combinații includ următoarele.
Numai învechit ROM
ROM ROM UEFI suplimentar propriu
ROM obișnuit + EBC suplimentar ROM UEFI
Memorare învechită ROM + suplimentare pe 64 de biți UEFI
Vechiul ROM UEFI + UEFI IA32 pe 64 de biți
Vechiul ROM + UEFI + UEFI IA32 pe 64 de biți + EBC UEFI suplimentar ROM
BIOS-ul UEFI poate descărca și rula driverele tradiționale de firmware dacă este activat modulul de suport compatibil (CSM). Rețineți că dacă este activată descărcarea sigură, modulul de compatibilitate compatibilitate și ROM-urile vechi sunt dezactivate, deoarece driverele tradiționale pentru firmware nu acceptă autentificarea. Dacă formatul de opțiune ROM din configurația BIOS este configurat pentru ROM învechit, atunci dispozitivul va folosi întotdeauna ROM-ul tradițional.
Dacă opțiunea ROM este instalată ca compatibilă cu UEFI. va folosi un nou EFI ROM dacă este disponibil sau o ROM veche în absența unei noi.
Driverele UEFI sunt necesare pentru multe dintre componentele de securitate ale noului firmware și pentru a permite secvența de boot UEFI. De exemplu, instalarea Windows de pe o unitate optică atașată la un controler de stocare incompatibil cu UEFI nu este posibilă dacă sistemul este pornit în modul UEFI cu boot securizat activat.
1. UEFI și ROM-uri suplimentare
Figura 2. Siguranța driverelor UEFI (sursa: UEFI 2.3.1 cu corecția C)
Din secțiunea 31.1.4 la 2.3.1 modificată de C UEFI:
Deoarece profilul utilizatorului UEFI conține o serie de beneficii legate de securitate, este important ca licențele de utilizare a regulatorului și furnizorii de acreditări de utilizator, precum și mediul în care acestea sunt realizate, sunt de încredere.
Aceasta include următoarele.
Protecția zonei de depozitare pentru șoferi.
Protecția instrumentelor de selecție a șoferului.
Protejați mediul de rulare al acestor drivere de la drivere neconfirmate.
Componentele, cum ar fi managerul de identitate, driverele de acreditare utilizator și driverele încorporate, pot fi amplasate într-o locație sigură, cum ar fi un dispozitiv de memorie flash protejat la scriere care are încredere în politica de platformă.
Unele alte drivere se pot afla în locații de stocare neprotejate, cum ar fi ROM-uri suplimentare sau partiții de disc, și pot fi ușor înlocuite. Asemenea drivere trebuie să fie verificate.
De exemplu, sau o platformă politică care este utilizată în mod implicit, ar trebui să fie în măsură să verifice cu succes driverele enumerate în parametrii driver Driver #### de descărcare, sau trebuie să verifice utilizatorului înainte de a va procesa aceste drivere. În caz contrar, executarea șoferului ar trebui să fie întârziată. Dacă profilul utilizatorului este modificat printr-un apel ulterior al comenzii de autentificare sau prin utilizarea autentificării dinamice, este posibil ca driverul #### să nu mai fie procesat din nou.
Baza de date a profilului de utilizator este închisă utilizând diverse evenimente ale semnalului UEFI bazate pe posibilitatea de a fi protejată.
UEFI și driverele UEFI ROM suplimentare rulează numai pentru dispozitivele din calea de boot.
Specificația PCI permite folosirea mai multor imagini ale ROM-urilor suplimentare pe un singur dispozitiv. Aceste ROM-uri suplimentare pot fi învechite pe 86 de biți și pe UEFI. Firmware-ul UEFI instalează o politică de platformă pentru selectarea ROM-urilor suplimentare. Din acest motiv, ROM-ul suplimentar al adaptorului poate fi executat ca un dispozitiv propriu de control.
Firmware-ul verifică semnăturile pe etapele BDS și DXE. Secvența evenimentelor este după cum urmează.
Inițierea PCI și diferențierea busului
Eșantion de dispozitiv PCI pentru ROM-urile opționale
Comparație între ROM-urile găsite în memorie
Etapa DXE: încărcarea driverelor UEFI în ROM
UEFI ROM-urile suplimentare pot fi localizate oriunde în memorie. Setarea implicită permite ROM-ului de pe placă să controleze dispozitivul. UEFI permite platformei să gestioneze politica cu privire la ce ROM suplimentar va gestiona un anumit dispozitiv utilizând EFI_PLATFORM_DRIVER_OVERRIDE. UEFI acceptă înregistrarea configurației interfeței cu ROM-uri suplimentare.
Pe un PC unde este activată boot-ul securizat, driverele ROM suplimentare prezintă un risc de securitate dacă nu au o semnătură sau nu au fost testate. Verificarea semnăturii pentru ROM-urile suplimentare este o cerință WHCK. Același lucru este valabil și atunci când deserviți alte ROM-uri, când trebuie să vă asigurați că actualizarea a fost verificată înainte de instalare.
Din specificația UEFI 2.3.1 Eratta C:
2. Descrierea problemei
Anumite ansamblul UEFI BIOS cu suport pentru pornire sigure, inclusiv Tiano Core, implicit nu autentifică opțiunea ROM UEFI, ca opțiune de ROM-uri UEFI semnate nu au fost disponibile în timpul dezvoltării sigure de boot. Aceasta reprezintă vectorii de atac posibili și vulnerabilitatea unei descărcări UEFI sigure.
2.1. vulnerabilitate
Codul sursă pentru vulnerabilitatea TianoCore este fișierul SecurityPkg \ SecurityPkg.dec:
Suprascrierea PCD trebuie plasată în secțiunea [PcdsFixedAtBuild] din fișierul DSC. Mecanismul exact de suprimare a setărilor poate varia în funcție de furnizorul BIOS.
Această vulnerabilitate poate exista în implementările anterioare ale descărcării în siguranță a UEFI în BIOS de la furnizori BIOS independenți. Contactați furnizorul BIOS pentru a afla dacă versiunea dvs. BIOS poate fi vulnerabilă.
3. În ce privește această preocupare?
Un computer UEFI pe care este implementată o descărcare sigură și care utilizează un UEFI ROM suplimentar fără semnătură. Mai mult, firmware-ul compatibil pentru a asigura funcționarea plăcilor existente poate fi vulnerabil fără efectuarea controalelor ROM suplimentare.
Netbook-uri, laptop-uri, și plăcile ultrabuki: majoritatea nu abordează backplane ROM-ul de anvelope mai frecvent utilizate ca PCI / e, ISA și derivați ai acestora (ExpressCard, miniPCI, CardBus, PCCard, LPC, trăsnete etc.). Dacă cele de mai sus nu sunt utilizate în laptop, numărul de posibile direcții de atac este redus semnificativ. În plus, driverele UEFI pentru componentele laptopului paralel sunt integrate în nucleul BIOS-ului încorporat al kernel-ului, care nu este localizat pe un ROM suplimentar separat. Prin urmare, majoritatea laptopurilor nu sunt expuse riscului. De asemenea, în cazul în care ROM-urile suplimentare învechite sunt dezactivate, UEFI pare să suporte numai ROM-uri suplimentare bazate pe PCI.
Cu toate acestea, dacă computerul dvs., placa de bază sau serverul utilizează UEFI BIOS și are o descărcare sigură, este posibil ca dispozitivul dvs. să fie vulnerabil. Pe un controler RAID dedicat, controler de stocare suplimentar pentru SATA, FC, etc. sau adaptoare de rețea Ethernet PCIe, pot fi utilizate alte dispozitive ROM. Controlerele de completare care acceptă o gamă largă de funcții pe servere sunt utilizate pe scară largă, deci acest lucru este valabil mai ales pentru spațiul de server.
De asemenea, poate afecta computerele pe 32 și 64 de biți și clasa 2 și clasa 3.
În cazul în care platforma de încărcare securizată acceptă dispozitive ROM suplimentare care nu sunt conectate la platforma în mod constant, și capacitatea de a verifica astfel de ROM suplimentare, aceasta ar trebui să sprijine, de asemenea, metodele de verificare ROM-uri opționale descrise în UDP protocoale de rețea și MTFTP și variabilele testate EFI, descrise în secțiunea caietul de sarcini 7.2 UEFI 2.3.1 modificat de C.
4. Cum efectuez verificarea?
Dacă dezvoltați software încorporat bazat pe Tiano Core, testați vulnerabilitatea menționată în secțiunea 2.1. Dacă utilizați firmware-ul unui alt furnizor independent de BIOS (IBV), contactați-l cu această întrebare. Sau puteți efectua singur testul, așa cum este descris mai jos.
Veți avea nevoie de următoarele.
PC pentru testare cu firmware-ul UEFI
Asigurați-vă că descărcarea sigură este activată
Pași pentru a efectua scanarea
Introduceți cardul PCI al suplimentului UEFI cu UEFI ROM-ul opțional în PC pentru verificare.
Activați funcția Secure Boot prin configurarea următoarelor opțiuni.
PK este testul dvs. PK sau testul PK auto-semnat
KEK - Microsoft KEK, test KEK Fabrikam, semnat cu PK, sau un alt KEK
DB - NULL. (Acest parametru este setat la "NULL").
SecureBoot - această variabilă UEFI trebuie să fie setată la "true"
Se așteaptă următorul rezultat.
Indiferent de opțiunea ROM-ul de conducător auto UEFI semnat sau nu ROM opțiune nu este încărcată dacă este setat parametrul DB la «NULL», și parametrul inclus SB (PK înregistrate și KEK).
A se vedea. De asemenea, o altă variantă a testului de mai sus în anexa A. Această abordare nu necesită valorile parametrilor DB «Null», dar pentru a efectua verificări necesare conducătorului auto UEFI ROM opțiune fără semn achiziționată de la un furnizor independent.
5. Cum pot remedia acest lucru?
Dacă verificarea de mai sus nu este finalizată, contactați IBV pentru a obține versiunile necesare și configurați-le pentru a testa alte ROM-uri. Verificați dacă firmware-ul este testat cu succes. Pentru computerele distribuite, va trebui să efectuați o actualizare de firmware sigură. Vedeți publicația NIST 800-147 și Ghidul pentru crearea și gestionarea cheilor de descărcare securizate în Windows 8.1.
Puteți testa PC-ul și utilizați Windows HCK ca instrument de validare (dar nu și un instrument de certificare) pentru a verifica dacă firmware-ul este actualizat în siguranță.
5.1. Semnarea conducătorului auto
Dacă există drivere nesemnate pentru UEFI ROM-uri suplimentare, citiți mai jos pentru informații despre cum să remediați acest lucru.
Semnați separat fiecare șofer ROM suplimentar. Acest lucru va perturba formatul PCI ROM-ului opțional. Șoferul UEFI trebuie să fie semnat numai înainte de a crea un ROM suplimentar combinat.
Înainte de a intra UEFI opțiunea driverului de imagine ROM UEFI semn sus și verificați-l la pornirea ghetei sigură în coajă UEFI (încărcare și descărcare de drivere fișier). Apoi adăugați driverul semnat la ROM-ul suplimentar combinat.
IHV dvs. poate contacta centrul Microsoft SysDev pentru a semna UEFI ROM-uri suplimentare prin serviciile disponibile în centrul SysDev.
5.2. Verificați pentru actualizări
Efectuați testul descris mai sus pentru a vă asigura că actualizarea nu este vulnerabilă. Utilizați verificarea HCK pentru a verifica dacă nu există regresii funcționale.
6. Resurse
Informații importante din specificația UEFI 2.3.1.
2.5.1. Probleme tradiționale ale unui ROM suplimentar
10. Protocoale - modelul conducătorului UEFI
13.4.2. PCI ROM-uri suplimentare
20. Codul mașinii virtuale EFI bytecode
28. Informații generale despre HII
29. Protocoale HII
30. Procesarea configurației HII și protocolul browserului
Anexa A. O abordare alternativă a testelor cu drivere ROM opționale fără semnătură
Această abordare se bazează pe primirea de fonduri de la IHV pentru a verifica dacă conducătorul UEFI ROM suplimentar este semnat.
Veți avea nevoie de următoarele.
PC pentru testare cu firmware-ul UEFI
Asigurați-vă că descărcarea sigură este activată
Mijloace de la IHV pentru a detecta semnătura driverului ROM suplimentar, dacă nu este evident - dacă driverul ROM suplimentar este semnat sau nu
Dacă firmware-ul nu este implementat corect, testul îl va afișa.
Anexa B. Scenarii pentru activarea Începerii Secure cu NULL db
Puteți utiliza fie setul curent de variabile de boot în condiții de siguranță (PK și KEK), fie puteți genera variabile de testare în scopul verificării.
Următorii pași descriu modul de creare a unui test PK, KEK și setarea parametrului DB la "NULL". Asigurați-vă că descărcarea sigură nu este activată; altfel, acești pași necesită semnarea fișierelor de bin UEFI.
Variabilele de boot sigure - DB, KEK și PK - sunt instalate în ordine inversă, deci nu este necesar să semnați fișiere UEFI bin.
Înainte de această etapă, computerul trebuie să fie în modul de instalare.
Crearea certificatelor KEK și PK
Pentru această etapă, aveți nevoie de instrumentul makecert.exe disponibil în SDK-ul Windows.
Trimiteți-le prietenilor: