MSI сломала защиту Secure Boot в прошивке сотен материнских плат

MSI сломала защиту Secure Boot в прошивке сотен материнских плат

MSI сломала защиту Secure Boot в прошивке сотен материнских плат

Более 290 материнских плат от MSI по умолчанию содержат небезопасную настройку UEFI Secure Boot, позволяющую загружать образ операционной системы с некорректной или отсутствующей подписью.

На проблему указал польский исследователь Давид Потоцкий. По его словам, неоднократные попытки связаться с MSI и проинформировать компанию о баге не привели к результату.

Как отметил Потоцкий, проблема затрагивает множество материнских плат от MSI, как на Intel, так и на AMD. Среди проблемных материнок есть и последние модели, использующие актуальную версию прошивки.

Secure Boot — одна из защитных функций, встроенных в прошивку UEFI-плат. Её задача — следить, чтобы только доверенный (подписанный) софт загружался на этапе запуска операционной системы.

Чтобы зафиксировать подлинность ядра, загрузчика ОС и других критически важных компонентов, Secure Boot проверяет PKI (public key infrastructure, инфраструктура открытых ключей). Если софт не подписан или сама подпись была модифицирована, Secure Boot заблокирует загрузку системы.

Давид Потоцкий утверждает, что версия прошивки MSI под номером 7C02v3C, выпущенная 18 января 2022 года, поменяла дефолтные настройки Secure Boot. Теперь ОС загрузится даже в том случае, если были обнаруженные сомнительные компоненты.

 

Полный список затронутых материнских плат Потоцкий выложил на GitHub. Пользователям рекомендуют зайти в настройки BIOS и проверить опцию “Image Execution Policy“. Её значение нужно установить на “Deny Execute“.

Напомним, в ноябре геймеры подверглись атаке фейкового MSI Afterburner, который устанавливал на их компьютеры майнеры и троян RedLine.

Замедление Telegram ударило по разработчикам российских ОС

В России оказался недоступен сервис git.kernel.org, через который разработчики получают обновления исходного кода ядра Linux. Крупные участники сообщества подтвердили проблему и связали её с действиями Роскомнадзора. Сам регулятор свою причастность отрицает.

Первые сообщения о сбоях в доступе к kernel.org появились 12 февраля. Пользователи отмечали, что зайти на ресурс без использования средств подмены адреса невозможно — ни по протоколу git, ни по HTTP. Аналогичные трудности возникли и с рядом других сайтов, в том числе с онлайн-курсами по Python и ресурсами разработчиков некоторых системных библиотек.

Портал Digital Report сообщил, что сбои могли быть связаны с мерами Роскомнадзора по замедлению Telegram. По версии издания, при попытке точечно ограничить трафик мессенджера и популярных VPN-протоколов (WireGuard, OpenVPN) применялась тактика «ковровых» блокировок по диапазонам IP-адресов. В результате под ограничения могли попасть CDN-сети, на которых размещаются зеркала Linux Kernel Archives.

Как отмечает Digital Report, ещё 12 февраля разработчики обратились в профильные группы Минцифры с просьбой разобраться в ситуации. По их словам, официальной реакции долгое время не последовало, а обсуждения сопровождались смесью тревоги и иронии.

Лишь сегодня Роскомнадзор в ответ на запрос издания «Подъём» сообщил: «Решения уполномоченных органов в отношении сервисов Linux не поступали, меры ограничения к ним не применяются».

После публикации комментария доступ к сервису начал постепенно восстанавливаться. Об этом, в частности, рассказал Алексей Смирнов в комментарии для Forbes.

Накануне похожие проблемы возникли у пользователей Windows: обновления системы либо не загружались, либо устанавливались с заметными задержками. Тогда Роскомнадзор также отрицал свою причастность.

RSS: Новости на портале Anti-Malware.ru