В 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, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Модули на Go стирают диски на Linux-серверах: опасная атака через GitHub

Исследователи из компании Socket, занимающейся безопасностью цепочек поставок, обнаружили новую волну атак на Linux-серверы — и на этот раз злоумышленники действуют через модули на Go, опубликованные на GitHub.

Вредоносный код был обнаружен в трёх модулях, замаскированных под легитимные проекты. Внутри — сильно запутанный код, который тянет на сервер скрипт с говорящим названием done.sh и тут же запускает его.

Что делает скрипт? Он запускает команду dd, которая затирает весь диск нулями. Да-да, весь: основной том /dev/sda, где хранится всё — от операционной системы до пользовательских файлов и баз данных. После такого «обнуления» восстановить систему уже невозможно — она становится полностью неработоспособной.

Атака нацелена исключительно на Linux-среду — скрипт предварительно проверяет, что выполняется именно на ней (runtime.GOOS == "linux"). И если всё «по плану» — начинается уничтожение данных.

Socket отмечает, что всё происходит практически мгновенно: модули скачивают скрипт с помощью wget и сразу запускают его. Реагировать просто не успеешь.

Вот список зловредных модулей, которые были удалены с GitHub после обнаружения:

  • github[.]com/truthfulpharm/prototransform
  • github[.]com/blankloggia/go-mcp
  • github[.]com/steelpoor/tlsproxy

Все трое выглядели как нормальные разработки: один якобы конвертировал данные сообщений, второй реализовывал протокол Model Context, а третий предлагал TLS-прокси для TCP и HTTP. Но на деле — лишь прикрытие для деструктивного кода.

Проблему усугубляет сама архитектура Go-экосистемы: из-за децентрализации и отсутствия строгой модерации злоумышленники могут создавать модули с любыми именами — даже такими, что выглядят как «настоящие». И если разработчик случайно подключит такой модуль — последствия могут быть катастрофическими.

Вывод простой: даже кратковременный контакт с этими модулями — это прямой путь к полной потере данных. Будьте осторожны, проверяйте зависимости и не доверяйте незнакомым репозиториям, даже если они выглядят «по-настоящему».

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

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