Дві вразливості у GRUB2, що дозволяють обійти захист UEFI Secure Boot

Розкрито відомості про дві вразливості у завантажувачі GRUB2, які можуть призвести до виконання коду при використанні спеціально оформлених шрифтів та обробці певних Unicode-послідовностей. Уразливості можуть використовуватися для обходу механізму верифікованого завантаження UEFI Secure Boot.

Виявлені вразливості:

  • CVE-2022-2601 — переповнення буфера функції grub_font_construct_glyph() при обробці спеціально оформлених шрифтів у форматі pf2, що виникає через неправильний розрахунок параметра max_glyph_size і виділення області пам'яті, явно меншої, ніж необхідно для розміщення гліфів.
  • CVE-2022-3775 - запис за межі виділеної області пам'яті при відтворенні деяких послідовностей Unicode спеціально оформленим шрифтом. Проблема присутня в коді обробки шрифтів та викликана відсутністю належних перевірок відповідності ширини та висоти гліфу розміру наявної бітової картки. Атакуючий може підібрати введення таким чином, щоб викликати запис хвоста даних межами виділеного буфера. Зазначається, що, незважаючи на складність експлуатації вразливості, доведення проблеми до виконання коду не виключається.

Виправлення опубліковано як патча. Статус усунення вразливостей у дистрибутивах можна оцінити на сторінках: Ubuntu, SUSE, RHEL, Fedora, Debian. Для усунення проблем у GRUB2 недостатньо просто оновити пакет, потрібно також сформувати нові внутрішні цифрові підписи та оновлювати інсталятори, завантажувачі, пакети з ядром, fwupd-прошивки та shim-прошарку.

У більшості Linux-дистрибутивів для верифікованого завантаження в режимі UEFI Secure Boot використовується невеликий прошарок shim, завірений цифровим підписом Microsoft. Цей прошарок верифікує GRUB2 власним сертифікатом, що дозволяє розробникам дистрибутивів не завіряти кожне оновлення ядра та GRUB у Microsoft. Уразливості в GRUB2 дозволяють досягти виконання свого коду на етапі після успішної верифікації shim, але до завантаження операційної системи, вклинившись в ланцюжок довіри при активному режимі Secure Boot і отримавши повний контроль за подальшим процесом завантаження, у тому числі для завантаження іншої ОС, модифікації компонентів операційної системи та обходу захисту Lockdown.

Для блокування вразливості без відкликання цифрового підпису дистрибутиви можуть використовувати механізм SBAT (UEFI Secure Boot Advanced Targeting), підтримка якого реалізована для GRUB2, shim та fwupd у більшості популярних Linux-дистрибутивів. SBAT розроблений спільно з Microsoft і передбачає додавання до виконуваних файлів компонентів UEFI додаткових метаданих, які включають інформацію про виробника, продукт, компонент і версію. Зазначені метадані завіряються цифровим підписом і можуть окремо включатися до списків дозволених або заборонених компонентів для UEFI Secure Boot.

SBAT дозволяє блокувати використання цифрового підпису для окремих номерів версій компонентів без необхідності відкликання ключів для Secure Boot. Блокування вразливостей через SBAT не вимагає використання списку відкликаних сертифікатів UEFI (dbx), а проводиться на рівні заміни внутрішнього ключа для формування підписів та оновлення GRUB2, shim та інших завантажувальних артефактів, що поставляються дистрибутивами. До впровадження SBAT, оновлення списку відкликаних сертифікатів (dbx, UEFI Revocation List) було обов'язковою умовою повного блокування вразливості, оскільки атакуючий, незалежно від операційної системи, міг для компрометації UEFI Secure Boot використовувати завантажувальний носій зі старою вразливою версією GRUB .

Джерело: opennet.ru

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