{"id":103242,"date":"2022-02-08T09:36:38","date_gmt":"2022-02-08T07:36:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-uefi-proshivkah-na-baze-frejmvorka-insydeh2o-pozvolyayushhie-vypolnit-kod-na-urovne-smm"},"modified":"2022-02-08T09:36:38","modified_gmt":"2022-02-08T07:36:38","slug":"uyazvimosti-v-uefi-proshivkah-na-baze-frejmvorka-insydeh2o-pozvolyayushhie-vypolnit-kod-na-urovne-smm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/uyazvimosti-v-uefi-proshivkah-na-baze-frejmvorka-insydeh2o-pozvolyayushhie-vypolnit-kod-na-urovne-smm","title":{"rendered":"Vulnerabilit\u00e0 nei firmware UEFI basati sul framework InsydeH2O, consentendo l'esecuzione di codice a livello SMM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nel framework InsydeH2O, utilizzato da molti produttori per creare firmware UEFI per il proprio hardware (la realizzazione pi\u00f9 comune del UEFI BIOS), sono state identificate 23 vulnerabilit\u00e0 che consentono l'esecuzione di codice a livello SMM (System Management Mode), pi\u00f9 prioritario (Ring -2) rispetto alla modalit\u00e0 hypervisor e al livello di protezione zero, con accesso illimitato all'intera memoria. Il problema interessa i firmware UEFI utilizzati da produttori come Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel e Bull Atos. <\/p>\n
Per sfruttare le vulnerabilit\u00e0 \u00e8 necessario un accesso locale con privilegi di amministratore, il che rende queste problematiche interessanti come vulnerabilit\u00e0 di secondo livello, utilizzate dopo aver sfruttato altre vulnerabilit\u00e0 nel sistema o utilizzando metodi di ingegneria sociale. L'accesso a livello SMM consente l'esecuzione di codice in un livello non controllato dal sistema operativo, il che pu\u00f2 essere utilizzato per modificare i firmware e lasciarvi codice dannoso o rootkit nascosti nella SPI Flash, non identificabili dal sistema operativo, nonch\u00e9 per disabilitare la verifica durante la fase di avvio (UEFI Secure Boot, Intel BootGuard) e attacchi agli hypervisor per eludere i meccanismi di verifica dell'integrit\u00e0 degli ambienti virtuali.
<\/center> <\/p>\n
Lo sfruttamento delle vulnerabilit\u00e0 pu\u00f2 essere effettuato dal sistema operativo tramite SMI handler (System Management Interrupt) non verificati, nonch\u00e9 in una fase precedente all'esecuzione del sistema operativo durante le fasi iniziali del boot o durante il risveglio da uno stato di sospensione. Tutte le vulnerabilit\u00e0 sono causate da problemi di gestione della memoria e sono suddivise in tre categorie: <\/p>\n
\n
SMM Callout \u2014 esecuzione del proprio codice con i diritti SMM tramite il reindirizzamento dell'esecuzione dei gestori di interruzione SWSMI su codice al di fuori di SMRAM;\n
Corruzioni di memoria che consentono all'attaccante di scrivere i propri dati in SMRAM, una speciale area di memoria isolata in cui viene eseguito codice con privilegi SMM.\n
Corruzione di memoria nel codice eseguito a livello DXE (Driver eXecution Environment). <\/ul>\n
Per dimostrare i principi dell'organizzazione di un attacco, \u00e8 stato pubblicato un esempio di exploit che consente, attraverso un attacco dal terzo o dal nullo anello di protezione, di accedere al DXE Runtime UEFI e di eseguire il proprio codice. L'exploit manipola il buffer overflow (CVE-2021-42059) nel driver UEFI DXE. Durante l'attacco, l'attaccante pu\u00f2 inserire il proprio codice nel driver DXE, che mantiene l'attivit\u00e0 anche dopo il riavvio del sistema operativo, oppure apportare modifiche all'area NVRAM nel Flash SPI. Durante l'esecuzione, il codice dell'attaccante pu\u00f2 modificare aree di memoria privilegiate, modificare i servizi EFI Runtime e influenzare il processo di avvio. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Vulnerabilit\u00e0](\"\/wp-content\/uploads\/2022\/02\/dcf918bee3be0d2788f82d325cd671c7.jpg\")
<\/center> <\/p>\n