Наскоро беше публикувана информация за уязвимост , която излага на риск облачните сървъри. Тази уязвимост позволява на атакуващите да поемат пълен контрол над физическата машина , което е кошмарен сценарий за доставчиците на облачна инфраструктура.
Zapscape, регистриран под идентификатор CVE-2026-64561, е критична уязвимост в хипервизора на Linux KVM, която излага на риск, който много платформи неволно поемат, като активират вложена виртуализация. Тази уязвимост позволява на атакуващ с привилегии на ядрото във виртуална машина (L1) да изпълнява код с root привилегии на хост системата (L0), нарушавайки изолацията на виртуализираните среди.
Считан за заплаха с голямо въздействие, Zapscape не само улеснява излизането от виртуалната машина, но и отваря локален маршрут за ескалация на привилегиите за потребители на хост, които имат права за запис на устройството /dev/kvm.
Въпреки че организации като Red Hat са оценили уязвимостта с CVSS оценка 7.0, фокусирайки се върху нестабилност и отказ на услуга, публичното доказателство за концепцията (PoC) демонстрира много по-разрушителен обхват: създаването на произволен файл директно в корена на хоста.
Хаос в устройството за управление на паметта
Начинът, по който работи Zapscape, е скрит в модула за управление на паметта (MMU) на KVM и в начина, по който хипервизорът обработва таблиците на страниците, когато един гост (L1) действа като хипервизор за друг подгост (L2). Проблемът се състои в логическа грешка в подреждането по време на обработката на грешки на страниците. В пътищата на кода на ядрото проверката за „остарял корен“ се изпълняваше преди функцията за извличане на страници, вместо след това.
Тази неправилна последователност задейства класически сценарий „използване след освобождаване“ . По време на възстановяване, KVM може да премахне коренния каталог, който използва, и да го маркира като невалиден. Тъй като обаче проверката за състоянието вече е изпълнена, системата продължава да изгражда съпоставяния под корен, който вече не е валиден. Интересното е, че този проблем със сортирането съществува в кода от 2008 г., но стана критичен и експлоатиран след пускането на Linux ядрото 5.9 през юли 2020 г. , когато беше въведена директива, която системата просто спря да прилага.
Изисквания и ограничения
За да може Zapscape да бъде експлоатиран, средата трябва да отговаря на много специфични изисквания. Първо, в KVM модула трябва да бъде активирана вложена виртуализация, конфигурация, която позволява трислойна архитектура (L0, L1 и L2). Атакуващият трябва да инициира атаката от L1 слой , което изисква root права на тази виртуална машина. Оттам атакуващият манипулира режимите на паметта, докато активността на L2 под-госта принуждава L0 хоста да инициира извличане на страница с квоти, причинявайки повреда на паметта.
На хардуерно ниво условията варират в зависимост от производителя. При AMD системи , които използват вложени таблици на страници ( SVM ), уязвимостта е по-лесна за разрешаване и не изисква допълнителни функции. Обратно, при Intel процесори сценарият изисква L1 гостът да е разкрил възможности за EPT Pagewalk на четири и пет нива . Това ограничава вектора на атака срещу Intel до по-нови архитектури, по-специално от семейството Ice Lake-SP нататък.
Заслужава да се отбележи, че въпреки че публичното доказателство за концепцията е успяло да се разпространи до хоста в контролирани среди, изследователите по сигурността съобщават, че при някои рекомпилирани ядра експлойтът просто срива виртуалната машина на нападателя, действайки като отказ на услуга, а не като пълно бягство.
Смекчаване, корекции и стратегии
Окончателното решение за Zapscape пристигна в Linux хранилищата миналия юли с пач, който коригира реда на валидиране. Тази корекция премества проверката за остарял root да се извършва след разпределението на страницата на MMU, като гарантира, че хипервизорът не създава активни съпоставяния под изтрит root. Тези корекции вече са внедрени в стабилните клонове на ядрото и се разпространяват широко от различни дистрибуции.
За администратори, които не могат да надстроят незабавно, съществуват високоефективни временни мерки за смекчаване на проблемите. Приоритетното действие е да се деактивира вложената виртуализация на всички сървъри, където не е строго необходима, чрез предаване на параметъра `nested=0` на модулите `kvm_amd` или `kvm_intel` в конфигурационните файлове на modprobe. Тази мярка изисква презареждане на модула, което означава спиране на всички активни виртуални машини.
И накрая, ако се интересувате да научите повече, можете да намерите подробностите на следния линк.