{"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\/novosti-interneta\/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, che consentono 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 di UEFI BIOS pi\u00f9 comune), sono state identificate 23 vulnerabilit\u00e0 che consentono di eseguire codice a livello SMM (System Management Mode), un livello pi\u00f9 privilegiato (Ring -2) rispetto alla modalit\u00e0 ipervisor e al ring zero di protezione, con accesso illimitato all'intera memoria. Il problema riguarda 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 questi problemi ricercati come vulnerabilit\u00e0 di secondo livello, utilizzate dopo aver sfruttato altre vulnerabilit\u00e0 nel sistema o utilizzando tecniche di ingegneria sociale. L'accesso di livello SMM consente l'esecuzione di codice a un livello non controllato dal sistema operativo, il che pu\u00f2 essere utilizzato per modificare firmware e lasciare codice malevolo o rootkit nascosto nel SPI Flash, non rilevabile dal sistema operativo, oltre a disabilitare la verifica nella fase di avvio (UEFI Secure Boot, Intel BootGuard) e attaccare hypervisor per bypassare i meccanismi di controllo dell'integrit\u00e0 degli ambienti virtuali.
<\/center> <\/p>\n
Lo sfruttamento delle vulnerabilit\u00e0 pu\u00f2 essere effettuato dal sistema operativo tramite handler SMI (System Management Interrupt) non verificati, cos\u00ec come nelle fasi iniziali di avvio o durante il ritorno dalla modalit\u00e0 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 — esecuzione del proprio codice con diritti SMM tramite il reindirizzamento dell'esecuzione dei gestori di interruzione SWSMI al codice al di fuori di SMRAM;\n
Danni alla memoria che consentono a un attaccante di scrivere i propri dati in SMRAM, una zona di memoria isolata e speciale in cui viene eseguito codice con privilegi SMM.\n
Corruzione di memoria nel codice eseguito nel livello DXE (Driver eXecution Environment). <\/ul>\n
Per dimostrare i principi di organizzazione di un attacco, \u00e8 stato pubblicato un esempio di exploit che consente, attraverso un attacco dal terzo o dal primo anello di protezione, di accedere al DXE Runtime UEFI e di eseguire il proprio codice. L'exploit manipola un overflow dello stack (CVE-2021-42059) nel driver UEFI DXE. Durante l'attacco, l'attaccante pu\u00f2 posizionare il proprio codice in un driver DXE, che rimane attivo anche dopo il riavvio del sistema operativo, o apportare modifiche all'area NVRAM nella memoria SPI Flash. 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