- Windows GDI ackumulerar sårbarheter i informationsläckage, överbelastningsattacker och fjärrkörning av kod som påverkar flera versioner av Windows och Windows Server.
- Många av dessa sårbarheter utnyttjas via EMF/WMF-filer eller felaktigt formaterat grafikinnehåll som bearbetas av gdi32.dll och win32k.sys, vilket kan orsaka BSOD:er eller minnesläckor.
- Microsoft släpper patchar i kumulativa paket med ändringar i binärfiler som gdi32.dll och tillhandahåller hashkoder och filinformation för att verifiera en lyckad installation.
- Kombinationen av agil patchning, nätverkssegmentering, begränsning av farliga grafikformat och övervakning med EDR är nyckeln till att minska risken i samband med GDI.
Windows grafiska användargränssnitt (GDI) har renderat fönster, text, ikoner och bilder i årtionden utan att de flesta användare ens insett det. Denna grundläggande systemkomponent har dock också varit källan till flera betydande säkerhetsbrister, vissa nolldagsattacker och andra som patchats i massiva Microsoft-uppdateringar. När GDI kraschar är det inte bara ett program som kraschar: i vissa fall kan det leda till dataläckor, fjärrkörning av kod eller blåskärmar (BSOD) som får hela servrar att krascha.
Följande rader beskriver hur GDI fungerar, vilka specifika sårbarheter som har dokumenterats under senare år (som CVE-2017-11816, CVE-2020-1435 eller CVE-2023-36884 ), hur de utnyttjas , vilken verklig inverkan de har på hem- och företagsmiljöer, och vilka praktiska åtgärder administratörer och cybersäkerhetsexperter kan vidta för att skydda sina Windows-system, från äldre versioner som Windows Vista SP2 till moderna utgåvor av Windows 11 och Windows Server.
Vad är Windows GDI och varför är det så känsligt säkerhetsmässigt?
Graphics Device Interface (GDI) är det äldre Windows API som ansvarar för att hantera allt som rör grafikrendering: från att rita linjer och rektanglar till att visa teckensnitt, bitmappar och bilder på skärmen eller i skrivare. Program anropar funktioner från bibliotek som gdi32.dll för att skapa enhetskontexter (HDC), penslar, pennor, regioner och andra grafiska objekt, vilka hanteras under huven av kärnstyrda datastrukturer.
GDI-arkitekturen är uppdelad i användarläge och kernelläge . I användarläge tar gdi32.dll DLL och andra relaterade bibliotek emot ritningsförfrågningar från program. Dessa anrop skickas till Windows fönstersystem, som körs i kernelläge via win32k.sys. Denna kerneldel är det som faktiskt manipulerar systemminne, validerar grafiska objekt och skickar dem till hårdvaran. Otillräcklig validering av pekare, storlekar eller index vid denna tidpunkt öppnar dörren för katastrofala fel.
För att spåra och återanvända resurser underhåller systemet GDI-objekttabeller . Varje process har sin egen tabell, men det finns också en global tabell för delade objekt, vilket ökar risken för korruption om ett buffertspill, en dubbelfri händelse eller en ogiltig minnesreferens inträffar. Dessa typer av fel kan leda till korrupt kärnminne, kapplöpningsförhållanden, systemkrascher eller till och med godtycklig kodkörning i systemets mest privilegierade kontext.
Med ankomsten av mer moderna API:er (GDI+, Direct2D, DirectWrite och till och med DirectComposition) har Microsoft minskat användningen av GDI i nya applikationer, men det äldre programvaruekosystem som fortfarande förlitar sig på det är enormt. Detta arv gör GDI till en mycket attraktiv attackyta för forskare och angripare.
Historiska sårbarheter: från informationsutlämnande till dag noll
Bland de äldsta sårbarheterna kopplade till GDI finns en dokumenterad sårbarhet för informationsläckage, CVE-2017-11816 . I det här fallet låg problemet i hur GDI hanterade vissa objekt i minnet, vilket gjorde det möjligt för en illvillig användare att hämta data från målsystemet som inte borde vara åtkomliga. Det var inte kodkörning, utan snarare ett allvarligt sekretessbrott.
Denna sårbarhet påverkade olika versioner av Windows och tvingade Microsoft att släppa en specifik säkerhetsuppdatering. Bristen låg i den interna hanteringen av grafikstrukturer, där delsystemet misslyckades med att korrekt rensa eller validera vissa minnesområden innan de återanvändes, vilket gjorde det möjligt att läsa kvarvarande information som tillhör andra processer eller själva operativsystemet.
Korrigeringen kom i en säkerhetsuppdatering som inkluderades i den vanliga "Patch Tuesday"-cykeln i oktober 2017. Tillsammans med beskrivningen av sårbarheten tillhandahöll Microsoft omfattande tabeller som listade de berörda filerna och deras nyare versioner: till exempel olika versioner av gdi32.dll för x86-, x64- och IA-64-plattformar, med datum som 8 september 2017 och filversioner som 6.0.6002.24200. Denna detalj gjorde det möjligt för administratörer att bekräfta att korrigeringen hade installerats korrekt.
Senare avslöjade forskare från Project Zero (Google) ytterligare en nolldagarssårbarhet relaterad till gdi32.dll i användarläge . Den här gången påverkade felet hanteringen av DIB:er (Device Independent Bitmaps) inbäddade i EMF-register (Enhanced Metafile). Felaktig manipulation av dessa bitmappar i metafilerna möjliggjorde extraktion av information från processminne, med direkta konsekvenser för dataskyddet.
Denna nolldagarssårbarhet kunde reproduceras lokalt via Internet Explorer och på distans via Office Online genom att öppna ett DOCX-dokument med en specialutformad EMF. Listan över berörda versioner var omfattande, från Windows Vista Service Pack 2 till Windows 10 , och inkluderade Windows Server-versioner som 2012 R2 och 2016. Problemet blev offentligt efter att standardperioden på 90 dagar för Project Zero löpte ut utan att en patch släpptes, vilket officiellt gjorde sårbarheten till ett praktiskt nolldagarsutnyttjande.
Samtidigt upplevde Microsoft en anmärkningsvärd incident: ett internt problem hindrade dem från att släppa sitt planerade Patch Tuesday -patchpaket i en månad, vilket försenade korrigeringarna till nästa cykel. Den här typen av förseningar ökar exponeringstiden för sårbarheter som redan är kända för forskarsamhället.
Nyligen kritiska buggar: BSOD, fjärrkörning och stora patchbatchar
Med tiden har sårbarheter i GDI utvecklats till mer allvarliga scenarier. Ett särskilt slående exempel är en denial-of-service-sårbarhet identifierad som CVE-2023-36884 , som påverkar versioner av Windows 10 (från och med 1607), Windows 11 och Windows Server 2016, 2019 och 2022. Även om identifieraren har associerats med olika komponenter beroende på bulletinen, beskriver den tekniska analysen en kritisk brist i grafikundersystemet som kan orsaka blåskärmar (BSOD) vid bearbetning av felaktiga grafiska objekt.
Problemet relaterar till funktionen NtGdiDdDeleteDeviceBitmap i win32k.sys . Vid hantering av en ogiltig grafikbitmapp eller enhet misslyckas den sårbara koden med att utföra en grundlig buffertgränskontroll när data kopieras från en enhetsstruktur (t.ex. av typen DD_DEVICE_OEM). Denna utelämnande gör att intilliggande minne skrivs över i kärnan, vilket genererar ett minnesåtkomstundantag (PAGE_FAULT_IN_NONPAGED_AREA, kod 0x00000050) och utlöser en blåskärm (BSOD) med koder som IRQL_NOT_LESS_OR_EQUAL eller liknande.
Det typiska exploateringsflödet börjar med grafikdata inbäddade i nätverksprotokoll som SMB eller RDP, eller till och med via WebDAV eller utskriftstjänster. En felaktigt formaterad EMF-fil färdas som en del av ett fjärrdokument eller en fjärrström, och när ett program som Office, Edge, en bildvisare eller till och med Utforskaren själv försöker tolka dess innehåll, anropas GDI-undersystemet för att bearbeta den. Parsningsrutinen misslyckas med att validera vissa objektregister korrekt, vilket gör att en pekare utanför intervallet kan avreferenseras och destabilisera kärnminnet (särskilt den icke-växlingsbara poolen).
Även om den påverkan som rapporteras i officiella bulletiner fokuserar på denial of service (DoS) , har olika forskare påpekat att det, med mer avancerade tekniker för att utnyttja minneskorruption (till exempel genom att attackera heapen), kan vara möjligt att bygga kedjor som leder till kodkörning i kernelläge, liknande vad som har setts med sårbarheter i andra komponenter som MSHTML (fallet med CVE-2021-40444).
GDI:s kritiska betydelse har också återspeglats i stora vågor av patchar. I juli 2020 släppte Microsoft en omfattande uppdatering som åtgärdade 123 sårbarheter i sina produkter, varav 18 klassificerades som kritiska. Bland de senare fanns CVE-2020-1435, direkt relaterad till hur GDI manipulerar objekt i minnet. Om en angripare lyckades lura ett offer att öppna specialskrivet innehåll (till exempel genom att besöka en skadlig webbplats), kunde den utlösa fjärrkörning av kod med samma behörigheter som användaren.
I samma batch dök CVE-2020-1436 upp, kopplad till hanteringen av specialskapade teckensnitt, och den särskilt uppmärksammade CVE-2020-1350 , en kritisk sårbarhet i Windows DNS-server med maskliknande funktioner, som kan sprida skadlig kod utan användarinteraktion. Även om den senare inte påverkar GDI, illustrerar den sammanhanget: ett enda patchpaket innehöll sårbarheter i nätverkstjänster, hypervisorer (flera fjärrkörningsfel i Hyper-V) och själva det grafiska gränssnittet.
CVE-2020-1435 avser specifikt hur GDI hanterar grafikobjekt i minnet . Ett lyckat utnyttjande skulle tillåta en angripare att installera program, visa, ändra eller ta bort data och skapa användarkonton med fullständiga behörigheter. Den typiska attackvektorn innebär att lura användaren att besöka en skadlig webbplats eller öppna en fil som innehåller grafikresurser utformade för att utnyttja sårbarheten. Detta stämmer överens med GDI:s historiska mönster: allt visuellt innehåll som förlitar sig på dess renderingsmotor kan vara en sårbarhet om systemet inte är uppdaterat.
I samma patchcykel från juli 2020 tillkännagavs även flera kritiska sårbarheter i Hyper-V (CVE-2020-1041, -1040, -1032, -1036, -1042 och -1043) , vilket visar hur olika Windows-komponenter (nätverk, virtualisering, grafik) kan bli länkar i samma attackkedja om organisationen inte upprätthåller ett rigoröst patchhanteringsprogram.
Faktisk påverkan på Windows-system, berörda versioner och vektorer
Det finns många versioner som påverkas av GDI-sårbarheter. I de nolldagarsfall som dokumenterats av Project Zero påverkade sårbarheten i gdi32.dll Windows Vista SP2, Windows 7, Windows 8.1, Windows 10 och flera utgåvor av Windows Server (2012 R2, 2016, etc.). Det innebär att ett stort antal datorer, både hemmadatorer och företagsdatorer, kan drabbas av minnesläckor helt enkelt genom att öppna ett dokument, surfa med Internet Explorer eller använda Office Online.
I det senaste scenariot med fokus på BSOD bekräftade Microsoft att den analyserade sårbarheten påverkar Windows 10 från version 1607 och framåt, Windows 11 och Windows Server 2016/2019/2022 , inklusive Enterprise-, Education- och LTSC-utgåvorna. Versioner som inte längre har utökat stöd, till exempel Windows 7 eller 8.1, täcks inte av den officiella patchen, men det betyder inte att de är fria från GDI-problem; det betyder helt enkelt att de inte får regelbundna korrigeringar.
På en operativ nivå kan effekten sammanfattas i tre kategorier: informationsläckage (läsning av minne som borde vara privat), överbelastningsfel (återkommande BSOD:er) och fjärrkörning av kod . I företagsmiljöer kan ett BSOD på en server med kritiska roller (till exempel en delad skrivarserver eller en Hyper-V-värd) utlösa en kedjereaktion av fel: avbrott i utskriftstjänster, oväntad avstängning av virtuella maskiner, dataförlust i fjärrsessioner och långa återställningstider.
Ur ett nätverksperspektiv kan GDI utnyttjas via protokoll som SMB (port 445), RDP eller WebDAV om någon tjänst automatiskt bearbetar mottagna EMF/WMF-bilder eller metafiler. Lokalt krävs det bara att en användare öppnar en skadlig fil i program som använder GDI, till exempel Paint, WordPad, äldre bildvisare eller till och med processer som är involverade i förhandsgranskning av ikoner och miniatyrer i Utforskaren . De vanligaste attackkedjorna kombinerar ett nätfiskemejl med ett DOCX- eller PDF-dokument som innehåller en felaktigt formaterad EMF-fil.
I reglerade organisationer (finans, sjukvård, offentlig förvaltning) kan incidenter orsakade av opatchade sårbarheter få juridiska och regulatoriska konsekvenser. En blåskärm (BSOD) som kraschar ett kritiskt system kan betraktas som en säkerhetshändelse som äventyrar tjänstens kontinuitet, vilket i sin tur kan utlösa granskningar och påföljder relaterade till ramverk som GDPR eller HIPAA. Dessutom har olika hotinformationsrapporter tillskrivit utnyttjandet av brister i grafikdelsystem till APT-grupper som riktar sig mot värdefulla mål i Asien och Europa.
Det är värt att komma ihåg att, enligt vanlig branschdata (till exempel den som återspeglas i årliga rapporter om dataintrång), förblir en betydande andel av Windows-enheter ouppdaterade i mer än 90 dagar efter att kritiska uppdateringar har släppts. Detta ger ett brett fönstret för angripare att automatisera attacker och integrera dem i ramverk som Metasploit eller Cobalt Strike, vilka kan skanna hela nätverksområden efter sårbara värdar.
Hur Microsoft distribuerar korrigeringar och vilken fil som ändras
När en sårbarhet upptäcks i GDI släpper Microsoft en säkerhetsuppdatering, vanligtvis paketerad i månatliga uppdateringar. Dessa uppdateringar levereras vanligtvis via Windows Update , Microsoft Update-katalogen eller hanteringsverktyg som Windows Server Update Services (WSUS) och Microsoft Endpoint Configuration Manager (MECM). När det gäller sårbarheten CVE-2017-11816 kan motsvarande uppdatering (till exempel KB4042121 för Windows Server 2008) hämtas från antingen Windows Update eller katalogen, som en fristående .msu-fil.
En egenhet som Microsoft betonar är att om språkpaket installeras efter att uppdateringen har tillämpats måste säkerhetsuppdateringen installeras om. Därför rekommenderas det alltid att först distribuera de nödvändiga språken och sedan uppdateringarna. Denna detalj, som kan verka obetydlig, har lett till mer än ett fall där ett system felaktigt tros ha en uppdatering när vissa GDI-binärfiler i verkligheten inte innehöll den korrigerade versionen.
I dokumentationen relaterad till dessa bulletiner tillhandahåller Microsoft omfattande tabeller med filinformation : namn (till exempel gdi32.dll), specifik version, storlek, datum, tid och plattform (x86, x64, IA-64). Dessa tabeller gör det möjligt för administratörer och granskare att forensiskt verifiera om rätt binärfil är installerad. En liknande process används för .msu- och .exe-paketen i olika utgåvor av Windows och Office, där SHA1- och SHA256-hashar för varje fil listas så att team kan verifiera deras integritet.
Listan över filer och hashkoder är överväldigande: från Windows 6.0-KB2834886-x86.msu och dess x64- och ia64-varianter, via Windows 6.1-KB2835364-x64.msu, Windows 8-RT-KB2835361-x86.msu, dussintals installationsprogram för Windows Server 2003 och Windows XP på alla möjliga språk (CHS, CHT, DEU, ESN, FRA, ITA, JPN, KOR, PTB, PTG, RUS, etc.), till patchar för Office- och Lync-komponenter som AttendeeAdmin.msp, ogl2007-kb2687309-fullfile-x86-glb.exe eller lyncloc2013-kb2817465-fullfile-x64-glb.exe. Var och en av dem innehåller sina egna SHA1- och SHA256-hashkoder för att underlätta verifiering.
I alla dessa fall är det slutgiltiga målet detsamma: att uppdatera gdi32.dll-filen (eller de relaterade binärfilerna för grafikundersystemet) till den säkra versionen. På plattformar som Windows Server 2008 listas till exempel gdi32.dll som version 6.0.6002.24200, med storlekar som varierar beroende på arkitekturen (cirka 299 520 byte på x86, 391 680 byte på x64 och 955 392 byte på IA-64). Dessa värden, tillsammans med byggdatumet, är den grundläggande referensen för att avgöra om systemet har patchen installerad.
Den officiella dokumentationen hänvisar också till kunskapsbasartiklar med detaljer om implementering och distribution av dessa uppdateringar, samt länkar till supportresurser: hjälpsidor för Windows Update, säkerhetsportaler för IT-proffs (som TechNet Security), internationella supportwebbplatser och specifika tjänster för att bekämpa skadlig kod under varumärket Microsoft Secure.
God praxis för begränsning, övervakning och åtgärder
Utöver att installera patchar så snart de är tillgängliga finns det ett antal åtgärder för att minska risken och djupgående försvar som hjälper till att minska risken i samband med GDI-fel, särskilt i företagsmiljöer med hundratals eller tusentals datorer.
För det första är det lämpligt att begränsa attackytan genom att inaktivera eller begränsa den automatiska bearbetningen av vissa grafikformat i program och webbläsare. I Microsoft Edge kan du till exempel konfigurera grupprinciper för att blockera eller kontrollera nedladdning och hantering av EMF/WMF-metafiler med hjälp av registernycklar under HKLM\SOFTWARE\Policies\Microsoft\Edge relaterade till nedladdningsbegränsningar. I andra program kan du använda konfigurationsalternativ för att förhindra automatisk förhandsgranskning av dokument från otillförlitliga platser och tillämpa felsökningsguider för att åtgärda problem med Utforskaren.
Ett annat viktigt lager är nätverkssegmentering enligt Zero Trust-principerna . Detta inkluderar att begränsa SMB-, RDP- och annan potentiellt utnyttjad protokolltrafik till endast de absolut nödvändiga subnäten, implementera nästa generations brandväggar med djup paketinspektion och tillämpa identitets- och kontextbaserade regler. Genom att begränsa vilka enheter som kan kommunicera med vilka tjänster minskas effekten av ett utnyttjande som försöker sprida sig i sidled drastiskt.
På detekteringssidan hjälper implementering av Endpoint Detection and Response (EDR)-lösningar, till exempel Microsoft Defender for Endpoint, till att övervaka avvikande beteenden relaterade till win32k.sys, gdi32.dll och BSOD-händelser . Att konfigurera aviseringar för toppar i blåskärmsfel (till exempel, som börjar med händelse-ID 1001 i händelsevisaren) och ovanlig åtkomst till grafikundersystemet kan hjälpa till att identifiera utnyttjandeförsök eller instabiliteter orsakade av skadlig kod.
För patchhantering rekommenderas det starkt att automatisera distributionen med Windows Update för företag, WSUS eller MECM, men att alltid inkludera en testfas i mellanlagringsmiljöer för att upptäcka potentiella regressioner innan driftsättning. I infrastrukturer med begränsad kapacitet är det lämpligt att granska alla inkommande filer med verktyg som YARA-regler som är utformade för att känna igen misstänkta mönster i EMF/WMF och andra grafiska format.
I mer avancerade scenarier överväger vissa organisationer att migrera sina interna applikationer till modernare API:er som Direct2D, DirectWrite eller plattformsoberoende grafikmotorer (Cairo, Skia), vilka erbjuder bättre isolering och mindre beroende av äldre GDI. På medellång sikt kan Microsoft komma att avskriva betydande delar av GDI i framtida versioner av Windows för att minska attackytan, även om kompatibilitet med äldre programvara kommer att förbli en utmaning.
Ur ett forensiskt och reverse engineering-perspektiv möjliggör verktyg som WinDbg, KD och Volatility dissekering av minnesdumpar efter en BSOD (Blue Screen of Death) och observation av korruption i minne märkt "Gdi" i kärnans minnespool. Proof-of-concept-exploits publicerade för forskningsändamål visar hur en EMF (Engine Memory File) med vissa felaktigt utformade register (t.ex. i EMR_HEADER) kan tvinga fram ett kapplöpningsvillkor och utlösa en krasch. Denna kunskap är avgörande för incidenthanteringsteam för att rekonstruera vad som hände i en verklig attack.
Vid en incident rekommenderas att följa handlingsramverk som NIST (Identify, Contain, Eradicate, Recover). Detta innebär att isolera berörda system , bevara bevis (minnesdumpar, loggar, exempel på misstänkta filer), distribuera väntande patchar, skanna system med uppdaterade verktyg mot skadlig kod och återställa från verifierade säkerhetskopior eller återgå till en tidigare punkt . Dessutom är det lämpligt att regelbundet granska lärdomar för att förbättra systempatchnings- och härdningsprocesser.
Hela denna historia av fel och patchar kring Windows GDI belyser hur ömtåliga äldre komponenter kan vara när det inte finns en robust säkerhets- och uppdateringsstrategi i flera lager. Att förstå hur dessa sårbarheter utnyttjas, vilka versioner som är i riskzonen och vilka ytterligare kontroller som kan tillämpas gör det möjligt för administratörer och cybersäkerhetsexperter att stärka sina system och förhindra att en enkel avbildning eller specialskapad metafil kraschar eller helt komprometterar en Windows-infrastruktur.
