Как я проверяю CVE-2024-23184 в Dovecot и обновляю почту

CVE-2024-23184 может перегружать процессор Dovecot при разборе множества адресных заголовков. Я проверяю исправление по полному номеру пакета и статусу своей ОС: сравнения с 2.3.21.1 недостаточно. Ниже — проверка Ubuntu и Debian, временные меры на входе и приёмка обновления без выдуманных настроек.

Что действительно делает CVE-2024-23184

У CVE-2024-23184 есть подтверждённое описание разработчика: большое количество адресных заголовков From, To, Cc, Bcc и других делает разбор письма чрезмерно затратным для CPU. Специально подготовленное сообщение извне может расходовать ресурсы и привести к перебоям. Когда я проверяю безопасность корпоративной почты, сначала выясняю, какой компонент принимает письмо, как оно попадает в хранилище и где возникает нагрузка. Эта последовательность определяет место исправления и временного ограничения.

Я разделяю число строк адресных заголовков, число адресов внутри поля и число получателей доставки. В описании разработчика речь именно о множестве адресных заголовков. Универсального порога в несколько тысяч получателей там нет. Поле Bcc также нельзя автоматически считать сохранённым списком всех скрытых адресатов: конкретный почтовый тракт может удалить его до передачи дальше. Для проверки мне нужен исходный вид сообщения на исследуемом этапе, иначе легко обвинить заголовок, которого Dovecot вообще не видел.

В экспертной базе и бюллетене разработчика для этой CVE указаны 5,0 балла и средняя серьёзность. Учитываю эту оценку вместе с возможными перебоями, без обещаний мгновенно положить любой сервер. На последствия влияют доступные ресурсы, нагрузка и обработка сообщения. Автоматическое переполнение памяти, кражу писем или выполнение команд это описание не подтверждает. Я убираю такие выводы из диагноза до появления отдельных доказательств. Цифра загрузки процессора сама по себе уголовное дело не раскрывает.

Первое исправление ветки 2.3 появилось в 2.3.21.1. Это историческая граница исправления, а выбор сегодняшнего пакета зависит от поддерживаемой поставки. В дистрибутиве изменение могут перенести в более раннюю базовую версию. Поэтому я сохраняю короткую формулу проверки: конкретная ОС, происхождение установленного пакета, статус этой CVE и полная версия исправления. Общий разбор почтовых уязвимостей помогает составить перечень компонентов, а здесь мы проверяем именно исправление адресного парсера Dovecot.

Какие пакеты Ubuntu и Debian содержат исправление

В Ubuntu я открываю карточку именно CVE-2024-23184 и читаю строку своего выпуска. Для 22.04 LTS jammy указан пакет с исправлением 1:2.3.16+dfsg1-3ubuntu2.4, для 24.04 LTS noble — 1:2.3.21+dfsg1-2ubuntu6. Эти номера подтверждают полезный факт из базы: исправленный пакет вполне может показывать базовую версию ниже 2.3.21.1. Суффиксы и начальную часть 1: сохраняю целиком. Пакет от стороннего поставщика требует его собственного подтверждения: таблица Ubuntu на чужую сборку автоматически не распространяется.

Со штатным пакетом Ubuntu 20.04 есть показательная ловушка. В актуальной карточке этой CVE стоит Not affected: затронутый код, согласно примечанию, появился в Dovecot 2.3.10. Старый USN-7013-1 объединяет несколько исправлений и перечисляет также 20.04. По одному этому бюллетеню нельзя объявлять выпуск уязвимым именно к CVE-2024-23184. Я фиксирую расхождение и использую отдельную карточку с её примечаниями. Для самостоятельно установленного нового Dovecot статус штатной поставки уже не решает вопрос.

В Debian я смотрю таблицу Fixed Version, чтобы определить первую исправленную сборку в нужном выпуске. Там указаны следующие границы. Это ориентиры для проверки конкретной CVE; при обновлении я выбираю актуальный пакет из поддерживаемого репозитория своего выпуска, поскольку после первого исправления могли выходить другие важные обновления. | Выпуск Debian | Первая исправленная версия | |---|---| | 11 bullseye | 1:2.3.13+dfsg1-2+deb11u2 | | 12 bookworm | 1:2.3.19.1+dfsg1-2.1+deb12u1 | Номер из соседней строки для другой ОС сравнивать с установленным пакетом бессмысленно.

Запись о CVE в трекере ещё не означает выпущенное исправление. Я различаю Fixed, Not affected и статусы, требующие уточнения; отсутствие карточки тоже оставляет вопрос открытым. Если поставка больше не получает нужные обновления, выясняю доступный канал поддержки и планирую переход на поддерживаемую систему. Самостоятельная сборка добавляет ответственность за дальнейшие патчи и совместимость модулей. Она требует отдельного решения, а не становится обязательным ответом на пустую строку в поиске. Номер версии без происхождения — почти гадание, только моноширинным шрифтом.

• Определить выпуск ОС и поставщика пакета.
• Сохранить полную установленную версию и ссылку на статус CVE.
• Проверить границу исправления именно для своего выпуска.
• Выбрать актуальную поддерживаемую сборку из подходящего репозитория.

Как я проверяю версию и готовлю обновление

Сначала определяю, где запущен обслуживающий пользователей экземпляр Dovecot. Пакет на узле и программа внутри контейнера могут иметь разное происхождение. Команды ниже предназначены для обычной установки пакетами Debian или Ubuntu; для контейнерной поставки проверяю сам работающий образ по инструкции её разработчика. Утилита dovecot --version корректно сообщает версию программы. Дополнительно мне нужна запись пакетного менеджера, чтобы увидеть ревизию дистрибутива и состояние установки. Баннер старательно сообщает ровно то, что умеет, — остальное мы должны проверить сами.

Для первичного осмотра использую такой набор. Шаблон имени и формат вывода заключены в одинарные кавычки, чтобы оболочка передала их dpkg-query буквально. В выводе ищу установленные компоненты со статусом installed, а не просто совпадения названий.

dovecot --version
dpkg-query -W -f='${binary:Package} ${Version} ${db:Status-Status}\n' 'dovecot*'
apt-cache policy dovecot-core

Последняя команда показывает доступные версии и приоритеты источников. Это помогает заметить сторонний репозиторий или ситуацию, когда ожидаемый пакет вообще недоступен. Текстовый вывод с датой проверки удобнее сохранять в журнале работ: его можно сравнить после обновления.

Затем обновляю индексы и рассматриваю план пакетного менеджера. Здесь показан пример для уже установленных dovecot-core и dovecot-imapd; список заменяю фактически установленными компонентами, включая используемые модули. Проверку выполняю с административными правами, чтобы симуляция видела ту же конфигурацию, что и установка.

sudo apt-get update
apt-cache policy dovecot-core
sudo apt-get --simulate install --only-upgrade dovecot-core dovecot-imapd

Симуляция установки не меняет пакеты. Обновление индексов перед ней необходимо для актуального выбора кандидата. Если загрузка индексов завершилась ошибками, сначала разбираю их: старые списки способны создать очень убедительную иллюзию отсутствия обновлений.

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

Действующую конфигурацию смотрю через dovecot -n: по руководству команда выводит настройки, отличающиеся от значений по умолчанию. Этот вывод помогает сопоставить конфигурацию до и после работ, но сам по себе исправление CVE не доказывает. Сохраняю его с ограниченным доступом и проверяю перед передачей кому-либо. После установки обеспечиваю предусмотренный поставкой перезапуск, чтобы обслуживающие процессы использовали обновлённый код. Если обновление требует перехода на 2.4, отдельно готовлю миграцию конфигурации Dovecot, поскольку смена ветки требует собственной проверки.

Какие временные ограничения имеют смысл на MTA

Экспертная база со ссылкой на разработчика указывает конкретное место временной меры: ограничения адресных заголовков в MTA перед Dovecot. Я проверяю весь маршрут входящей почты и выбираю поддерживаемый фильтр, который умеет оценивать нужные заголовки до передачи дальше. Действие при превышении порога, журналирование и допустимые исключения задаю осознанно. Универсальной строки для любого почтового сервера здесь нет. Настройку нужно проверять на своей версии и реальных деловых письмах, иначе защитная мера сама станет причиной потери корреспонденции.

В Postfix параметр smtpd_recipient_limit относится к получателям SMTP-запроса доставки. Адресные заголовки находятся внутри сообщения и не обязаны совпадать с этим списком. Письмо одному получателю способно содержать множество таких полей, поэтому уменьшение числа получателей не подтверждает защиту от CVE-2024-23184. Параметр recipient_delimiter задаёт разделители расширения адреса, например метки после плюса; к ограничению количества адресатов он не относится. Совет лечить эту CVE через recipient_delimiter отправляю в корзину до применения. У знака плюс и так достаточно обязанностей.

В документации Postfix есть header_size_limit и header_address_token_limit. Первый ограничивает память для хранения заголовка, второй — число адресных элементов в адресном заголовке; превышающая предел информация отбрасывается обработчиком cleanup. Я учитываю это поведение: данные могут измениться, а автоматический отказ отправителю из такого описания не следует. Эти параметры также не дают универсальной гарантии ограничения суммарного числа отдельных адресных полей. Для осмысленной политики нужно понимать, что именно считает выбранный фильтр и какое сообщение затем получает Dovecot.

Лимит общего размера сообщения решает свою задачу; его отдельно разбирает статья про ограничение размера письма Postfix. Я не выдаю произвольные 10 МБ или сто получателей за проверенное средство против этой CVE. Также убираю совет добавлять mail_max_size в случайные файлы Dovecot: подтверждённого рецепта с такой директивой для описанной установки нет. Пока временная политика проходит проверку, план исправления пакета остаётся обязательным. Временная мера должна иметь владельца, запись о проверке и условие отмены, иначе она быстро превращается в вечный памятник аварии.

• Найти MTA, который передаёт входящие письма в Dovecot.
• Выбрать проверку адресных заголовков, соответствующую своей поставке.
• Проверить действия фильтра на обычных и превышающих лимит письмах на стенде.
• Зафиксировать ограничения временной меры и продолжить установку исправления.

Условный разбор: «Ремонт рядом», 9 рабочих мест

Для сервисного центра «Ремонт рядом» в Москве я разбираю учебную ситуацию: девять рабочих мест, почта на Ubuntu 22.04 LTS, пользователи жалуются на задержки открытия папок. Это условный пример порядка работ, без заявления о реальном инциденте. Версии в нём взяты из официальной карточки Ubuntu, а сроки служат планом обслуживания. Первые 30 минут отвожу на сбор сведений: работающий экземпляр, пакет, время жалоб, нагрузка, доставка и сообщения журналов. Наличие задержек ещё оставляет несколько возможных причин.

Допустим, проверка показывает сборку, выпущенную до исправления, и доступный пакет не ниже 1:2.3.16+dfsg1-3ubuntu2.4 из доверенного репозитория этого выпуска. Такой результат даёт основание установить обновление. Отдельно выясняю причину нагрузки: какие процессы заняты, с какими действиями пользователей совпадает симптом и какие сообщения тогда обрабатываются. Я не придумываю запись в журнале, число адресатов и доказанную атаку ради красивого сюжета. Если приходится отложить обработку подозрительного письма, сохраняю его для анализа и документирую действие.

На подготовку и пробное обновление в этом плане выделяю ещё 60 минут, на окно обслуживания — 30 минут. Итого два часа запланированных работ; перерыв доступа может занимать только часть окна. Эти значения не обещают восстановить любую почту за два часа: размер копии, состояние хранения и зависимости способны увеличить подготовку. После пробного прохода уточняю срок. Для этого полезен тестовый стенд переноса почты: при обновлении я использую тот же принцип предварительной проверки доставки и доступа к ящику.

Плановый итог формулирую проверяемо: установлен подтверждённый пакет, процессы перезапущены, тестовые входящие и исходящие письма прошли, папки открываются, контрольное наблюдение не показывает прежнего симптома. Факт эксплуатации CVE записываю только при подтверждении причины. Если после обновления задержки остались, продолжаю диагностику хранения, поиска и других нагрузок. Закрытая уязвимость и устранённая жалоба получают отдельные отметки в отчёте. Галочка об обновлении очень любит притворяться всей выполненной работой.

Что проверяю после установки и отдаю заказчику

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

В контрольном ящике проверяю приём внешнего письма, отправку, открытие папок, чтение и поиск обычной корреспонденции. Согласованный период наблюдения выбираю так, чтобы увидеть привычную рабочую нагрузку. По CPU смотрю не только общий процент, но и занятые процессы; по почте — задержки и ошибки доставки. График должен показывать, вернулся ли сервис к обычному состоянию. Опасные сообщения с искусственной перегрузкой оставляю для изолированного стенда: эксплуатационный тест на рабочей почте требует отдельного решения и подготовленного восстановления.

Высокий CPU — повод сопоставить события, а не готовая подпись CVE. Индексация, поиск, дисковая задержка и другая работа могут дать похожую жалобу. Перезапуск способен временно изменить симптом, но письмо может остаться в ящике или очереди и снова попасть в обработку. Блокировка адреса отправителя, fail2ban или ограничение входа по IMAP не заменяют исправления парсера; входящая доставка проходит своим маршрутом. При продолжающихся перебоях я изолирую подтверждённый источник нагрузки с сохранением материала для анализа, затем проверяю восстановление сервиса.

Автоматические обновления тоже проверяю по результату: какие пакеты установлены, когда была успешная загрузка индексов и нет ли ошибок источников. Сам факт запущенного механизма обновлений не объясняет состояние работающего кода. В отчёте оставляю открытые вопросы отдельно от выполненных работ: неподдерживаемую поставку, непроверенный фильтр или сохраняющиеся задержки. Для небольшого офиса такая запись полезнее обещания найти все уязвимости за день. Я отвечаю за конкретную проверку и понятный следующий шаг — именно это можно принять и повторить.

• Полная версия пакета и подтверждение исправления приложены к отчёту.
• Работающий экземпляр использует обновлённый код.
• Доставка и доступ к контрольному ящику проверены.
• Временные ограничения и оставшиеся задачи имеют ответственного.

Частые вопросы