Difetti di sicurezza di Windows GDI: rischi, exploit e patch

Informatec Digital » Risorse » Difetti di sicurezza di Windows GDI: rischi, exploit e patch

L' interfaccia grafica utente di Windows (GDI) si occupa del rendering di finestre, testo, icone e immagini da decenni, senza che la maggior parte degli utenti se ne renda conto. Tuttavia, questo componente fondamentale del sistema è stato anche fonte di diverse vulnerabilità di sicurezza significative, alcune di tipo zero-day e altre corrette con importanti aggiornamenti di Microsoft. Quando la GDI non funziona correttamente, non si tratta solo di un'applicazione che si blocca: in alcuni casi, può causare fughe di dati, esecuzione di codice in remoto o schermate blu di errore (BSOD) che mandano in crash interi server.

Le righe seguenti descrivono in dettaglio il funzionamento di GDI, le vulnerabilità specifiche documentate negli ultimi anni (come CVE-2017-11816, CVE-2020-1435 o CVE-2023-36884 ), le modalità di sfruttamento , l'impatto reale sugli ambienti domestici e aziendali e le misure pratiche che amministratori e professionisti della sicurezza informatica possono adottare per proteggere i propri sistemi Windows, dalle versioni precedenti come Windows Vista SP2 alle edizioni più recenti di Windows 11 e Windows Server.

Che cos'è Windows GDI e perché è così delicato in termini di sicurezza?

L'interfaccia GDI (Graphics Device Interface) è l'API legacy di Windows responsabile della gestione di tutto ciò che riguarda il rendering grafico: dal disegno di linee e rettangoli alla visualizzazione di font, bitmap e immagini sullo schermo o nelle stampanti. Le applicazioni richiamano funzioni da librerie come gdi32.dll per creare contesti di dispositivo (HDC), pennelli, penne, aree e altri oggetti grafici, che vengono gestiti internamente da strutture dati controllate dal kernel.

L'architettura GDI è suddivisa tra modalità utente e modalità kernel . In modalità utente, la DLL gdi32.dll e altre librerie correlate ricevono le richieste di disegno dalle applicazioni. Queste chiamate vengono passate al sottosistema di finestre di Windows, che viene eseguito in modalità kernel tramite win32k.sys. Questa parte del kernel è quella che effettivamente manipola la memoria di sistema, convalida gli oggetti grafici e li invia all'hardware. Qualsiasi convalida insufficiente di puntatori, dimensioni o indici in questa fase può causare errori catastrofici.

Per tracciare e riutilizzare le risorse, il sistema gestisce tabelle di oggetti GDI . Ogni processo ha la propria tabella, ma esiste anche una tabella globale per gli oggetti condivisi, il che aumenta il rischio di corruzione dei dati in caso di overflow del buffer, doppio deallocazione della memoria o riferimento di memoria non valido. Questi tipi di errori possono causare la corruzione della memoria del kernel, condizioni di gara, arresti anomali del sistema o persino l'esecuzione di codice arbitrario nel contesto più privilegiato del sistema.

Con l'avvento di API più moderne (GDI+, Direct2D, DirectWrite e persino DirectComposition), Microsoft ha ridotto l'utilizzo di GDI nelle nuove applicazioni, ma l'ecosistema software legacy che ancora si basa su di esso è enorme. Questa eredità rende GDI una superficie di attacco molto attraente per ricercatori e malintenzionati.

Vulnerabilità storiche: dalla divulgazione delle informazioni al giorno zero

Tra le vulnerabilità più datate legate a GDI si annovera una vulnerabilità documentata di divulgazione di informazioni, identificata come CVE-2017-11816 . In questo caso, il problema risiedeva nel modo in cui GDI gestiva determinati oggetti in memoria, consentendo a un utente malintenzionato di recuperare dati dal sistema di destinazione che non avrebbero dovuto essere accessibili. Non si trattava di esecuzione di codice, bensì di una grave violazione della riservatezza.

Questa vulnerabilità ha interessato diverse edizioni di Windows e ha costretto Microsoft a rilasciare uno specifico aggiornamento di sicurezza. Il difetto risiedeva nella gestione interna delle strutture grafiche: il sottosistema non riusciva a liberare o convalidare correttamente determinate aree di memoria prima di riutilizzarle, consentendo la lettura di informazioni residue appartenenti ad altri processi o al sistema operativo stesso.

La correzione è arrivata con un aggiornamento di sicurezza incluso nel consueto ciclo di "Patch Tuesday" nell'ottobre 2017. Insieme alla descrizione della vulnerabilità, Microsoft ha fornito tabelle dettagliate che elencavano i file interessati e le loro versioni più recenti: ad esempio, diverse build di gdi32.dll per piattaforme x86, x64 e IA-64, con date come l'8 settembre 2017 e versioni di file come la 6.0.6002.24200. Questi dettagli hanno permesso agli amministratori di verificare che la patch fosse stata applicata correttamente.

In seguito, i ricercatori di Project Zero (Google) hanno rivelato un'altra vulnerabilità zero-day relativa a gdi32.dll in modalità utente . Questa volta, la falla interessava la gestione dei DIB (Device Independent Bitmaps) incorporati nei registri EMF (Enhanced Metafile). Una manipolazione impropria di questi bitmap all'interno dei metafile consentiva l'estrazione di informazioni dalla memoria di processo, con conseguenze dirette sulla privacy dei dati.

Questa vulnerabilità zero-day poteva essere riprodotta localmente tramite Internet Explorer e da remoto tramite Office Online aprendo un documento DOCX con un EMF appositamente creato. L'elenco delle versioni interessate era esteso e comprendeva Windows Vista Service Pack 2 e Windows 10 , incluse versioni di Windows Server come 2012 R2 e 2016. Il problema è diventato pubblico dopo la scadenza del periodo standard di 90 giorni previsto dal Project Zero, senza che fosse stata rilasciata una patch, rendendo ufficialmente la vulnerabilità un exploit zero-day di fatto sfruttabile.

Nel frattempo, Microsoft ha subito un incidente significativo: un problema interno ha impedito il rilascio del pacchetto di patch previsto per il Patch Tuesday per un mese, ritardando le correzioni fino al ciclo successivo. Questo tipo di ritardi aumenta il tempo di esposizione delle vulnerabilità già note alla comunità scientifica.

Bug critici recenti: BSOD, esecuzione remota e grandi batch di patch

Nel corso del tempo, le vulnerabilità di GDI si sono evolute in scenari più gravi. Un esempio particolarmente eclatante è la vulnerabilità di negazione del servizio identificata come CVE-2023-36884 , che interessa le versioni di Windows 10 (a partire dalla 1607), Windows 11 e Windows Server 2016, 2019 e 2022. Sebbene l'identificativo sia stato associato a componenti diversi a seconda del bollettino, l'analisi tecnica descrive un difetto critico nel sottosistema grafico in grado di causare schermate blu di errore (BSOD) durante l'elaborazione di oggetti grafici non validi.

Il problema riguarda la funzione NtGdiDdDeleteDeviceBitmap nel file win32k.sys . Quando si gestisce una bitmap grafica o un dispositivo non validi, il codice vulnerabile non esegue un controllo completo dei limiti del buffer durante la copia dei dati da una struttura di dispositivo (ad esempio, di tipo DD_DEVICE_OEM). Questa omissione consente la sovrascrittura della memoria adiacente nel kernel, generando un'eccezione di accesso alla memoria (PAGE_FAULT_IN_NONPAGED_AREA, codice 0x00000050) e causando una schermata blu di errore (BSOD) con codici come IRQL_NOT_LESS_OR_EQUAL o simili.

Il tipico flusso di sfruttamento inizia con dati grafici incorporati in protocolli di rete come SMB o RDP, o anche tramite WebDAV o servizi di stampa. Un file EMF non valido viaggia come parte di un documento o di un flusso remoto e, quando un'applicazione come Office, Edge, un visualizzatore di immagini o persino Esplora file stesso tenta di interpretarne il contenuto, viene richiamato il sottosistema GDI per elaborarlo. La routine di parsing non riesce a convalidare correttamente alcuni registri oggetto, consentendo la dereferenziazione di un puntatore fuori intervallo e destabilizzando la memoria del kernel (in particolare il Non-Paged Pool).

Sebbene l'impatto riportato nei bollettini ufficiali si concentri sugli attacchi denial of service (DoS) , diversi ricercatori hanno evidenziato che, con tecniche più avanzate per sfruttare la corruzione della memoria (ad esempio, attaccando l'heap), potrebbe essere possibile costruire catene di vulnerabilità che portino all'esecuzione di codice in modalità kernel, analogamente a quanto osservato con vulnerabilità in altri componenti come MSHTML (caso di CVE-2021-40444).

La criticità di GDI si è riflessa anche in un'ondata di patch di grandi dimensioni. Nel luglio 2020, Microsoft ha rilasciato un aggiornamento massiccio che ha corretto 123 vulnerabilità nei suoi prodotti, 18 delle quali classificate come critiche. Tra queste, la CVE-2020-1435, direttamente correlata al modo in cui GDI manipola gli oggetti in memoria. Se un utente malintenzionato fosse riuscito a indurre una vittima ad aprire contenuti appositamente creati (ad esempio, visitando un sito web dannoso), avrebbe potuto attivare l'esecuzione di codice remoto con gli stessi privilegi dell'utente.

Nello stesso gruppo di patch sono comparse la CVE-2020-1436, associata alla gestione di font appositamente creati, e la particolarmente nota CVE-2020-1350 , una vulnerabilità critica nel server DNS di Windows con capacità simili a quelle di un worm, in grado di diffondere malware senza l'interazione dell'utente. Sebbene quest'ultima non riguardi GDI, illustra il contesto: un singolo pacchetto di patch conteneva vulnerabilità nei servizi di rete, negli hypervisor (diverse falle di esecuzione remota in Hyper-V) e nell'interfaccia grafica stessa.

Nello specifico, la vulnerabilità CVE-2020-1435 riguarda il modo in cui GDI gestisce gli oggetti grafici in memoria . Un attacco riuscito consentirebbe a un malintenzionato di installare programmi, visualizzare, modificare o eliminare dati e creare account utente con privilegi completi. Il vettore di attacco tipico consiste nell'indurre l'utente a visitare un sito web dannoso o ad aprire un file contenente risorse grafiche progettate per sfruttare la vulnerabilità. Questo si inserisce nel quadro storico di GDI: qualsiasi contenuto visivo che si basa sul suo motore di rendering può rappresentare una vulnerabilità se il sistema non è aggiornato.

Nello stesso ciclo di patch di luglio 2020, sono state annunciate anche diverse vulnerabilità critiche in Hyper-V (CVE-2020-1041, -1040, -1032, -1036, -1042 e -1043) , a dimostrazione di come diversi componenti di Windows (rete, virtualizzazione, grafica) possano diventare anelli della stessa catena di attacco se l'organizzazione non mantiene un rigoroso programma di gestione delle patch.

Impatto effettivo sui sistemi Windows, versioni interessate e vettori

La gamma di versioni interessate dalle vulnerabilità GDI è ampia. Nei casi zero-day documentati da Project Zero, la vulnerabilità in gdi32.dll ha interessato Windows Vista SP2, Windows 7, Windows 8.1, Windows 10 e diverse edizioni di Windows Server (2012 R2, 2016, ecc.). Ciò significa che un gran numero di computer, sia domestici che aziendali, potrebbero essere vittime di perdite di memoria semplicemente aprendo un documento, navigando con Internet Explorer o utilizzando Office Online.

Nell'ultimo scenario incentrato sulla schermata blu di errore (BSOD), Microsoft ha confermato che la vulnerabilità analizzata interessa Windows 10 dalla versione 1607 in poi, Windows 11 e Windows Server 2016/2019/2022 , incluse le edizioni Enterprise, Education e LTSC. Le versioni che non sono più coperte dal supporto esteso, come Windows 7 o 8.1, non sono incluse nella patch ufficiale, ma ciò non significa che siano esenti da problemi GDI; significa semplicemente che non ricevono aggiornamenti regolari.

A livello operativo, l'impatto può essere riassunto in tre categorie: divulgazione di informazioni (lettura di memoria che dovrebbe essere privata), negazione del servizio (schermate blu ricorrenti) ed esecuzione di codice remoto . Negli ambienti aziendali, una schermata blu su un server con ruoli critici (ad esempio, un server di stampa condiviso o un host Hyper-V) può innescare una reazione a catena di guasti: interruzione dei servizi di stampa, arresto imprevisto delle macchine virtuali, perdita di dati nelle sessioni remote e lunghi tempi di ripristino.

Dal punto di vista della rete, GDI può essere sfruttato tramite protocolli come SMB (porta 445), RDP o WebDAV se un qualsiasi servizio elabora automaticamente le immagini EMF/WMF o i metadati ricevuti. A livello locale, è sufficiente che un utente apra un file dannoso in applicazioni che utilizzano GDI, come Paint, WordPad, visualizzatori di immagini meno recenti o persino processi coinvolti nell'anteprima di icone e miniature in Esplora file . Le catene di attacco più comuni combinano un'e-mail di phishing con un documento DOCX o PDF contenente un file EMF danneggiato.

Nelle organizzazioni regolamentate (finanza, sanità, pubblica amministrazione), gli incidenti causati da vulnerabilità non corrette possono avere conseguenze legali e normative. Una schermata blu di errore (BSOD) che manda in crash un sistema critico può essere considerata un evento di sicurezza che compromette la continuità del servizio, il che a sua volta può innescare audit e sanzioni relative a normative come il GDPR o l'HIPAA. Inoltre, diversi report di intelligence sulle minacce hanno attribuito lo sfruttamento di falle nei sottosistemi grafici a gruppi APT che prendono di mira obiettivi di alto valore in Asia e in Europa.

È importante ricordare che, secondo i dati comunemente utilizzati nel settore (ad esempio, quelli riportati nei report annuali sulle violazioni dei dati), una percentuale significativa di dispositivi Windows rimane senza aggiornamenti per oltre 90 giorni dopo il rilascio di aggiornamenti critici. Ciò offre agli aggressori un ampio margine di opportunità per automatizzare gli exploit e integrarli in framework come Metasploit o Cobalt Strike, in grado di scansionare intere reti alla ricerca di host vulnerabili.

Come Microsoft distribuisce le correzioni e quale file viene modificato

Quando viene scoperta una vulnerabilità in GDI, Microsoft rilascia un aggiornamento di sicurezza, in genere incluso in pacchetti cumulativi mensili. Questi aggiornamenti vengono solitamente distribuiti tramite Windows Update , il Catalogo di Microsoft Update o strumenti di gestione come Windows Server Update Services (WSUS) e Microsoft Endpoint Configuration Manager (MECM). Nel caso della vulnerabilità CVE-2017-11816, l'aggiornamento corrispondente (ad esempio, KB4042121 per Windows Server 2008) poteva essere ottenuto tramite Windows Update o il catalogo, come file .msu autonomo.

Una particolarità che Microsoft sottolinea è che, se i pacchetti lingua vengono installati dopo l'aggiornamento , è necessario reinstallare la patch di sicurezza. Pertanto, si raccomanda sempre di installare prima le lingue necessarie e poi gli aggiornamenti. Questo dettaglio, che può sembrare insignificante, ha portato a più di un caso in cui un sistema è stato erroneamente ritenuto aggiornato quando, in realtà, alcuni file binari GDI non contenevano la versione corretta.

Nella documentazione relativa a questi bollettini, Microsoft fornisce tabelle dettagliate con informazioni sui file : nome (ad esempio, gdi32.dll), versione specifica, dimensione, data, ora e piattaforma (x86, x64, IA-64). Queste tabelle consentono ad amministratori e revisori di verificare in modo forense se è installato il file binario corretto. Un processo simile viene utilizzato per i pacchetti .msu e .exe delle diverse edizioni di Windows e Office, dove vengono elencati gli hash SHA1 e SHA256 di ciascun file in modo che i team possano verificarne l'integrità.

L'elenco di file e hash è impressionante: da Windows6.0-KB2834886-x86.msu e le sue varianti x64 e ia64, passando per Windows6.1-KB2835364-x64.msu, Windows8-RT-KB2835361-x86.msu, decine di programmi di installazione per Windows Server 2003 e Windows XP in tutti i tipi di lingue (CHS, CHT, DEU, ESN, FRA, ITA, JPN, KOR, PTB, PTG, RUS, ecc.), fino a patch per componenti di Office e Lync come AttendeeAdmin.msp, ogl2007-kb2687309-fullfile-x86-glb.exe o lyncloc2013-kb2817465-fullfile-x64-glb.exe. Ciascuno di essi incorpora i propri hash SHA1 e SHA256 per facilitare la verifica.

In tutti questi casi, l'obiettivo finale è lo stesso: aggiornare il file gdi32.dll (o i relativi file binari del sottosistema grafico) alla versione sicura. Su piattaforme come Windows Server 2008, ad esempio, gdi32.dll è elencato come versione 6.0.6002.24200, con dimensioni che variano a seconda dell'architettura (circa 299.520 byte su x86, 391.680 byte su x64 e 955.392 byte su IA-64). Questi valori, insieme alla data di compilazione, sono il riferimento di base per determinare se il sistema ha la patch applicata.

La documentazione ufficiale fa riferimento anche ad articoli della Knowledge Base con dettagli sull'implementazione e la distribuzione di questi aggiornamenti, nonché a collegamenti a risorse di supporto: pagine di aiuto di Windows Update, portali di sicurezza per professionisti IT (come TechNet Security), siti di supporto internazionali e servizi specifici per la lotta al malware con il marchio Microsoft Secure.

Buone pratiche per la mitigazione, il monitoraggio e la risposta

Oltre all'installazione delle patch non appena disponibili, esistono diverse misure di mitigazione e di difesa multilivello che contribuiscono a ridurre il rischio associato ai malfunzionamenti di GDI, soprattutto in ambienti aziendali con centinaia o migliaia di computer.

Innanzitutto, è consigliabile limitare la superficie di attacco disabilitando o limitando l' elaborazione automatica di determinati formati grafici in applicazioni e browser. Ad esempio, in Microsoft Edge, è possibile configurare i criteri di gruppo per bloccare o controllare il download e la gestione dei metadati EMF/WMF utilizzando le chiavi di registro in HKLM\SOFTWARE\Policies\Microsoft\Edge relative alle restrizioni di download. In altre applicazioni, è possibile utilizzare le opzioni di configurazione per impedire l'anteprima automatica dei documenti provenienti da posizioni non attendibili e consultare le guide alla risoluzione dei problemi per risolvere i problemi di mancata risposta di Esplora file.

Un altro livello essenziale è la segmentazione della rete secondo i principi Zero Trust . Ciò include la limitazione del traffico SMB, RDP e di altri protocolli potenzialmente vulnerabili alle sole sottoreti strettamente necessarie, l'implementazione di firewall di nuova generazione con ispezione approfondita dei pacchetti e l'applicazione di regole basate sull'identità e sul contesto. Limitando i dispositivi che possono comunicare con i vari servizi, l'impatto di un attacco che tenta di diffondersi lateralmente viene drasticamente ridotto.

Sul fronte del rilevamento, l'implementazione di soluzioni di Endpoint Detection and Response (EDR), come Microsoft Defender for Endpoint, aiuta a monitorare i comportamenti anomali relativi a win32k.sys, gdi32.dll e agli eventi BSOD . La configurazione di avvisi per picchi di errori di schermata blu (ad esempio, a partire dall'ID evento 1001 nel Visualizzatore eventi) e accessi insoliti al sottosistema grafico può aiutare a identificare tentativi di sfruttamento o instabilità causate da malware.

Per la gestione delle patch, è fortemente consigliato automatizzare la distribuzione utilizzando Windows Update for Business, WSUS o MECM, ma includendo sempre una fase di test in ambienti di staging per rilevare potenziali regressioni prima della messa in produzione. Nelle infrastrutture isolate dalla rete, è consigliabile controllare tutti i file in entrata con strumenti come le regole YARA, progettate per riconoscere modelli sospetti nei formati EMF/WMF e altri formati grafici.

In scenari più avanzati, alcune organizzazioni stanno valutando la possibilità di migrare le proprie applicazioni interne verso API più moderne come Direct2D, DirectWrite o motori grafici multipiattaforma (Cairo, Skia), che offrono un migliore isolamento e una minore dipendenza dalle vecchie GDI. Nel medio termine, Microsoft potrebbe deprecare parti significative di GDI nelle future versioni di Windows per ridurre la superficie di attacco, sebbene la compatibilità con i software meno recenti rimarrà una sfida.

Dal punto di vista forense e del reverse engineering, strumenti come WinDbg, KD e Volatility consentono di analizzare i dump di memoria successivi a una schermata blu di errore (BSOD - Blue Screen of Death) e di osservare la corruzione nella memoria etichettata "Gdi" all'interno del pool di memoria del kernel. Gli exploit proof-of-concept pubblicati a scopo di ricerca dimostrano come un EMF (Engine Memory File) con determinati registri malformati (ad esempio, in EMR_HEADER) possa forzare una condizione di gara e provocare un crash. Questa conoscenza è fondamentale per i team di risposta agli incidenti al fine di ricostruire quanto accaduto in un attacco reale.

In caso di incidente, si raccomanda di seguire protocolli d'azione come quello del NIST (Identifica, Contenimento, Eliminazione, Ripristino). Ciò implica isolare i sistemi interessati , preservare le prove (dump di memoria, log, campioni di file sospetti), distribuire le patch in sospeso, scansionare i sistemi con strumenti antimalware aggiornati e ripristinare da backup verificati o tornare a un punto precedente . Inoltre, è consigliabile rivedere periodicamente le lezioni apprese per migliorare i processi di applicazione delle patch e di protezione del sistema.

L'intera storia di fallimenti e patch relativi a Windows GDI evidenzia quanto possano essere fragili i componenti legacy in assenza di una solida strategia di sicurezza e aggiornamento a più livelli; comprendere come vengono sfruttate queste vulnerabilità, quali versioni sono a rischio e quali controlli aggiuntivi possono essere applicati consente agli amministratori e ai professionisti della sicurezza informatica di rafforzare i propri sistemi e impedire che una semplice immagine o un metafile appositamente creato possano causare il blocco o compromettere completamente un'infrastruttura Windows.