Kwetsbaarheden aangetroffen in UEFI-module van Gigabyte-firmware
UEFI-modules die aanwezig zijn in de firmware van Gigabyte blijken kwetsbaar voor zogeheten System Management Mode (SMM) callout-kwetsbaarheden. Kwaadwillenden kunnen de kwetsbaarheden uitbuiten om hun rechten op te hogen en willekeurige code uit te voeren in de SMM-omgeving van een UEFI-ondersteunde CPU.
De kwetsbaarheden zijn ontdekt door het Binarly REsearch-team en gemeld aan het Amerikaanse CERT, die in een security advisory op het lek ingaat. UEFI zorgt voor een interface tussen een besturingssysteem en de firmware van een platform. Het kan daarbij directe interactie hebben met hardware via de SMM, wat een speciale CPU-modus is voor het uitvoeren van systeemoperaties. SMM-operaties worden uitsluitend uitgevoerd in een beschermd deel van het interne geheugen dat de System Management RAM (SMRAM) wordt genoemd. Zij zijn alleen toegankelijk via System Management Interrupt (SMI)-handlers.
Gateway naar SMM
SMI-handlers dienen als een gateway naar SMM. Zij verwerken gegevens die via specifieke communicatiebuffers worden doorgegeven. Het onjuist valideren van deze buffers of onbetrouwbare pointers uit CPU-opslagregisters kan leiden tot ernstige beveiligingsrisico's, waaronder SMRAM-corruptie en ongeautoriseerde SMM-uitvoering. Een aanvaller kan deze SMI-handlers misbruiken voor het uitvoeren van willekeurige code tijdens de opstartfase, herstelmodi of voordat het besturingssysteem volledig is geladen.Meerdere kwetsbaarheden zijn geïdentificeerd in Gigabyte firmware-implementaties:
CVE-2025-7029: Ongecontroleerd gebruik van het RBX-register geeft een aanvaller controle over OcHeader- en OcData-pointers die worden gebruikt in de logica voor stroom- en thermische configuratie. Dit kan leiden tot willekeurige SMRAM-schrijfbewerkingen.(BRLY-2025-011)
CVE-2025-7028: Gebrek aan validatie van functiepointerstructuren afgeleid van RBX en RCX geeft een aanvaller controle over kritieke flash-bewerkingen via FuncBlock. Dit is van invloed op functies zoals ReadFlash, WriteFlash, EraseFlash en GetFlashInfo.(BRLY-2025-010)
CVE-2025-7027: Dit is een kwetsbaarheid voor dubbele pointer-dereferentie. De locatie van het geheugenschrijven is daarbij afkomstig van een niet-gevalideerde NVRAM-variabele SetupXtuBufferAddress NVRAM en de content voor het schrijven van een door de aanvaller gecontroleerde pointer gebaseerd op het RBX-register. De kwetsbaarheid stelt kwaadwillenden in staat willekeurige code naar SMRAM te schrijven.(BRLY-2025-009)
CVE-2025-7026: Een door de aanvaller gecontroleerd RBX-register kan worden gebruikt als een niet-gecontroleerde pointer binnen de CommandRcx0-functie. Dit maakt schrijfbewerkingen mogelijk naar door de aanvaller gespecificeerd geheugen in SMRAM. (BRLY-2025-008)
UEFI en SMM zijn geen speeltuin: als je daar code mag uitvoeren, sta je boven het besturingssysteem, boven hypervisors, boven security agents. Eenmaal binnen kun je rootkits installeren die zelfs survive'n na OS-herinstallaties. De RBX-register als je persoonlijke cheatcode? Dat is next-level pwnage.
De details zijn ook smullen:
CVE-2025-7029 - Ongecontroleerd gebruik van RBX -> volledige controle over pointers in power/thermal config. Want waarom zou je hardwarebeheer niet openstellen voor willekeurige schrijfacties?
CVE-2025-7028 - Flash-bewerkingen zonder validatie. Ja hoor, lees/schrijf/erase flash alsof je admin van het universum bent.
CVE-2025-7027 - Dubbele pointer-dereferentie. Als je dacht dat C pointerbugs passé waren, welkom terug in 1999.
CVE-2025-7026 - CommandRcx0: waar je RBX gebruikt om gewoon geheugen te overschrijven in SMRAM.
Het engste? Dit gebeurt voor je OS opstaat. EDR? Kan niks doen. Secure Boot? Wordt omzeild. Dit is firmware hell, en de enige remedie is patchen - als de vendor dat ooit goed regelt.
Vraag is wel: hoeveel systemen draaien nog met deze kwetsbare implementaties, en hoe lang duurt het voordat iemand een PoC op GitHub zet? Mijn gok: niet lang.
Gigabyte-gebruikers: veel plezier met BIOS-updates. En doe het snel, want een persistent SMM-rootkit is niet iets dat je met een herstart oplost.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?