Специалисты компании Okta обнаружили уязвимость в библиотеке OpenSSL, получившую название HollowByte, которая позволяет вызвать состояние отказа в обслуживании на сервере при помощи вредоносной нагрузки размером всего 11 байт. Проблема связана с некорректным выделением памяти при обработке TLS-соединений, и хотя сопровождающие OpenSSL уже выпустили исправления для всех затронутых версий, включая устаревшие, CVE-идентификатор данной уязвимости присвоен не был. Учитывая фундаментальную роль OpenSSL в безопасных интернет-коммуникациях, профильным организациям рекомендуется в приоритетном порядке интегрировать исправленные версии библиотеки.

Механизм эксплуатации уязвимости заключается в том, что в процессе установления TLS-соединения каждое сообщение содержит 4-байтный заголовок, информирующий о размере входящих данных. Уязвимые версии OpenSSL выделяют область памяти под заявленную длину сообщения еще до получения самой полезной нагрузки и до проверки ее фактического размера. При поступлении вредоносного заголовка компонент состояния запускает процедуру выделения памяти без проверки. Получив 11-байтную нагрузку, конечный автомат TLS считывает 4-байтовый заголовок рукопожатия и запускает непроверенное предварительное выделение памяти на основе 3-байтового объявления длины. Цепочка вызовов выглядит следующим образом: Read Header ⟶ grow_init_buf() ⟶ OPENSSL_clear_realloc() ⟶ malloc(attacker_size). Поскольку проверка полезной нагрузки не выполняется, функция malloc() выделяет до 131 КБ памяти, основываясь исключительно на ложных данных, после чего рабочий поток уходит в цикл бесконечного ожидания данных, которые никогда не поступят.

Исследователи подчеркивают, что многократное открытие соединений для исчерпания ресурсов сервера — известный прием, однако HollowByte создает дополнительную проблему из-за особенностей работы GNU C Library (glibc) с памятью. Когда вредоносное соединение обрывается, OpenSSL высвобождает выделенный буфер, но glibc не сразу возвращает операционной системе освободившиеся ресурсы малого и среднего размера, а сохраняет их для потенциального повторного использования. Манипулируя множественными волнами запросов с разными заявленными длинами, злоумышленник препятствует перераспределению памяти, что приводит к существенной фрагментации кучи. В результате максимальный размер резидентной памяти постоянно растет и остается раздутым даже после прекращения атаки, а единственным способом перераспределить память становится остановка процесса OpenSSL.

Команда Okta протестировала уязвимые и защищенные экземпляры OpenSSL под управлением NGINX в различных условиях. В стандартной среде с 1 ГБ оперативной памяти незащищенный сервер прекратил работу из-за ошибки нехватки памяти (OOM) в тот момент, когда на зависшую и фрагментированную память приходилось 547 мегабайт. В более производительных средах с 16 ГБ ОЗУ атака успешно блокировала 25% всей памяти системы, оставаясь при этом в пределах установленного лимита соединений. Это означает, что стандартные средства защиты, ограничивающие количество входящих подключений, не способны предотвратить атаку HollowByte. Эксперт по информационной безопасности компании SEQ Александр Зонов считает, что такую атаку очень легко выполнить, сложно отразить, а ее последствия сопоставимы с распределенной DDoS-атакой, и ущерб от простоя может быть колоссальным.

Библиотека OpenSSL встроена в широкий спектр популярного программного обеспечения, включая веб-серверы Nginx и Apache, среды выполнения Node.js, Python, Ruby и PHP, а также базы данных MySQL и PostgreSQL, и предустановлена на большинстве дистрибутивов Linux с поддержкой TLS-шифрования и обработки сертификатов безопасности. Исправление, предотвращающее резервирование памяти на основе ложных данных из заголовка, вошло в версии 4.0.1, 3.6.3, 3.5.7, 3.4.6 и 3.0.21. Теперь буфер памяти выделяется не на основе заявленной в заголовке длины, а на основе фактического размера входящего сообщения.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *