Kaspersky Secure Mail Gateway фильтрует корпоративную почту и держит промежуточные данные во встроенной базе Redis, работающей в оперативной памяти. Этот вспомогательный компонент несёт в себе уязвимость, которая позволяет удалённо выполнить произвольный код. Под угрозу попадают сборки продукта старше версии 3.1. Сведения вошли в бюллетень Kaspersky 12430#170926 от 17 сентября 2026 года. Идентификатор CVE-2023-41056 уязвимость получила ещё в январе 2024 года. Значит, исправление появилось почти через три года.
Уязвимость CVE-2023-41056
Redis нужен почтовому шлюзу для быстрых операций: он хранит очереди писем, кэш и служебные метки. Такая база живёт внутри продукта, и её обновляют вместе с основной сборкой. Именно поэтому одна и та же уязвимость тиражируется по всем установкам заказчика, пока вендор не выпустит новую версию. К тому же Redis работает с данными, которые приходят снаружи. Это делает его доступным для атакующего.
Причина сбоя - целочисленное переполнение. Redis неверно рассчитывает размер буферов при их увеличении. Когда на вход поступает специально составленный запрос, результат вычисления выходит за разрядную сетку. Под данные отводится меньше памяти, чем нужно. Затем записанная следом информация выходит за границы участка и затирает соседние области динамической памяти. Переполнение целого числа превращается в переполнение буфера, а оттуда открывается путь к исполнению чужого кода. Отдельная грань той же уязвимости - несогласованная работа функций управления памятью. Одни участки кода выделяют блок одним способом, другие освобождают его иначе. Это расхождение и становится причиной уязвимости.
Для почтового шлюза отправной точкой служит письмо. Kaspersky указывает, что уязвимость приводит к сбою продукта либо к исполнению кода при обработке файлов определённого формата. Значит, злоумышленнику достаточно доставить на шлюз вложение подходящего вида. Участие человека не требуется. Оценка по шкале CVSS 3.1 составляет 8,1 балла из 10, что относят к высокому уровню риска. Успешная эксплуатация даёт атакующему те же права, что и у самой службы. Он сможет читать письма, менять правила обработки и подменять ссылки в письмах. Заметить это без специального мониторинга трудно, поскольку шлюз и должен работать с почтой постоянно.
Почтовый шлюз стоит на границе сети и видит весь входящий поток. Если атакующий выполнит на нём свой код, он получит доступ к переписке, к учётным данным и к внутренней инфраструктуре компании. Поэтому такие серверы привлекают внимание атакующих. Они круглосуточно принимают данные от посторонних. Им приходится разбирать вложения самых разных форматов. Уязвимость в разборе файлов затрагивает самую нагруженную часть продукта.
Затронуты организации, которые поставили Kaspersky Security 10 for Linux Mail Server версии 10.0 и более ранние выпуски шлюза. Речь идёт о компаниях с собственной почтовой инфраструктурой. При этом в документации вендора названия расходятся. Бюллетень говорит о Kaspersky Secure Mail Gateway, а описание исправления ссылается на Kaspersky Security 10 for Linux Mail Server. Администратору стоит сверить номер сборки на своём сервере, чтобы не пропустить нужный пакет. Проблема в самом Redis известна с января 2024 года. Разработчики закрыли её в версиях 7.0.15 и 7.2.4. Уязвимыми оставались сборки с 7.0.9 по 7.0.15 и с 7.2.0 по 7.2.4. Следовательно, у части заказчиков на периметре годами работал компонент с известной уязвимостью.
Исправление вышло в Kaspersky Secure Mail Gateway 3.1. Новая версия повторяет функциональность предыдущей, поэтому переносить настройки и переписывать правила фильтрации не придётся. Однако дистрибутив не выложили в открытый доступ. Его выдают через службу поддержки Kaspersky по запросу. Компаниям стоит проверить, какая сборка работает на их почтовом сервере, и запланировать переход.
Пока обновление не установлено, снизить риск помогают обычные меры. Шлюз не должен быть открыт в интернет напрямую сверх необходимого. Административный доступ к нему стоит ограничить отдельным сегментом. Кроме того, журналы продукта полезно просматривать на предмет аварийных завершений и необычных вложений. Если вложения от неизвестных отправителей проверяет внешний сервис, это снимет часть нагрузки со шлюза. Заодно имеет смысл сверить, не осталось ли в инфраструктуре других продуктов с той же версией Redis ниже 7.0.15 или 7.2.4.
Уязвимость устранили в самом Redis в начале 2024 года, однако в составе сторонних продуктов она способна жить годами. Производители почтовых шлюзов, систем резервного копирования и аналитики регулярно встраивают чужие библиотеки и базы данных. Следят за их обновлениями далеко не всегда. Для заказчика это означает простую вещь. Безопасность купленного продукта зависит не только от вендора. Она зависит и от того, насколько быстро он тянет свежие версии зависимостей. Зато проверить состав зависимостей помогает перечень компонентов программного обеспечения, который всё чаще требуют при закупке. Без него заказчик узнаёт о чужой библиотеке внутри продукта только из бюллетеня вендора. Регулярная инвентаризация компонентов и контроль за выпуском исправлений снижают этот риск сильнее, чем любой внешний сканер.
Ссылки
- https://www.cve.org/CVERecord?id=CVE-2023-41056
- https://support.kaspersky.com/vulnerability/list-of-advisories/12430#170926
