- Windows GDI akkumulerer sårbarheter i informasjonsavsløring, tjenestenekt og ekstern kjøring av kode som påvirker flere versjoner av Windows og Windows Server.
- Mange av disse sårbarhetene utnyttes gjennom EMF/WMF-filer eller misdannet grafikkinnhold behandlet av gdi32.dll og win32k.sys, som kan forårsake BSOD-er eller minnelekkasjer.
- Microsoft gir ut oppdateringer i kumulative pakker med endringer i binærfiler som gdi32.dll, og tilbyr hash-er og filinformasjon for å bekrefte en vellykket installasjon.
- Kombinasjonen av smidig patching, nettverkssegmentering, begrensning av farlige grafikkformater og overvåking med EDR er nøkkelen til å redusere risikoen forbundet med GDI.
Windows grafiske brukergrensesnitt (GDI) har gjengitt vinduer, tekst, ikoner og bilder i flere tiår uten at de fleste brukere engang har innsett det. Denne grunnleggende systemkomponenten har imidlertid også vært kilden til flere betydelige sikkerhetsproblemer, noen nulldagsangrep og andre som er oppdatert i massive Microsoft-oppdateringer. Når GDI feiler, er det ikke bare et program som krasjer: i noen tilfeller kan det føre til datalekkasjer, ekstern kodekjøring eller blåskjermer (BSOD-er) som får hele servere til å falle.
Følgende linjer beskriver hvordan GDI fungerer, hvilke spesifikke sårbarheter som har blitt dokumentert de siste årene (som CVE-2017-11816, CVE-2020-1435 eller CVE-2023-36884 ), hvordan de utnyttes , hvilken reell innvirkning de har på hjemme- og bedriftsmiljøer, og hvilke praktiske tiltak administratorer og cybersikkerhetseksperter kan bruke for å beskytte Windows-systemene sine, fra eldre versjoner som Windows Vista SP2 til moderne utgaver av Windows 11 og Windows Server.
Hva er Windows GDI, og hvorfor er det så sensitivt når det gjelder sikkerhet?
Graphics Device Interface (GDI) er det eldre Windows API-et som er ansvarlig for å administrere alt relatert til grafikkgjengivelse: fra å tegne linjer og rektangler til å vise fonter, punktgrafikk og bilder på skjermen eller i skrivere. Programmer kaller funksjoner fra biblioteker som gdi32.dll for å opprette enhetskontekster (HDC-er), pensler, penner, regioner og andre grafiske objekter, som administreres under panseret av kjernekontrollerte datastrukturer.
GDI-arkitekturen er delt mellom brukermodus og kjernemodus . I brukermodus mottar gdi32.dll DLL og andre relaterte biblioteker tegneforespørsler fra applikasjoner. Disse kallene sendes til Windows-vindusundersystemet, som kjører i kjernemodus via win32k.sys. Denne kjernedelen er det som faktisk manipulerer systemminne, validerer grafiske objekter og sender dem til maskinvaren. Enhver utilstrekkelig validering av pekere, størrelser eller indekser på dette tidspunktet åpner døren for katastrofale feil.
For å spore og gjenbruke ressurser vedlikeholder systemet GDI-objekttabeller . Hver prosess har sin egen tabell, men det finnes også en global tabell for delte objekter, noe som øker potensialet for korrupsjon hvis det oppstår bufferoverløp, double-free-hendelse eller en ugyldig minnereferanse. Disse typene feil kan føre til korrupsjon av kjerneminne, kappløpsforhold, systemkrasj eller til og med vilkårlig kodekjøring i systemets mest privilegerte kontekst.
Med ankomsten av mer moderne API-er (GDI+, Direct2D, DirectWrite og til og med DirectComposition) har Microsoft redusert bruken av GDI i nye applikasjoner, men det eldre programvareøkosystemet som fortsatt er avhengig av det er enormt. Denne arven gjør GDI til en svært attraktiv angrepsflate for forskere og angripere.
Historiske sårbarheter: fra informasjonsavsløring til dag null
Blant de eldste sårbarhetene knyttet til GDI er et dokumentert sikkerhetsproblem for informasjonsavsløring, CVE-2017-11816 . I dette tilfellet lå problemet i hvordan GDI håndterte visse objekter i minnet, slik at en ondsinnet bruker kunne hente data fra målsystemet som ikke burde være tilgjengelige. Det var ikke kodeutførelse, men snarere et alvorlig brudd på konfidensialitet.
Denne sårbarheten rammet diverse utgaver av Windows og tvang Microsoft til å gi ut en spesifikk sikkerhetsoppdatering. Feilen lå i den interne håndteringen av grafikkstrukturer, der delsystemet ikke klarte å tømme eller validere visse minneområder på riktig måte før de ble brukt på nytt, noe som gjorde det mulig å lese gjenværende informasjon som tilhører andre prosesser eller selve operativsystemet.
Rettelsen kom i en sikkerhetsoppdatering som var inkludert i den vanlige «Patch Tuesday»-syklusen i oktober 2017. Sammen med beskrivelsen av sårbarheten ga Microsoft omfattende tabeller som listet opp de berørte filene og deres nyere versjoner: for eksempel forskjellige versjoner av gdi32.dll for x86-, x64- og IA-64-plattformer, med datoer som 8. september 2017, og filversjoner som 6.0.6002.24200. Denne detaljen tillot administratorer å bekrefte at oppdateringen var installert riktig.
Senere avdekket forskere fra Project Zero (Google) en annen nulldagssårbarhet relatert til gdi32.dll i brukermodus . Denne gangen påvirket feilen håndteringen av DIB-er (Device Independent Bitmaps) innebygd i EMF-registre (Enhanced Metafile). Feil manipulering av disse bitmapene i metafilene tillot utvinning av informasjon fra prosessminne, med direkte innvirkning på databeskyttelse.
Denne nulldagssårbarheten kunne reproduseres lokalt via Internet Explorer og eksternt via Office Online ved å åpne et DOCX-dokument med en spesiallaget EMF. Listen over berørte versjoner var omfattende, alt fra Windows Vista Service Pack 2 til Windows 10 , og inkludert Windows Server-versjoner som 2012 R2 og 2016. Problemet ble offentlig etter at standard 90-dagers Project Zero-perioden utløp uten at en oppdatering ble utgitt, noe som offisielt gjorde sårbarheten til en praktisk nulldagsutnyttelse.
I mellomtiden opplevde Microsoft en bemerkelsesverdig hendelse: et internt problem forhindret dem i å gi ut den planlagte Patch Tuesday -oppdateringspakken i en måned, noe som utsatte rettelsene til neste syklus. Denne typen forsinkelser øker eksponeringstiden for sårbarheter som allerede er kjent i forskningsmiljøet.
Nylige kritiske feil: BSOD, fjernkjøring og store patch-batcher
Over tid har sårbarheter i GDI utviklet seg til mer alvorlige scenarier. Et spesielt slående eksempel er en denial-of-service-sårbarhet identifisert som CVE-2023-36884 , som påvirker versjoner av Windows 10 (starter med 1607), Windows 11 og Windows Server 2016, 2019 og 2022. Selv om identifikatoren har blitt knyttet til forskjellige komponenter avhengig av bulletinen, beskriver den tekniske analysen en kritisk feil i grafikksystemet som kan forårsake blåskjermer (BSOD-er) ved behandling av misdannede grafiske objekter.
Problemet er knyttet til NtGdiDdDeleteDeviceBitmap-funksjonen i win32k.sys . Når en ugyldig grafikkbitmap eller enhet håndteres, klarer ikke den sårbare koden å utføre en grundig buffergrensekontroll når data kopieres fra en enhetsstruktur (f.eks. av typen DD_DEVICE_OEM). Denne utelatelsen gjør at tilstøtende minne kan overskrives i kjernen, noe som genererer et minnetilgangsunntak (PAGE_FAULT_IN_NONPAGED_AREA, kode 0x00000050) og utløser en blåskjerm (BSOD) med koder som IRQL_NOT_LESS_OR_EQUAL eller lignende.
Den typiske utnyttelsesflyten starter med grafikkdata innebygd i nettverksprotokoller som SMB eller RDP, eller til og med via WebDAV eller utskriftstjenester. En misdannet EMF-fil sendes som en del av et eksternt dokument eller en strøm, og når et program som Office, Edge, en bildeviser eller til og med Filutforsker selv prøver å tolke innholdet, kalles GDI-undersystemet for å behandle det. Parseringsrutinen klarer ikke å validere visse objektregistre på riktig måte, noe som gjør at en peker utenfor rekkevidde kan derefereres og destabiliserer kjerneminnet (spesielt Non-Paged Pool).
Selv om virkningen rapportert i offisielle bulletiner fokuserer på tjenestenekt (DoS) , har diverse forskere påpekt at det med mer avanserte teknikker for å utnytte minnekorrupsjon (for eksempel ved å angripe heapen), kan være mulig å bygge kjeder som fører til kodekjøring i kjernemodus, likt det som har blitt sett med sårbarheter i andre komponenter som MSHTML (tilfellet med CVE-2021-40444).
Kritiskheten til GDI har også blitt reflektert i store bølger av oppdateringer. I juli 2020 ga Microsoft ut en massiv oppdatering som fikset 123 sårbarheter i produktene sine, hvorav 18 ble klassifisert som kritiske. Blant sistnevnte var CVE-2020-1435, direkte relatert til hvordan GDI manipulerer objekter i minnet. Hvis en angriper klarte å lure et offer til å åpne spesiallaget innhold (for eksempel ved å besøke et ondsinnet nettsted), kunne det utløse ekstern kjøring av kode med de samme rettighetene som brukeren.
I samme batch dukket det opp CVE-2020-1436, knyttet til håndtering av spesiallagde fonter, og den spesielt profilerte CVE-2020-1350 , en kritisk sårbarhet i Windows DNS-serveren med ormlignende egenskaper, som kan spre skadelig programvare uten brukerinteraksjon. Selv om sistnevnte ikke påvirker GDI, illustrerer den konteksten: en enkelt oppdateringspakke inneholdt sårbarheter i nettverkstjenester, hypervisorer (flere feil i ekstern kjøring i Hyper-V) og selve det grafiske grensesnittet.
CVE-2020-1435 relaterer seg spesifikt til hvordan GDI håndterer grafikkobjekter i minnet . En vellykket utnyttelse vil tillate en angriper å installere programmer, vise, endre eller slette data og opprette brukerkontoer med fulle rettigheter. Den typiske angrepsvektoren innebærer å lure brukeren til å besøke et ondsinnet nettsted eller åpne en fil som inneholder grafikkressurser som er designet for å utnytte sårbarheten. Dette stemmer overens med GDIs historiske mønster: alt visuelt innhold som er avhengig av gjengivelsesmotoren, kan være et sårbarhet hvis systemet ikke er oppdatert.
I den samme oppdateringssyklusen fra juli 2020 ble det også annonsert flere kritiske sårbarheter i Hyper-V (CVE-2020-1041, -1040, -1032, -1036, -1042 og -1043) , som demonstrerer hvordan ulike Windows-komponenter (nettverk, virtualisering, grafikk) kan bli ledd i samme angrepskjede hvis organisasjonen ikke opprettholder et strengt program for oppdateringsadministrasjon.
Faktisk innvirkning på Windows-systemer, berørte versjoner og vektorer
Utvalget av versjoner som er berørt av GDI-sårbarheter er bredt. I nulldagstilfellene som er dokumentert av Project Zero, påvirket sårbarheten i gdi32.dll Windows Vista SP2, Windows 7, Windows 8.1, Windows 10 og flere utgaver av Windows Server (2012 R2, 2016 osv.). Dette betyr at et stort antall datamaskiner, både hjemme- og bedriftsdatamaskiner, kan bli offer for minnelekkasjer bare ved å åpne et dokument, surfe med Internet Explorer eller bruke Office Online.
I det nyeste BSOD-fokuserte scenariet bekreftet Microsoft at den analyserte sårbarheten påvirker Windows 10 fra versjon 1607 og utover, Windows 11 og Windows Server 2016/2019/2022 , inkludert Enterprise-, Education- og LTSC-utgavene. Versjoner som ikke lenger har utvidet støtte, for eksempel Windows 7 eller 8.1, dekkes ikke av den offisielle oppdateringen, men det betyr ikke at de er fri for GDI-problemer; det betyr ganske enkelt at de ikke mottar regelmessige rettelser.
På et operasjonelt nivå kan virkningen oppsummeres i tre kategorier: informasjonsavsløring (lesing av minne som skal være privat), tjenestenekt (gjentakende BSOD-er) og ekstern kodekjøring . I bedriftsmiljøer kan en BSOD på en server med kritiske roller (for eksempel en delt utskriftsserver eller en Hyper-V-vert) utløse en kjedereaksjon av feil: avbrudd i utskriftstjenester, uventet nedstengning av virtuelle maskiner, datatap i eksterne økter og lange gjenopprettingstider.
Fra et nettverksperspektiv kan GDI utnyttes gjennom protokoller som SMB (port 445), RDP eller WebDAV hvis en tjeneste automatisk behandler mottatte EMF/WMF-bilder eller metafiler. Lokalt krever det bare at en bruker åpner en skadelig fil i programmer som bruker GDI, for eksempel Paint, WordPad, eldre bildevisere eller til og med prosesser involvert i forhåndsvisning av ikoner og miniatyrbilder i Filutforsker . De vanligste angrepskjedene kombinerer en phishing-e-post med et DOCX- eller PDF-dokument som inneholder en misdannet EMF-fil.
I regulerte organisasjoner (finans, helsevesen, offentlig forvaltning) kan hendelser forårsaket av uoppdaterte sårbarheter ha juridiske og regulatoriske konsekvenser. En blåskjerm (BSOD) som krasjer et kritisk system kan betraktes som en sikkerhetshendelse som kompromitterer tjenestekontinuiteten, noe som igjen kan utløse revisjoner og straffer knyttet til rammeverk som GDPR eller HIPAA. Videre har ulike trusselinformasjonsrapporter tilskrevet utnyttelse av feil i grafikkundersystemer til APT-grupper som retter seg mot verdifulle mål i Asia og Europa.
Det er verdt å huske at, ifølge vanlige bransjedata (for eksempel de som gjenspeiles i årlige rapporter om datainnbrudd), forblir en betydelig andel av Windows-enheter uoppdatert i mer enn 90 dager etter utgivelsen av kritiske oppdateringer. Dette gir et bredt vindu for angripere til å automatisere utnyttelser og integrere dem i rammeverk som Metasploit eller Cobalt Strike, som er i stand til å skanne hele nettverksområder for sårbare verter.
Hvordan Microsoft distribuerer rettelser og hvilke filer som blir endret
Når et sikkerhetsproblem oppdages i GDI, utgir Microsoft en sikkerhetsoppdatering, vanligvis samlet i månedlige samleoppdateringer. Disse oppdateringene leveres vanligvis via Windows Update , Microsoft Update-katalogen eller administrasjonsverktøy som Windows Server Update Services (WSUS) og Microsoft Endpoint Configuration Manager (MECM). Når det gjelder sikkerhetsproblemet CVE-2017-11816, kan den tilsvarende oppdateringen (for eksempel KB4042121 for Windows Server 2008) hentes fra enten Windows Update eller katalogen, som en frittstående .msu-fil.
En særegenhet som Microsoft understreker er at hvis språkpakker installeres etter at oppdateringen er installert , må sikkerhetsoppdateringen installeres på nytt. Derfor anbefales det alltid å distribuere de nødvendige språkene først og deretter oppdateringene. Denne detaljen, som kan virke ubetydelig, har ført til mer enn ett tilfelle der et system feilaktig ble antatt å være oppdatert, når visse GDI-binærfiler i virkeligheten ikke inneholdt den korrigerte versjonen.
I dokumentasjonen knyttet til disse bulletinene tilbyr Microsoft omfattende tabeller med filinformasjon : navn (for eksempel gdi32.dll), spesifikk versjon, størrelse, dato, klokkeslett og plattform (x86, x64, IA-64). Disse tabellene lar administratorer og revisorer bekrefte rettsmedisinsk om riktig binærfil er installert. En lignende prosess brukes for .msu- og .exe-pakkene i forskjellige utgaver av Windows og Office, der SHA1- og SHA256-hasher for hver fil er listet opp slik at team kan bekrefte integriteten deres.
Listen over filer og hasher er overveldende: fra Windows 6.0-KB2834886-x86.msu og dens x64- og ia64-varianter, via Windows 6.1-KB2835364-x64.msu, Windows 8-RT-KB2835361-x86.msu, dusinvis av installasjonsprogrammer for Windows Server 2003 og Windows XP på alle slags språk (CHS, CHT, DEU, ESN, FRA, ITA, JPN, KOR, PTB, PTG, RUS, osv.), til oppdateringer for Office- og Lync-komponenter som AttendeeAdmin.msp, ogl2007-kb2687309-fullfile-x86-glb.exe eller lyncloc2013-kb2817465-fullfile-x64-glb.exe. Hver av dem har sine egne SHA1- og SHA256-hasher for å forenkle verifisering.
I alle disse tilfellene er det endelige målet det samme: å oppdatere gdi32.dll-filen (eller de relaterte binærfilene for grafikkundersystemet) til den sikre versjonen. På plattformer som Windows Server 2008 er for eksempel gdi32.dll oppført som versjon 6.0.6002.24200, med størrelser som varierer avhengig av arkitekturen (rundt 299 520 byte på x86, 391 680 byte på x64 og 955 392 byte på IA-64). Disse verdiene, sammen med byggedatoen, er den grunnleggende referansen for å avgjøre om systemet har oppdateringen installert.
Den offisielle dokumentasjonen viser også til kunnskapsbaseartikler med detaljer om implementering og distribusjon av disse oppdateringene, samt lenker til støtteressurser: hjelpesider for Windows Update, sikkerhetsportaler for IT-fagfolk (som TechNet Security), internasjonale støttesider og spesifikke tjenester for bekjempelse av skadelig programvare under Microsoft Secure-merket.
God praksis for avbøtende tiltak, overvåking og respons
Utover å installere oppdateringer så snart de er tilgjengelige, finnes det en rekke tiltak for å redusere risikoen forbundet med GDI-feil, spesielt i bedriftsmiljøer med hundrevis eller tusenvis av datamaskiner.
For det første anbefales det å begrense angrepsflaten ved å deaktivere eller begrense automatisk behandling av visse grafikkformater i applikasjoner og nettlesere. I Microsoft Edge kan du for eksempel konfigurere gruppepolicyer for å blokkere eller kontrollere nedlasting og håndtering av EMF/WMF-metafiler ved hjelp av registernøkler under HKLM\SOFTWARE\Policies\Microsoft\Edge relatert til nedlastingsbegrensninger. I andre applikasjoner kan du bruke konfigurasjonsalternativer for å forhindre automatisk forhåndsvisning av dokumenter fra uklarerte steder og bruke feilsøkingsveiledninger for å løse problemer med at Filutforsker ikke reagerer.
Et annet viktig lag er nettverkssegmentering i henhold til nulltillitsprinsipper . Dette inkluderer å begrense SMB-, RDP- og annen potensielt utnyttbar protokolltrafikk til kun de strengt nødvendige delnettene, implementere neste generasjons brannmurer med dyp pakkeinspeksjon og håndheve identitets- og kontekstbaserte regler. Ved å begrense hvilke enheter som kan kommunisere med hvilke tjenester, reduseres virkningen av et utnyttelsesforsøk som forsøker å spre seg lateralt drastisk.
På deteksjonssiden bidrar implementering av Endpoint Detection and Response (EDR)-løsninger, som Microsoft Defender for Endpoint, til å overvåke unormal oppførsel relatert til win32k.sys-, gdi32.dll- og BSOD-hendelser . Konfigurering av varsler for topper i blåskjermfeil (for eksempel startende med hendelses-ID 1001 i hendelsesvisningen) og uvanlig tilgang til grafikksystemet kan bidra til å identifisere utnyttelsesforsøk eller ustabiliteter forårsaket av skadelig programvare.
For oppdateringsadministrasjon anbefales det på det sterkeste å automatisere distribusjonen ved hjelp av Windows Update for Business, WSUS eller MECM, men alltid inkludere en testfase i oppsettsmiljøer for å oppdage potensielle regresjoner før lansering. I infrastrukturer med begrenset kapasitet anbefales det å revidere alle innkommende filer med verktøy som YARA-regler som er utviklet for å gjenkjenne mistenkelige mønstre i EMF/WMF og andre grafiske formater.
I mer avanserte scenarier vurderer noen organisasjoner å migrere sine interne applikasjoner til mer moderne API-er som Direct2D, DirectWrite eller grafikkmotorer på tvers av plattformer (Cairo, Skia), som tilbyr bedre isolasjon og mindre avhengighet av eldre GDI. På mellomlang sikt kan Microsoft avskrive betydelige deler av GDI i fremtidige versjoner av Windows for å redusere angrepsflaten, selv om kompatibilitet med eldre programvare fortsatt vil være en utfordring.
Fra et rettsmedisinsk og reverse engineering-perspektiv tillater verktøy som WinDbg, KD og Volatility disseksjon av minnedumper etter en BSOD (Blue Screen of Death) og observasjon av korrupsjon i minne merket "Gdi" i kjerneminnepoolen. Proof-of-concept-utnyttelser publisert for forskningsformål demonstrerer hvordan en EMF (Engine Memory File) med visse misdannede registre (f.eks. i EMR_HEADER) kan tvinge frem en kappløpstilstand og utløse et krasj. Denne kunnskapen er avgjørende for hendelsesresponsteam for å rekonstruere hva som skjedde i et angrep i den virkelige verden.
Ved en hendelse anbefales det å følge handlingsrammeverk som NIST (Identify, Contain, Eradicate, Recover). Dette innebærer å isolere berørte systemer , bevare bevis (minnedumper, logger, prøver av mistenkelige filer), distribuere ventende oppdateringer, skanne systemer med oppdaterte verktøy mot skadelig programvare og gjenopprette fra verifiserte sikkerhetskopier eller gå tilbake til et tidligere punkt . Videre er det tilrådelig å jevnlig gjennomgå lærdommer for å forbedre systemoppdaterings- og herdingsprosesser.
Hele denne historien med feil og oppdateringer rundt Windows GDI fremhever hvor skjøre eldre komponenter kan være når det ikke finnes en robust lagdelt sikkerhets- og oppdateringsstrategi. Å forstå hvordan disse sårbarhetene utnyttes, hvilke versjoner som er i faresonen og hvilke tilleggskontroller som kan brukes, lar administratorer og cybersikkerhetseksperter styrke systemene sine og forhindre at et enkelt bilde eller en spesiallaget metafil krasjer eller fullstendig kompromitterer en Windows-infrastruktur.
