Даследчыкі з каманды Google Project Zero прадставілі гэта некалькі дзён таму ў сваім блогу выявілі ўразлівасць (CVE-2021-29657) у гіпервізары KVM (гіпервізар на аснове Linux з адкрытым зыходным кодам, які падтрымлівае апаратна паскораную віртуалізацыю на x86, ARM, PowerPC і S / 390), дазваляе пазбегнуць ізаляцыі гасцявой сістэмы і запусціце свой код на баку асяроддзя хаста.
У паведамленні згадваецца, што праблема маніфесты з ядра Linux 5.10-rc1 да v5.12-rc6, гэта значыць, ахоплівае толькі ядра 5.10 і 5.11 (Большасць стабільных філіялаў дыстрыбутываў праблема не закранула.) Праблема прысутнічае ў механізме nested_svm_vmrun, рэалізаваным з выкарыстаннем пашырэння AMD SVM (Secure Virtual Machine) і дазваляе ўкладзеным запускам гасцявых сістэм.
У гэтым паведамленні ў блогу я апісваю ўразлівасць у кодзе KVM для AMD і абмяркоўваю, як гэтая памылка можа ператварыцца ў поўнае ўцёкі віртуальнай машыны. Наколькі я ведаю, гэта першае публічнае напісанне прарыву госця да хаста KVM, якое не спадзяецца на памылкі ў кампанентах карыстацкай прасторы, такіх як QEMU.
Абмеркаваная памылка была прызначана CVE-2021-29657, уплывае на версіі ядра v5.10-rc1 да v5.12-rc6 і была выпраўлена ў канцы сакавіка 2021 года. Паколькі памылка стала даступнай для выкарыстання толькі ў v5.10 і была выяўлена прыкладна праз 5 месяцаў, большасць рэальных разгортванняў KVM не павінна закранацца. Я ўсё яшчэ лічу, што праблема заключаецца ў цікавым тэматычным даследаванні працы, неабходнай для стварэння стабільнага ўцёкаў госця да хаста супраць KVM, і я спадзяюся, што гэты артыкул можа сцвярджаць, што кампрамісы гіпервізара - гэта не толькі тэарэтычныя праблемы.
Даследчыкі згадваюць, што для правільнай рэалізацыі гэтай функцыянальнасці, гіпервізор павінен перахапіць усе інструкцыі SVM працаваць на гасцявых сістэмах, эмуляваць яго паводзіны і сінхранізаваць стан з апаратным забеспячэннем, што з'яўляецца даволі складанай задачай.
Прааналізаваўшы прапанаваную рэалізацыю KVM, даследчыкіs сутыкнулася з лагічнай памылкай, якая дазваляе змест MSR (Рэгістрацыя для канкрэтнай мадэлі) гаспадара быць пад уплывам госцявай сістэмы, які можна выкарыстоўваць для выканання кода на ўзроўні хаста.
У прыватнасці, выкананне аперацыі VMRUN з госця другога ўкладзенага ўзроўню (L2 запушчаны з іншага госця) прыводзіць да другога выкліку nested_svm_vmrun і псуе структуру svm-> nested.hsave, якая накладваецца на дадзеныя з vmcb з гасцявой сістэмы L2 .
У выніку ўзнікае сітуацыя, калі на ўзроўні гасцей L2 можна вызваліць памяць у структуры svm-> nested.msrpm, якая захоўвае біт MSR, нягледзячы на тое, што ён працягвае выкарыстоўвацца, і атрымаць доступ да MSR хаста навакольнае асяроддзе.
Гэта азначае, напрыклад, што памяць госця можа быць праверана шляхам выгрузкі выдзеленай памяці працэсу карыстацкай прасторы альбо што абмежаванні рэсурсаў для працэсара і памяці могуць быць лёгка забяспечаны.
Акрамя таго, KVM можа разгрузіць большую частку працы, звязанай з эмуляцыяй прылады, на кампанент карыстацкай прасторы.
Праблема прысутнічае ў кодзе, які выкарыстоўваецца ў сістэмах з працэсарамі AMD (модуль kvm-amd.ko), і не з'яўляецца ў працэсарах Intel.
За межамі пары прадукцыйных прылад, звязаных з апрацоўкай перапыненняў, увесь складаны код нізкага ўзроўню для прадастаўлення доступу да віртуальнага дыска, сеткі альбо графічнага працэсара можа быць разгорнуты ў карыстацкай прасторы.
Даследчыкі ў дадатак да апісання праблемы Яны таксама падрыхтавалі дзеючы прататып эксплойта які дазваляе запускаць каранёвую абалонку з гасцявой асяроддзя ў хастовым асяроддзі ў сістэме з працэсарам AMD Epyc 7351P і ядром Linux 5.10.
Заўважана, што гэта першы госць, які размясціў уразлівасць у гіпервізары KVM сам па сабе, не звязаны з памылкамі ў такіх кампанентах карыстацкай прасторы, як QEMU. Выпраўленне было прынята ў ядры ў канцы сакавіка.
У рэшце рэшт калі вам цікава даведацца пра гэта больш пра нататку вы можаце праверыць дэталі Па наступнай спасылцы.
Будзьце першым, каб каментаваць