Badacze z zespołu Google Project Zero ujawnili kilka dni temu w poście na blogu, że zidentyfikowali lukę (CVE-2021-29657) w hipernadzorcy KVM (hiperwizor open source oparty na systemie Linux, który obsługuje wirtualizację przyspieszaną sprzętowo na x86, ARM, PowerPC i S / 390), pozwala uniknąć izolacji systemu gościa i uruchom swój kod po stronie środowiska hosta.
W poście wspomniano, że problem manifesty z jądra Linux 5.10-rc1 do v5.12-rc6, to znaczy obejmuje tylko jądra 5.10 i 5.11 (Problem nie dotyczył większości stabilnych gałęzi dystrybucji). Problem tkwi w mechanizmie nested_svm_vmrun, zaimplementowanym przy użyciu rozszerzenia AMD SVM (Secure Virtual Machine) i umożliwiającym zagnieżdżone uruchamianie systemów gościa.
W tym poście opiszę lukę w kodzie KVM specyficznym dla AMD i omówię, w jaki sposób ten błąd może przekształcić się w całkowitą ucieczkę maszyny wirtualnej. O ile mi wiadomo, jest to pierwszy publiczny wpis dotyczący przełamania KVM między gośćmi a hostem, który nie opiera się na błędach w komponentach przestrzeni użytkownika, takich jak QEMU.
Omawiany błąd został przypisany CVE-2021-29657, dotyczy wersji jądra v5.10-rc1 do v5.12-rc6 i został załatany pod koniec marca 2021 r. Ponieważ błąd stał się możliwy do wykorzystania dopiero w wersji 5.10 i został wykryty około 5 miesięcy później, większość rzeczywistych wdrożeń KVM nie powinna mieć wpływu. Nadal uważam, że problemem jest interesujące studium przypadku w pracy wymaganej do zbudowania stabilnej ucieczki gościa do hosta przeciwko KVM i mam nadzieję, że ten artykuł może udowodnić, że kompromisy z hiperwizorem nie są tylko problemami teoretycznymi.
Badacze wspominają, że dla prawidłowej realizacji tej funkcjonalności, hiperwizor musi przechwycić wszystkie instrukcje SVM działają na systemach gościa, emulować jego zachowanie i synchronizować stan ze sprzętem, co jest dość trudnym zadaniem.
Po przeanalizowaniu proponowanego wdrożenia KVM, badaczes napotkał błąd logiczny, który zezwala na zawartość MSR (Rejestracja specyficzna dla modelu) hosta być pod wpływem systemu gościa, który może służyć do wykonywania kodu na poziomie hosta.
W szczególności uruchomienie operacji VMRUN z drugiego gościa poziomu zagnieżdżonego (L2 uruchomionego z innego gościa) prowadzi do drugiego wywołania nested_svm_vmrun i uszkadza strukturę svm-> nested.hsave, która jest nałożona na dane z vmcb z systemu gościa L2. .
W rezultacie powstaje sytuacja, w której na poziomie gościa L2 można zwolnić pamięć w strukturze svm->nested.msrpm, która przechowuje bit MSR, mimo że jest nadal używany, i uzyskać dostęp do MSR hosta środowisko.
Oznacza to na przykład, że pamięć gościa może być sprawdzona przez zrzucenie przydzielonej pamięci procesu w przestrzeni użytkownika lub że limity zasobów dla czasu procesora i pamięci mogą być łatwo wyegzekwowane.
Ponadto KVM może przenieść większość pracy związanej z emulacją urządzenia na komponent przestrzeni użytkownika.
Problem występuje w kodzie używanym w systemach z procesorami AMD (moduł kvm-amd.ko) i nie pojawia się na procesorach Intel.
Poza kilkoma wrażliwymi na wydajność urządzeniami zajmującymi się obsługą przerwań, cały złożony kod niskiego poziomu zapewniający dostęp do dysku wirtualnego, sieci lub GPU można wdrożyć w przestrzeni użytkownika.
Naukowcy oprócz opisania problemu przygotowali też działający prototyp exploita co pozwala na uruchomienie powłoki root ze środowiska gościa w środowisku hosta na systemie z procesorem AMD Epyc 7351P i jądrem Linux 5.10.
Zauważono, że jest to pierwszy gość, który hostuje lukę w hipernadzorcy KVM sam w sobie, niezwiązany z błędami w komponentach przestrzeni użytkownika, takich jak QEMU. Poprawka została zaakceptowana w jądrze pod koniec marca.
W końcu jeśli chcesz dowiedzieć się więcej na ten temat o notatce możesz sprawdzić szczegóły W poniższym linku.