Det ble nylig offentliggjort informasjon om en sårbarhet som setter skyservere i fare. Denne sårbarheten lar angripere ta full kontroll over den fysiske maskinen , et marerittscenario for leverandører av skyinfrastruktur.
Zapscape, registrert under identifikatoren CVE-2026-64561, er en kritisk sårbarhet i Linux KVM-hypervisoren som eksponerer en risiko som mange plattformer utilsiktet påtar seg ved å aktivere nestet virtualisering. Denne sårbarheten lar en angriper med kjerneprivilegier i en virtuell maskin (L1) kjøre kode med rotprivilegier på vertssystemet (L0), og dermed bryte isolasjonen av virtualiserte miljøer.
Zapscape regnes som en trussel med stor innvirkning, og tilrettelegger ikke bare for escape fra den virtuelle maskinen, men åpner også en lokal rute for privilegier for vertsbrukere som har skrivetillatelser på /dev/kvm-enheten.
Selv om organisasjoner som Red Hat har vurdert sårbarheten med en CVSS-score på 7.0 med fokus på ustabilitet og tjenestenekt, viser det offentlige konseptbeviset (PoC) et mye mer destruktivt omfang: opprettelsen av en vilkårlig fil direkte i roten av verten.
Kaos i minnehåndteringsenheten
Måten Zapscape opererer på er skjult i KVMs Memory Management Unit (MMU) og hvordan hypervisoren håndterer sidetabeller når én gjest (L1) fungerer som hypervisor for en annen undergjest (L2). Problemet ligger i en logisk rekkefølgefeil under håndtering av sidefeil. I kjernekodebanene ble sjekken for en "foreldet rot" utført før sidehentingsfunksjonen, i stedet for etter.
Denne feilaktige sekvensen utløser et klassisk bruk-etter-frigjøring-scenario . Under gjenoppretting kan KVM fjerne roten den bruker og markere den som ugyldig. Men fordi helsesjekken allerede har kjørt, fortsetter systemet å bygge mappinger under en rot som ikke lenger er gyldig. Interessant nok har dette sorteringsproblemet eksistert i koden siden 2008, men det ble kritisk og utnyttbart etter utgivelsen av Linux-kjernen 5.9 i juli 2020 , da et direktiv ble introdusert som systemet rett og slett sluttet å håndheve.
Krav og begrensninger
For at Zapscape skal kunne utnyttes, må miljøet oppfylle svært spesifikke krav. Først må nestet virtualisering aktiveres i KVM-modulen, en konfigurasjon som tillater en trelagsarkitektur (L0, L1 og L2). Angriperen må starte angrepet fra L1-laget , som krever rotrettigheter på den virtuelle maskinen. Derfra manipulerer angriperen minnemoduser mens aktiviteten til L2-undergjesten tvinger L0-verten til å starte henting av kvotesider, noe som forårsaker minnekorrupsjon.
På maskinvarenivå varierer forholdene avhengig av produsenten. På AMD-systemer som bruker nestede sidetabeller ( SVM ), er sårbarheten enklere og krever ingen tilleggsfunksjoner. På Intel-prosessorer krever scenariet derimot at L1-gjesten har eksponert fire- og femnivås EPT-sidevandringsmuligheter . Dette begrenser angrepsvektoren på Intel til nyere arkitekturer, spesielt fra Ice Lake-SP-familien og utover.
Det er verdt å merke seg at selv om det offentlige konseptbeviset har klart å rømme til verten i kontrollerte miljøer, har sikkerhetsforskere rapportert at på visse rekompilerte kjerner krasjer utnyttelsen ganske enkelt angriperens virtuelle maskin, og fungerer som en tjenestenekt snarere enn en fullstendig escape.
Tiltak, oppdateringer og strategier
Den definitive løsningen for Zapscape kom til Linux-repositoriene i juli i fjor med en oppdatering som korrigerer valideringsrekkefølgen. Denne oppdateringen flytter den foreldede rotkontrollen til å skje etter MMU-sideallokeringen, noe som sikrer at hypervisoren ikke oppretter aktive mappinger under en slettet rot. Disse oppdateringene er allerede implementert i de stabile kjernegrenene og distribueres bredt av forskjellige distribusjoner.
For administratorer som ikke kan oppgradere umiddelbart, finnes det svært effektive midlertidige tiltak. Prioriterte tiltak er å deaktivere nestet virtualisering på alle servere der det ikke er strengt nødvendig, ved å sende parameteren `nested=0` til modulene `kvm_amd` eller `kvm_intel` i modprobe-konfigurasjonsfilene. Dette tiltaket krever at modulen lastes inn på nytt, noe som betyr at alle aktive virtuelle maskiner stoppes.
Til slutt, hvis du er interessert i å lære mer, kan du finne detaljene på følgende lenke.