LINUX.ORG.RU

В Exim 4.99.3 устранена уязвимость, позволяющая удалённое выполнение кода при использовании GnuTLS

 , ,


0

1

Разработчики почтового сервера Exim выпустили корректирующий релиз Exim 4.99.3, устраняющий уязвимость в некоторых конфигурациях почтового агента. Проблема проходит под внутренним идентификатором EXIM-Security-2026-05-01.1; в официальном уведомлении также фигурирует как CVE-TBD.

Уязвимость относится к классу Remote Use-After-Free и проявляется при разборе тела сообщения BDAT при работе TLS через GnuTLS. BDAT используется в SMTP-расширении CHUNKING для передачи тела письма блоками. Согласно описанию Exim, ошибка может быть вызвана, когда клиент во время передачи BDAT отправляет TLS-уведомление close_notify до завершения передачи тела, а затем добавляет дополнительный байт в рамках того же TCP-соединения.

В такой последовательности Exim может записать данные в буфер памяти, который уже был освобождён при завершении TLS-сессии. Это приводит к повреждению кучи и потенциально может быть использовано для выполнения кода. В уведомлении подчёркивается, что атакующему достаточно иметь возможность установить TLS-соединение и использовать SMTP-расширение CHUNKING / BDAT.

Проблема затрагивает Exim 4.97, 4.98, 4.99, 4.99.1 и 4.99.2, но только сборки, собранные с поддержкой GnuTLS. В официальной документации это сформулировано как конфигурации с USE_GNUTLS=yes; сборки, использующие OpenSSL или другие TLS-библиотеки, данной уязвимостью не затронуты. Также в уведомлении Exim отдельно указано, что уязвимы конфигурации, где объявляются STARTTLS и CHUNKING.

Исправление включено в Exim 4.99.3. По описанию разработчиков, патч гарантирует чистый сброс стека обработки ввода при получении TLS close_notify во время активной передачи BDAT, что предотвращает дальнейшее использование устаревших указателей. Иного известного способа полностью закрыть проблему, кроме обновления, в рекомендациях не приведено.

Разработчики Exim получили сообщение об ошибке 1 мая 2026 года от Federico Kirschbaum из XBOW Security. После проверки отчёта исправление готовилось в закрытых репозиториях, 7 мая о проблеме уведомили дистрибутивы через закрытый список рассылки, 10 мая им предоставили ограниченный доступ к исправлениям, а 12 мая 2026 года состоялась публикация рекомендаций и самого релиза с исправлением.

Администраторам почтовых серверов рекомендуется проверить используемую версию Exim и TLS-бэкенд сборки. Если сервер работает на Exim от 4.97 до 4.99.2 включительно, собран с GnuTLS и объявляет STARTTLS вместе с CHUNKING, проект Exim рекомендует как можно быстрее перейти на Exim 4.99.3 или более новую версию. Исправленные исходные тексты доступны в ветке exim-4.99+fixes и теге exim-4.99.3, а также в виде tarball-архивов на обычных площадках загрузки Exim.

>>> Источник

★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 6)

После исправления нейрослопа надо подтвердить новость с отрицательным скором.

firkax ★★★★★
()
Ответ на: комментарий от dataman

я уже говорил, я пишу, корректоры решают

если новость есть на опеннет я беру оттуда, если нахожу в других местах, ну ты понел

unclestephen ★★★
() автор топика
Ответ на: комментарий от firkax

Я слегка почистил стиль, но не уверен в правильности перевода

а затем добавляет последний байт открытым текстом

В оригинале:

and then follows up with a final byte in cleartext on the same TCP connection.

Не уверен, что в данном случае означает cleartext и как его правильно переводить.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Клиент шлёт серверу команду окончания TLS-сессии, а затем шлёт ещё один байт (я почти уверен, что послать можно и больше одного и будет то же самое). Суть в том, что при команде закрывания сессии exim освобождает какие-то структуры или буферы, а затем, когда в сокет приходит ещё что-то, он пытается к освобождённым участкам памяти обратиться чтобы этот новый байт туда всунуть. Поскольку tls-сессия закрыта, exim считает присланный байт незашифрованным - это и есть clear text.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)

Классический пример уязвимости от которой помогло бы переписывание на Rust. Надеюсь наконец-то займутся.

zabbal ★★★★☆
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.