Уразливості в UEFI-прошивках на базі фреймворку InsydeH2O, що дозволяють виконати код на рівні SMM

У фреймворку InsydeH2O, що застосовується багатьма виробниками для створення UEFI-прошивок до свого обладнання (найпоширеніша реалізація UEFI BIOS), виявлено 23 вразливості, що дозволяють виконати код на рівні SMM (System Management Mode), більш пріоритетному (Ring-2) і нульове кільце захисту, які мають необмежений доступ до всієї пам'яті. Проблема торкається UEFI-прошивки, які використовуються такими виробниками, як Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel та Bull Atos.

Для експлуатації вразливостей потрібен локальний доступ із правами адміністратора, що робить проблеми затребуваними як уразливості другої ланки, що застосовуються після експлуатації інших уразливостей у системі або використання методів соціальної інженерії. Доступ на рівні SMM дозволяє виконати код на рівні, непідконтрольному операційній системі, що може бути використане для модифікації прошивок та залишення в SPI Flash прихованого шкідливого коду або руткітів, які не визначаються з операційної системи, а також для відключення верифікації на етапі завантаження (UEFI Secure Boot) , Intel BootGuard) та атак на гіпервізори для обходу механізмів перевірки цілісності віртуальних оточень.

Уразливості в UEFI-прошивках на базі фреймворку InsydeH2O, що дозволяють виконати код на рівні SMM

Експлуатація уявзимостей може бути здійснена з операційної системи за допомогою неверифікованих SMI-обробників (System Management Interrupt), а також на етапі до виконання операційної системи під час початкових стадій завантаження або повернення зі сплячого режиму. Усі вразливості викликані проблемами роботи з пам'яттю та поділені на три категорії:

  • SMM Callout - виконання свого коду з правами SMM через перенаправлення виконання обробників переривань SWSMI на код поза SMRAM;
  • Пошкодження пам'яті, що дозволяють атакуючому записати свої дані в SMRAM, спеціальну ізольовану область пам'яті, в якій виконується код із правами SMM.
  • Пошкодження пам'яті в коді, що виконується на рівні DXE (Driver eXecution Environment).

Для демонстрації принципів організації атаки опубліковано приклад експлоїту, що дозволяє через проведення атаки з третього або нульового кільця захисту отримати доступ до DXE Runtime UEFI і виконати свій код. Експлоїт маніпулює переповненням стека (CVE-2021-42059) у драйвері UEFI DXE. У ході атаки зловмисник може розмістити свій код у DXE-драйвері, що зберігає активність після перезапуску операційної системи, або внести зміни до області NVRAM у SPI Flash. У процесі виконання код зловмисника може вносити зміни до привілейованих областей пам'яті, модифікувати сервіси EFI Runtime та впливати на процес завантаження.

Джерело: opennet.ru

Додати коментар або відгук