Onlangs is er informatie naar buiten gekomen over een kwetsbaarheid die cloudservers in gevaar brengt. Deze kwetsbaarheid stelt aanvallers in staat om de volledige controle over de fysieke machine over te nemen , een nachtmerriescenario voor aanbieders van cloudinfrastructuur.
Zapscape, geregistreerd onder de identificatiecode CVE-2026-64561, is een kritieke kwetsbaarheid in de Linux KVM-hypervisor die een risico blootlegt dat veel platforms onbedoeld nemen door geneste virtualisatie in te schakelen. Deze kwetsbaarheid stelt een aanvaller met kernelrechten in een virtuele machine (L1) in staat om code met rootrechten uit te voeren op het hostsysteem (L0), waardoor de isolatie van gevirtualiseerde omgevingen wordt doorbroken.
Zapscape wordt beschouwd als een ernstige bedreiging, omdat het niet alleen ontsnapping uit de virtuele machine mogelijk maakt, maar ook een lokale route voor privilege-escalatie opent voor hostgebruikers die schrijfrechten hebben op het apparaat /dev/kvm.
Hoewel organisaties zoals Red Hat de kwetsbaarheid een CVSS-score van 7.0 hebben toegekend, waarbij de focus ligt op instabiliteit en denial-of-service-aanvallen, toont het publieke proof-of-concept (PoC) een veel destructievere omvang aan: het aanmaken van een willekeurig bestand direct in de rootmap van de host.
Chaos in de geheugenbeheereenheid
De werking van Zapscape is verborgen in de Memory Management Unit (MMU) van KVM en hoe de hypervisor paginatabellen afhandelt wanneer een gast-VM (L1) fungeert als hypervisor voor een andere sub-gast-VM (L2). Het probleem zit hem in een logische volgordefout tijdens de afhandeling van paginafouten. In de kernelcode werd de controle op een "verouderde root" uitgevoerd vóór de functie voor het ophalen van pagina's, in plaats van erna.
Deze onjuiste volgorde veroorzaakt een klassiek use-after-free-scenario . Tijdens het herstelproces kan KVM de root die het gebruikt verwijderen en als ongeldig markeren. Omdat de health check echter al is uitgevoerd, blijft het systeem mappings bouwen onder een root die niet langer geldig is. Opmerkelijk is dat dit sorteerprobleem al sinds 2008 in de code aanwezig is, maar het werd kritiek en exploiteerbaar na de release van Linux-kernel 5.9 in juli 2020 , toen een richtlijn werd geïntroduceerd die het systeem simpelweg niet meer afdwingt.
Vereisten en beperkingen
Om Zapscape te kunnen exploiteren, moet de omgeving aan zeer specifieke vereisten voldoen. Ten eerste moet geneste virtualisatie zijn ingeschakeld in de KVM-module, een configuratie die een drielaagse architectuur mogelijk maakt (L0, L1 en L2). De aanvaller moet de aanval starten vanuit de L1-laag , waarvoor rootrechten op die virtuele machine vereist zijn. Van daaruit manipuleert de aanvaller geheugenmodi, terwijl de activiteit van de L2-sub-gast de L0-host dwingt om quota-pagina-opvraging te starten, wat leidt tot geheugenbeschadiging.
Op hardwareniveau variëren de voorwaarden afhankelijk van de fabrikant. Op AMD-systemen die geneste paginatabellen ( SVM ) gebruiken , is de kwetsbaarheid eenvoudiger en vereist geen extra functionaliteit. Op Intel-processoren daarentegen vereist het scenario dat de L1-gast beschikt over mogelijkheden voor het doorlopen van paginatabellen op vier of vijf niveaus (EPT pagewalk) . Dit beperkt de aanvalsvector op Intel tot recentere architecturen, met name vanaf de Ice Lake-SP-familie.
Het is belangrijk op te merken dat, hoewel het publieke proof-of-concept erin is geslaagd om in gecontroleerde omgevingen naar de host te ontsnappen, beveiligingsonderzoekers hebben gemeld dat de exploit bij bepaalde opnieuw gecompileerde kernels de virtuele machine van de aanvaller simpelweg laat crashen, wat resulteert in een denial-of-service-aanval in plaats van een volledige ontsnapping.
Beperkende maatregelen, patches en strategieën
De definitieve oplossing voor Zapscape is afgelopen juli in de Linux-repositories verschenen met een patch die de validatievolgorde corrigeert. Deze correctie verplaatst de controle op een verouderde root naar na de toewijzing van MMU-pagina's, waardoor wordt gegarandeerd dat de hypervisor geen actieve mappings aanmaakt onder een verwijderde root. Deze correcties zijn al geïmplementeerd in de stabiele kernelbranches en worden breed verspreid door verschillende distributies.
Voor beheerders die niet direct kunnen upgraden, bestaan ​​er zeer effectieve tijdelijke oplossingen. De prioriteit is om geneste virtualisatie uit te schakelen op alle servers waar dit niet strikt noodzakelijk is, door de parameter `nested=0` door te geven aan de modules `kvm_amd` of `kvm_intel` in de modprobe-configuratiebestanden. Deze maatregel vereist het herladen van de module, wat betekent dat alle actieve virtuele machines moeten worden gestopt.
Als u tot slot meer wilt weten, kunt u de details vinden via de volgende link.