CVE-2023-42115: проверяю EXTERNAL AUTH, пакет и сборку

CVE-2023-42115 затрагивает обработчик EXTERNAL AUTH в Exim: открытого SMTP-порта для вывода об уязвимости недостаточно. Я проверяю доступность этого механизма, установленный пакет и исправления поставщика. Ниже — точные исторические версии Debian, команды чтения версии и порядок обновления с проверкой доставки, без обещаний вылечить сервер по баннеру.

Когда CVE-2023-42115 действительно касается сервера

Я начинаю с условий эксплуатации. CVE-2023-42115 — ошибка записи за границами буфера в обработчике EXTERNAL AUTH Exim. Она допускает удалённое выполнение кода без предварительного успешного входа. Однако для этого должен быть доступен именно затронутый обработчик; наличия Exim или любого другого механизма AUTH недостаточно. В моей работе по защите корпоративной почты это отдельная проверка конфигурации, а не вывод из названия программы. Иначе легко потратить окно обслуживания на ложную тревогу и пропустить настоящий риск.

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

Сам механизм EXTERNAL использует сведения об идентичности, полученные за пределами обычного обмена логином и паролем SMTP. Например, конфигурация может опираться на клиентский сертификат. Поэтому обнаруженный в ответе сервера AUTH с другими механизмами ещё не доказывает доступность уязвимого кода. Важны сборка, действующая настройка и условия, при которых механизм предлагается конкретному соединению. Я сверяю эти части вместе: поддержка драйвера в бинарном файле и его использование сервером — разные вещи.

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

Какие версии исправлены: upstream и пакеты Debian

Здесь чаще всего ошибаются с номером пакета. Для исходного проекта Exim исправление этой CVE выпущено в 4.96.1; оно также есть в 4.97. Это историческая граница конкретного исправления. Я не предлагаю устанавливать эти старые релизы сегодня: для рабочего сервера выбираю поддерживаемый пакет с актуальными исправлениями от его поставщика. Номер исходного релиза и полная версия пакета дистрибутива решают разные задачи. Поставщик может перенести исправление в прежнюю ветку, сохранив её основной номер.

Для Debian Security Tracker даёт следующие исторические версии исходного пакета exim4, в которых закрыта CVE-2023-42115. По ним удобно разбирать старый отчёт сканера или журнал обновлений. Сравнивать версии нужно внутри соответствующего выпуска Debian, с учётом происхождения пакета. | Выпуск Debian | Первая исправленная версия в трекере | |---|---| | bullseye | 4.94.2-7+deb11u1 | | bookworm | 4.96-15+deb12u2 | | unstable, историческая запись | 4.97~RC1-2 | Я сохраняю суффиксы целиком: именно они различают сборки с одинаковой базовой версией.

Строки 4.94.2-7 и 4.96-15 без продолжения нельзя выдавать за универсальные исправленные версии. В Debian bookworm номер до и после обновления может начинаться одинаково, а наличие исправления различается суффиксом пакета. Запись 4.97_RC1-2 тоже неверно передаёт версию Debian: в трекере используется тильда. Это не косметика для отчёта. Неполная строка мешает сопоставить установленный пакет с уведомлением безопасности и создаёт ложное подтверждение, что работа закончена. Суффикс отрезали — уверенность оставили. Очень удобная бухгалтерия безопасности.

Для buster трекер отмечает отсутствие затронутости этой CVE: поддержка внешнего аутентификатора появилась позже. Из этого не следует, что любая старая версия Exim безопасна или что устаревший выпуск системы годится для дальнейшей эксплуатации. Это узкий вывод об одной ошибке. Для пакетов другого дистрибутива я открываю уведомление его поставщика; Debian-суффиксы туда не переношу. Общую проверку почтовой безопасности дополняю этой проверкой сборки и EXTERNAL, чтобы не подменять один вопрос другим.

Как получить версию работающего Exim и его пакета

Я собираю сведения на самом узле, где обслуживаются SMTP-соединения. Для бинарного файла Exim ключ версии — -bV, с заглавной V. В Debian программа называется exim4; в других установках встречается exim. Примеры ниже — альтернативы для соответствующего имени, а не обязательная последовательность из двух запусков. Выполнять их нужно в окружении действующего почтового сервера, с правами, достаточными для чтения его конфигурации.

# Debian
exim4 -bV

# Установка с именем exim
exim -bV

Ключ -v включает подробный вывод о действиях Exim; это не штатный ключ получения версии. У -bV другая задача: показать номер программы, сведения о сборке, включённые драйверы и используемый файл конфигурации. Здесь я также проверяю, тот ли экземпляр программы вызвал. На сервере могут остаться ручная установка и пакетная копия, а в контейнере — собственный бинарный файл. Вывод случайной команды из окружения администратора не доказывает, что сетевые соединения обслуживает именно она. Баннер может представиться кем угодно. Паспорт пакета я читаю на самом узле.

На Debian полную строку версии пакетов получаю отдельно. Команда ниже читает базу пакетов и ничего не обновляет. Кавычки сохраняют шаблон для dpkg-query, чтобы оболочка не подставила вместо него имена местных файлов.

dpkg-query -W 'exim4*'

Я нахожу пакет, поставляющий действующий демон, а не ограничиваюсь наличием метапакета exim4. В зависимости от установки это может быть exim4-daemon-light или exim4-daemon-heavy. Сведения об установленной версии сопоставляю с источником пакета и записью нужного выпуска в трекере.

Полезная дополнительная проверка: -bV читает конфигурацию и выполняет её статическую проверку синтаксиса. Но выражения, зависящие от данных соединения или сообщения, так полностью не проверяются. Успешный запуск не заменяет испытания доставки и аутентификации. Кроме того, список встроенных драйверов показывает возможности сборки, а не список реально включённых механизмов. Я использую этот вывод как исходные данные для следующего шага, а не как готовую справку «сервер защищён». Галочка красивая. Доказательств пока нет.

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

Как проверить EXTERNAL и временно ограничить риск

После версии я читаю действующую конфигурацию аутентификаторов. В официальном примере Exim внешний механизм задают строки driver = external и public_name = EXTERNAL. Но найденный фрагмент в старом резервном файле ещё ничего не говорит о текущей службе. Проверяю, входит ли он в используемую конфигурацию, включена ли серверная часть и какие условия управляют доступностью механизма. Настройки шаблона и итогового файла могут различаться, особенно если конфигурацию собирает система управления сервером. Править нужно источник действующих настроек, иначе очередная пересборка вернёт прежнее поведение.

Снаружи список предложенных механизмов виден в ответе на EHLO. При этом конфигурация может менять список в зависимости от клиента и состояния шифрования; поэтому единственного наблюдения до STARTTLS недостаточно. Я сопоставляю ответ с настройками и проверяю штатные варианты подключения, которыми пользуются сотрудники и приложения. Отсутствие EXTERNAL в одном ответе — результат для этих условий, а не справка обо всех подключениях. Наличие EXTERNAL при этом показывает доступность механизма, но само по себе не доказывает отсутствие исправления в пакете.

Для CVE-2023-42115 разработчики Exim прямо предлагают временную меру: не предлагать EXTERNAL-аутентификацию. Если механизм не используется, отключаю его после проверки зависимостей; если используется, сначала выясняю, какие подключения потеряют доступ. Для этой ошибки не требуется без разбора отключать всю SMTP-аутентификацию или запрещать обычную входящую почту. Временную меру фиксирую вместе с причиной и условием отмены. Она снижает доступность проблемного обработчика, но не превращает старую сборку в исправленную. Отключить всё легко; потом обычно выясняется, что почта всё-таки была нужна.

Сетевые ограничения тоже оцениваю по фактическому доступу. Если соединение до уязвимой службы невозможно, атака по этому пути не проходит. Закрытие порта 25 снаружи действительно убирает этот путь, однако оставшиеся доступные слушатели и доверенные подключения нужно рассмотреть отдельно. Номер порта не исправляет код. Так же и включённый TLS не служит патчем для CVE-2023-42115: бюллетень Exim не связывает устранение этих ошибок с включением или выключением шифрования. Я сохраняю TLS и решаю вопрос с обработчиком и пакетом.

Условный разбор: «Лексика», 17 рабочих мест

Разберу учебную ситуацию: московское бюро переводов «Лексика», 17 рабочих мест. Это условный сценарий, а не отчёт о реальном обращении клиента. Допустим, сканер отметил старый Exim на почтовом узле Debian bookworm, а ответственный за обслуживание показывает успешное получение писем. Я разделяю вопросы: исправлен ли пакет, доступен ли EXTERNAL и работает ли доставка. Число рабочих мест помогает согласовать проверку с пользователями, но ничего не говорит о версии демона или количестве почтовых ящиков.

Допустим, в исходной карточке сервера записано только 4.96-15. Этого недостаточно: я получаю полную строку и сопоставляю её с исторической границей исправления bookworm — 4.96-15+deb12u2. Если установленный пакет содержит исправление, приложу подтверждение к отчёту сканера. Если нет, проверю доступность EXTERNAL и выберу актуальное обновление поставщика. При недоступном механизме запишу, что условия эксплуатации этой ошибки не подтверждены; при доступном — поставлю временное ограничение и обновление в приоритет. Историческая версия здесь служит точкой сравнения, а не целью установки сегодня.

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

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

Как обновить сервер и подтвердить результат

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

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

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

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

Наконец, отдельно смотрю признаки возможной компрометации: неожиданные изменения конфигурации, неизвестные задания и процессы, необычную исходящую почту и события аутентификации. Отсутствие записей не доказывает чистоту системы; отсутствие мониторинга тоже не доказывает взлом. При находках сохраняю данные для расследования и расширяю проверку, поскольку патч не удаляет уже внесённые изменения. Проверяя признаки компрометации почтового ящика, не забываю про сам узел. Работу закрываю отчётом и ответственным за следующие обновления. Календарная напоминалка патчи пока не устанавливает.

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