В OpenSSL обнаружена уязвимость HollowByte, позволяющая удалённо вызвать отказ в обслуживании через фрагментацию памяти

Группа реагирования на угрозы Okta Red Team выявила уязвимость в криптографической библиотеке OpenSSL, получившую название HollowByte. Проблема позволяет удалённому неавторизованному злоумышленнику вызвать отказ в обслуживании сервера, отправив вредоносную полезную нагрузку длиной всего 11 байт. Атака происходит до начала процедуры рукопожатия TLS и приводит к неконтролируемому расходу памяти, которую невозможно освободить без перезапуска процесса.

Уязвимость HollowByte

Суть уязвимости связана с тем, как OpenSSL обрабатывает заголовок сообщения ClientHello. На этапе установки TLS-соединения клиент отправляет запрос, содержащий четырёхбайтовый заголовок, в котором указан размер передаваемых данных. В уязвимых версиях библиотеки OpenSSL выделяла буфер для приёма данных, полагаясь исключительно на заявленный в заголовке размер, ещё до того как какие-либо данные фактически поступали.

Когда атакующий отправляет ложный заголовок, TLS-автомат считывает его и запускает операцию malloc с размером, указанным злоумышленником. Поскольку проверка содержимого пакета на этом этапе отсутствует, malloc выделяет до 131 КБ памяти на основании недостоверных данных. После этого рабочий поток сервера блокируется в ожидании информации, которая никогда не придёт.

Дополнительным осложняющим фактором становится поведение библиотеки glibc. При разрыве соединения OpenSSL освобождает выделенный буфер, но glibc не сразу возвращает память небольшого и среднего размера операционной системе, а сохраняет её для возможного повторного использования. Выполняя волны соединений со случайными заявленными размерами, атакующий не даёт аллокатору переиспользовать освобождённые блоки. В результате куча фрагментируется, а резидентный размер памяти сервера непрерывно растёт. Даже после отключения атакующего память не очищается полностью - единственный способ восстановить ресурсы заключается в завершении процесса.

Тестирование незащищённых и исправленных экземпляров OpenSSL под управлением NGINX показало масштаб угрозы. В среде с 1 ГБ оперативной памяти незащищённый сервер был убит механизмом OOM-killer при достижении 547 МБ замороженной фрагментированной памяти. В конфигурации с 16 ГБ ОЗУ атака заблокировала 25 процентов всей системной памяти, оставаясь при этом ниже типовых лимитов соединений. Это означает, что стандартные средства защиты, ограничивающие число одновременных подключений, не способны предотвратить подобную атаку.

Поскольку OpenSSL широко используется в качестве базовой криптографической библиотеки, уязвимость затрагивает значительное число программных продуктов: веб-серверы (Apache, NGINX), среды выполнения языков программирования (Node.js, Python, Ruby, PHP), а также системы управления базами данных (MySQL, PostgreSQL). Атака не требует аутентификации и может быть выполнена из любой точки сети, что делает её особенно опасной для интернет-ориентированных серверов.

Разработчики OpenSSL устранили проблему, перейдя на инкрементальный рост буфера. Вместо того чтобы доверять указанному в заголовке размеру, библиотека теперь увеличивает буфер только по мере фактического поступления данных. Если пакет пуст или содержит лишь заголовок без последующего наполнения, сервер не выделяет никаких лишних ресурсов. Соответствующие изменения были внесены в пул-реквесты #30792, #30793 и #30794 и вошли в состав релиза OpenSSL v4.0.1, а также были обратно портированы в версии 3.6.3, 3.5.7, 3.4.6 и 3.0.21. Примечательно, что OpenSSL классифицировал исправление как усиление защиты (hardening fix) и не выпустил отдельное уведомление с CVE.

Специалистам по безопасности настоятельно рекомендуется обновить пакеты OpenSSL на всех затронутых системах, особенно на серверах, доступных из интернета. Ограничение числа подключений само по себе не обеспечивает защиты: атака может развиваться в рамках типового лимита соединений и при этом блокировать значительную долю памяти. Ситуация подчёркивает критическую важность своевременного обновления базовых библиотек, от которых зависит работоспособность значительной части цифровой инфраструктуры.

Уязвимость HollowByte

Ссылки