Nemrégiben információk láttak napvilágot egy olyan sebezhetőségről , amely veszélyezteti a felhőszervereket. Ez a sebezhetőség lehetővé teszi a támadók számára, hogy teljes mértékben átvegyék az irányítást a fizikai gép felett , ami rémálomszerű forgatókönyv a felhőinfrastruktúra-szolgáltatók számára.
A CVE-2026-64561 azonosítón regisztrált Zapscape egy kritikus sebezhetőség a Linux KVM hipervizorban, amely olyan kockázatot rejt magában, amelyet sok platform akaratlanul is vállal a beágyazott virtualizáció engedélyezésével. Ez a sebezhetőség lehetővé teszi a támadó számára, hogy kernel jogosultságokkal rendelkező támadó egy virtuális gépen (L1) root jogosultságokkal futtasson kódot a gazdagépen (L0), megtörve a virtualizált környezetek izolációját.
A nagy hatású fenyegetésnek tekintett Zapscape nemcsak a virtuális gépből való kilépést teszi lehetővé, hanem egy helyi jogosultság-eszkalációs útvonalat is megnyit a hosztfelhasználók számára, akik írási jogosultsággal rendelkeznek a /dev/kvm eszközön.
Bár olyan szervezetek, mint a Red Hat, 7.0-es CVSS pontszámmal értékelték a sebezhetőséget, az instabilitásra és a szolgáltatásmegtagadásra összpontosítva, a nyilvános koncepcióbizonyítás (PoC) sokkal rombolóbb hatókört mutat: egy tetszőleges fájl létrehozását közvetlenül a gazdagép gyökerében.
Káosz a memóriakezelő egységben
A Zapscape működési módja a KVM memóriakezelő egységében (MMU) és abban rejlik, hogy a hipervizor hogyan kezeli az oldaltáblákat, amikor az egyik vendég (L1) hipervizorként működik egy másik alvendég (L2) számára. A probléma egy logikai rendezési hibában rejlik az oldalhibák kezelése során. A kernel kódútvonalakban az „elavult gyökér” ellenőrzése az oldallekérési függvény előtt, nem pedig utána történt.
Ez a helytelen sorrend egy klasszikus „felszabadítás utáni használat” forgatókönyvet indít el . A helyreállítás során a KVM eltávolíthatja a használt gyökeret, és érvénytelenként jelölheti meg. Mivel azonban az állapotellenőrzés már lefutott, a rendszer továbbra is egy olyan gyökér alatt épít leképezéseket, amely már nem érvényes. Érdekes módon ez a rendezési probléma 2008 óta létezik a kódban, de kritikussá és kihasználhatóvá vált a Linux kernel 5.9-es verziójának 2020 júliusi megjelenése után , amikor bevezettek egy direktívát, amelynek a végrehajtását a rendszer egyszerűen leállította.
Követelmények és korlátozások
Ahhoz, hogy a Zapscape kihasználható legyen, a környezetnek nagyon specifikus követelményeknek kell megfelelnie. Először is, a beágyazott virtualizációt engedélyezni kell a KVM modulban, ez a konfiguráció háromszintű architektúrát (L0, L1 és L2) tesz lehetővé. A támadónak az L1 rétegről kell kezdeményeznie a támadást , amelyhez root jogosultságok szükségesek az adott virtuális gépen. Innen a támadó manipulálja a memória módokat, miközben az L2 alvendég tevékenysége arra kényszeríti az L0 gazdagépet, hogy kvótaoldal-lekérést kezdeményezzen, ami memória-sérülést okoz.
Hardver szinten a feltételek gyártónként eltérőek. Az beágyazott lapozási táblázatokat ( SVM ) használó AMD rendszereken a sebezhetőség egyértelműbb, és nem igényel további funkciókat. Ezzel szemben az Intel processzorokon a forgatókönyv megköveteli , hogy az L1 vendég négy- és ötszintű EPT lapozási képességekkel rendelkezzen . Ez a támadási vektort az Intel ellen az újabb architektúrákra korlátozza, konkrétan az Ice Lake-SP családtól kezdődően.
Érdemes megjegyezni, hogy bár a nyilvános koncepcióbizonyításnak sikerült eljutnia a gazdagépre ellenőrzött környezetben, biztonsági kutatók arról számoltak be, hogy bizonyos újrafordított kernelek esetén a sérülékenység egyszerűen összeomlasztja a támadó virtuális gépét, szolgáltatásmegtagadásként, nem pedig teljes kiútként működve.
Mérséklés, javítások és stratégiák
A Zapscape végleges megoldása tavaly júliusban érkezett a Linux repository-kba egy olyan javítással, amely kijavítja az érvényesítési sorrendet. Ez a javítás az elavult gyökérellenőrzést az MMU oldal kiosztása utánra helyezi át, biztosítva, hogy a hipervizor ne hozzon létre aktív leképezéseket egy törölt gyökér alatt. Ezeket a javításokat már implementálták a stabil kernel ágakban, és széles körben terjesztik különböző disztribúciók.
Azoknak a rendszergazdáknak, akik nem tudnak azonnal frissíteni, léteznek rendkívül hatékony ideiglenes megoldások. A legfontosabb intézkedés a beágyazott virtualizáció letiltása minden olyan szerveren, ahol az nem feltétlenül szükséges, a `nested=0` paraméter átadásával a `kvm_amd` vagy `kvm_intel` moduloknak a modprobe konfigurációs fájlokban. Ez az intézkedés a modul újratöltését igényli, ami az összes aktív virtuális gép leállítását jelenti.
Végül, ha további részletekre vagy kíváncsi, a következő linken megtalálod a részleteket.