Приблизно 200 000 пристроїв Framework на Linux отримали з заводу легально підписані компоненти UEFI Shell, які містять команду memory modify (mm). За даними дослідників Eclypsium, цю можливість можна використати для обходу Secure Boot і завантаження стійких буткітів. Виробник підтвердив проблему та готує оновлення; користувачам рекомендовано встановити патчі й тимчасово обмежити фізичний доступ до пристроїв.
Суть проблеми: підписаний UEFI Shell і ризики для ланцюга довіри
UEFI Shell — інструмент низькорівневої діагностики, який на деяких пристроях постачається у підписаному вигляді для сумісності з Secure Boot. У виявленій конфігурації Shell містить команду mm, що надає прямий доступ на читання/запис системної пам’яті. За оцінкою Eclypsium, це дозволяє змінювати критичні структури раннього етапу завантаження, включно зі змінною gSecurity2, яка впливає на перевірку підписів UEFI-модулів.
Чому це критично для Secure Boot
Secure Boot забезпечує ланцюг довіри: на старті виконуються лише компоненти, підписані довіреним виробником. Якщо змінну gSecurity2 перезаписати, наприклад до NULL, перевірка підписів фактично вимикається. У такому разі можливе завантаження неавторизованих або шкідливих модулів ще до старту ОС, що відкриває шлях до буткітів і надстійкого закріплення загрози. Подібні техніки вже використовувалися в реальних атаках проти механізмів захисту завантаження.
Масштаб і походження: помилка конфігурації, а не компрометація ланцюга постачання
Eclypsium оцінює вплив приблизно у 200 тисяч пристроїв Framework. Дослідники наголошують: ідеться не про злам ланцюга постачання, а про конфігураційну помилку у підписаному UEFI Shell. Компанія Framework визнала проблему та розгортає виправлення поетапно.
Сценарії зловживання: від ручного втручання до автозапуску
Зловмисник, який може запустити UEFI Shell на цільовому пристрої, здатен скористатися командою mm для модифікації пам’яті та тимчасового вимкнення перевірок. Далі можливе впровадження буткіта, який завантажуватиметься першим. На практиці атаку можна автоматизувати через UEFI-скрипти автозапуску, що забезпечує збереження загрози після перезавантаження і навіть переживання перевстановлення ОС. Найвищі ризики виникають за наявності фізичного доступу або можливості завантаження з зовнішніх носіїв/мережі.
Як знизити ризики власникам пристроїв Framework
Оновлення прошивки/BIOS/UEFI. Встановіть офіційні патчі від Framework одразу після виходу. Це базовий крок, що блокує небезпечну поведінку UEFI Shell і унеможливлює обхід Secure Boot.
Контроль фізичного доступу. Увімкніть надійні паролі прошивки (UEFI/BIOS), забороніть завантаження з зовнішніх носіїв і зафіксуйте пріоритет завантаження. Розгляньте використання засобів захисту від несанкціонованого доступу до портів.
Обмеження UEFI Shell та драйверів. Якщо доступно, вимкніть UEFI Shell або забороніть виконання неавторизованих UEFI-драйверів і застосунків. Принцип «мінімально необхідний функціонал» на рівні прошивки суттєво зменшує площу атаки.
Тимчасове видалення DB-ключа Framework. За відсутності оновлення розгляньте видалення DB-ключа виробника через налаштування BIOS як тимчасовий захід. Це зменшує ризик запуску підписаних компонентів Shell, що можуть бути зловживані. Врахуйте можливі проблеми сумісності та відновіть ключі після інсталяції патчів.
Моніторинг цілісності та раннього етапу завантаження
Впровадьте моніторинг подій Secure Boot, використовуйте TPM, механізми Measured Boot та журнали для перевірки цілісності. Регулярно аудитуйте конфігурацію UEFI на предмет несанкціонованих змін. Такі практики допомагають своєчасно виявляти втручання на докернельному рівні, характерні для буткітів.
Випадок із UEFI Shell на пристроях Framework демонструє: навіть легітимні діагностичні інструменти, підписані для сумісності з Secure Boot, можуть стати вразливою ланкою ланцюга довіри. Користувачам і організаціям варто оперативно встановлювати оновлення виробника, мінімізувати можливість запуску неперевіреного коду до старту ОС і дотримуватися принципу «мінімально необхідного функціоналу». Чим швидше буде усунено ризикові конфігурації та посилено політики контролю завантаження, тим нижчою буде ймовірність стійких атак із використанням буткітів.
