В Oracle Linux выявлены серьёзные проблемы в реализации UEFI Secure Boot

В Oracle Linux выявлены серьёзные проблемы в реализации UEFI Secure Boot

Компания Oracle объявила о реализации в выпуске дистрибутива Oracle Linux 7.1 возможности верификации процесса загрузки на системах с UEFI Secure Boot. Мэтью Гаррет (Matthew Garrett), один из разработчиков ядра Linux, активно занимающийся обеспечением загрузки Linux на системах с UEFI, выступилс критикой поддержки UEFI Secure Boot в Oracle Linux и указал на серьёзные проблемы с безопасностью, позволяющие выполнить произвольный код, незаверенный цифровой подписью.

Механизм UEFI Secure Boot позволяет гарантировать использование на этапе загрузки системы только оригинальных компонентов, заверенных цифровой подписью. В RHEL и Oracle Linux, при использовании UEFI Secure Boot, обеспечивается проверка загрузчика, ядра, загружаемых ядром драйверов и модулей ядра. Для обеспечения защиты от выполнения непроверенных компонентов, при загрузке с верификацией в ядре необходимо отключить ряд возможностей, таких как вызов kexec и интерфейсы, позволяющие вносить изменения в память ядра из пространства пользователя. В частности, kexec предоставляет возможность загрузки нового ядра из уже запущенного ядра Linux, что может быть использовано для обхода UEFI Secure Boot путём замены проверенного ядра на другое ядро, не снабжённое цифровой подписью, сообщает opennet.ru.

Как известно, в Oracle Linux кроме клона ядра из состава RHEL также поставляется собственный вариант ядра Unbreakable Enterprise Kernel, поддерживаемый силами Oracle. Проблема состоит в том, что цифровые подписи для обоих ядер созданы с использование одного ключа. Если в клоне ядра RHEL при загрузке в UEFI Secure Boot производится отключение опасных компонентов ядра, то в ядре Unbreakable Enterprise Kernel остаётся активен kexec, что сводит на нет всю цепочку доверия. Даже при использовании ядра RHEL в Oracle Linux, атакующий имеет возможность загрузить имеющее корректную цифровую подпись ядро Unbreakable Enterprise Kernel, а затем через kexec запустить модифицированный вариант ядра с бэкдором.

Интересно также то, что ключ для создания цифровой подписи для Oracle Linux назван "oracle301", при том, что число 301 выбрано так как ключ в RHEL тоже оканчивается на 301, но без учёта того, что 301 не имеет принципиального значения и является лишь порядковым номером сгенерированного в Red Hat ключа. 

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Обнаружена уязвимость в WDS: PXE-сервер можно вывести из строя удалённо

Если вы всё ещё используете Windows Deployment Services (WDS) для раздачи образов Windows по сети, пора всерьёз задуматься. Специалист обнаружил серьёзную уязвимость, которая позволяет удалённо и без аутентификации вывести из строя сервер буквально за несколько минут.

Да-да, без логинов, паролей и вообще какого-либо взаимодействия с пользователем — просто взял и положил.

WDS использует старый добрый протокол TFTP по UDP (порт 69) для раздачи установочных образов Windows. При подключении клиента сервер создаёт объект CTftpSession.

Проблема в том, что никакого лимита на число сессий не предусмотрено. В результате злоумышленник может подделывать IP-адреса и порты, рассылать фальшивые UDP-пакеты — и сервер начинает захлёбываться в собственных объектах.

«Ключевая проблема в том, что EndpointSessionMapEntry не накладывает ограничений на число сессий», — говорится в техническом отчёте. — «Атакующий может подделывать IP-адреса и номера портов, многократно создавая новые сессии, пока ресурсы системы не будут исчерпаны».

На тестовом сервере с Windows Server Insider Preview и 8 ГБ оперативной памяти исследователю Чжиниану Пэну удалось полностью обрушить систему за 7 минут — исключительно с помощью случайных UDP-пакетов с поддельными исходными адресами.

Это классическая zero-click DoS-атака — никаких действий со стороны пользователя не требуется. Просто поток UDP-трафика, и PXE-инфраструктура, через которую разворачиваются Windows-образы, оказывается парализованной.

Что ответил Microsoft? Пэн сообщил об уязвимости в Microsoft 8 февраля 2025 года. 4 марта компания подтвердила наличие бага, а 23 апреля… отказалась его исправлять. По официальной позиции Microsoft, проблема «не соответствует критериям для выпуска патча».

Пэн не скрывает разочарования:

«Мы считаем, что это важная уязвимость, которая подпадает под стандарт SDL, и нам было очень неприятно общаться с Microsoft по этому поводу», — написал он.

Тем не менее Microsoft патч выпускать не планирует, поэтому Пэн даёт однозначную рекомендацию:

«Чтобы защитить PXE-сеть от этой угрозы, не используйте Windows Deployment Services».

Альтернативы — сторонние PXE-решения на базе Linux, кастомные сборки или переход к другим способам развёртывания.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

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