XSS в колонках Roundcube: как закрыть CVE-2024-37384

CVE-2024-37384 — XSS при обработке колонок списка писем в Roundcube. Исправление вышло в версиях 1.5.7 и 1.6.7, но сегодня я выбираю актуальный поддерживаемый релиз или пакет с подтверждённым исправлением. Ниже — проверка установки, план обновления и критерии результата без обещаний, что любое письмо немедленно взломает сервер.

Что именно ломается в колонках Roundcube

Я начинаю с точного описания: CVE-2024-37384 связана с обработкой колонок списка писем из пользовательских настроек Roundcube. Разработчики сообщили об исправлении 19 мая 2024 года. Речь о межсайтовом скриптинге, то есть выполнении нежелательного сценария в браузере в контексте веб-приложения. Это основание обновить веб-почту и проверить её установку. Заявлять по одному номеру CVE об уже украденной переписке нельзя. При аудите информационной безопасности я отдельно фиксирую наличие ошибки и отдельно — признаки её использования.

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

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

Доступность веб-почты из интернета учитываю при выборе срочности работ, но не умножаю риск на выдуманное число. Внутренняя установка тоже нуждается в исправлении. Для оценки я смотрю, какие данные доступны сотрудникам, есть ли доступные посторонним учётные записи, кто отвечает за обновления и замечает ли команда подозрительные действия. Наличие уязвимой версии ещё не означает критический инцидент. Зато отсутствие владельца обновлений вполне объясняет, почему ошибка остаётся годами. Фраза «у нас всё закрыто фаерволом» хороша только вместе с перечнем того, что именно закрыто. Иначе это оберег с сетевым интерфейсом.

• Проблема находится в обработке колонок списка писем.
• Исправление нужно подтверждать для реально работающей установки.
• Наличие CVE и факт компрометации проверяют отдельно.

Как я разобрал бы ситуацию в «Тест-профи»

Возьму условный центр диагностики «Тест-профи» в Москве: 49 рабочих мест, собственная почта, Roundcube 1.5.5. Это учебный разбор с заданными условиями, а не сообщение о реальной утечке. Версия здесь — исходное условие примера. Я сначала выяснил бы способ установки: архив, пакет или компонент, добавленный к почтовой платформе. Для исходного релиза 1.5.5 исправление CVE-2024-37384 ещё не выпущено; для пакета с таким базовым номером потребовалась бы проверка перенесённых исправлений. До этого я не стал бы записывать в акт ни подтверждённую защищённость, ни состоявшийся взлом. Номер версии помогает задать вопрос, но не заменяет ответ.

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

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

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

• Исходные условия примера: 49 рабочих мест, Roundcube 1.5.5.
• Перед выбором пакета — проверка источника установки и исправлений.
• Перед работами — пробное обновление и условия отката.
• После работ — приёмка функций и фиксация версии.

Как проверить версию и не пропустить бэкпорт

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

Если Roundcube поставлен пакетами Debian или Ubuntu, я начинаю с запроса к базе пакетов:

dpkg-query --show 'roundcube*'

Команда показывает имена и версии совпавших пакетов. Её результат относится к пакетной базе той системы, где выполнен запрос. Пустая выдача не доказывает отсутствие Roundcube: приложение могли развернуть из архива или внутри контейнера. В системе с RPM можно получить список зарегистрированных пакетов командой rpm -qa и найти относящиеся к Roundcube записи. Затем я сопоставляю их с работающим экземпляром, а не объявляю победу по первому похожему имени. Эти команды только читают сведения о пакетах и ничего не обновляют.

Для установки из архива я проверяю обозначение релиза в её файлах и происхождение самого архива. В дереве Roundcube 1.6 номер задаётся константой RCMAIL_VERSION в program/include/iniset.php; путь здесь указан относительно корня приложения. Для другой ветки сверяю структуру её релиза. Универсальный файл VERSION обещать нельзя. И даже найденная константа не доказывает полноту обновления: после неудачного копирования часть файлов может остаться старой. Я сравниваю состав развёрнутой копии с выбранным дистрибутивом и учитываю локальные изменения. Если происхождение файлов неизвестно, сначала восстанавливаю понятную цепочку поставки, иначе следующая проверка снова упрётся в догадки.

Для исходных релизов границы исправления этой XSS такие: в ветке 1.5 — версия 1.5.7, в ветке 1.6 — 1.6.7. Дистрибутив может перенести исправление в пакет с меньшим базовым номером. Например, Debian Security Tracker показывает исправленные пакеты Roundcube на базе 1.6.5. Поэтому я сверяю полный номер пакета и статус конкретной CVE у поставщика. Эти исторические версии не служат сегодняшней рекомендацией: цель работ — актуальный поддерживаемый выпуск с нужными исправлениями. В карточке проверки я сохраняю источник этого вывода и дату проверки, чтобы следующий администратор видел основание решения, а не только отметку «обновлено».

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

Как обновить Roundcube с понятным откатом

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

Дальше я читаю инструкцию обновления именно выбранного релиза и проверяю требования к PHP, базе и расширениям. Для пакетов использую порядок поставщика дистрибутива; файлы из архива поверх пакетной установки не накладываю. Для ручной установки у Roundcube предусмотрен bin/installto.sh: его запускают из распакованного нового релиза с указанием существующего каталога приложения. Он переносит файлы и вызывает процедуру обновления. При ручном выполнении отдельных шагов миграцией занимается bin/update.sh согласно инструкции релиза. Единый SQL-файл для всех установок я в план не включаю. Перед запуском также проверяю, что командная строка использует подходящее окружение PHP.

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

У добавленного к mailcow Roundcube свой порядок обслуживания. Официальная инструкция различает интегрированную установку и отдельный контейнер; обновление самой платформы нельзя считать доказательством обновления этого веб-клиента. Там же предусмотрены отдельные действия для расширений. В иной схеме действия будут отличаться, поэтому я сначала устанавливаю способ развёртывания, а уже потом выбираю команды. Разницу между клиентами разбираю в материале Roundcube вместо SOGo. На выходе сохраняю журнал обновления, новую версию и проверенную копию исходного состояния. Если менялась схема базы, возврат старых файлов без согласованного восстановления данных не считаю готовым откатом.

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

Что делать до обновления и при чём здесь RCE

Если обновление откладывается, я назначаю ответственного, срок следующей проверки и временно сокращаю доступ к уязвимой веб-почте там, где это допустимо для работы. Иногда обоснованно приостановить именно этот интерфейс и оставить проверенные способы доступа к ящикам. Конкретное решение зависит от связей компонентов и потребностей сотрудников. Сетевые ограничения уменьшают число доступных точек входа, но не исправляют приложение. Защитный эффект такой меры я описываю вместе с её пределами. Руководителю нужен понятный остаточный риск и дата устранения причины, а не успокаивающая запись «приняты меры», после которой никто уже не открывает задачу.

Отключение пользовательского выбора колонок я не предлагаю как доказанную защиту от этой CVE. Исправление разработчика меняет проверку входных данных и построение списка, поэтому запрет сохранения предпочтений нельзя автоматически считать равноценным. Так же осторожно я отношусь к готовой политике Content Security Policy из случайной инструкции: её совместимость с конкретной версией интерфейса нужно проверять. Фильтрующие правила WAF могут быть дополнительным слоем, но универсального обещания блокировать все способы эксплуатации я не даю. Как выбирать такие меры по их реальным возможностям, объясняю в статье что защищает веб-приложение.

Отдельно держу CVE-2025-49113. В экспертной базе для неё указаны исправления в 1.6.11 и 1.5.10; это совпадает с выпуском разработчика от 1 июня 2025 года. Там описано удалённое выполнение кода после аутентификации через десериализацию PHP-объектов. Это другая ошибка с другими условиями, а не новое название XSS в колонках. Исполняемый код получает права соответствующего процесса; полный контроль над ОС нельзя обещать без дополнительных условий. Для планирования я учитываю возможность получения учётной записи и доступные процессу ресурсы. Одна и та же красная плашка в сканере не делает две разные уязвимости одинаковыми по механизму и последствиям.

При выборе срочности я сопоставляю подтверждённые условия ошибок с устройством системы. Проверяю доступность входа, права процесса, состояние PHP, расширений и источника обновлений. Заявления «WAF всё закроет» и «WAF здесь совсем бесполезен» одинаково требуют проверки на конкретных правилах и запросах. Я не устраиваю соревнование названий уязвимостей: задача — выбрать безопасный путь к поддерживаемой конфигурации и не потерять управляемость почты по дороге. Временные исключения записываю с владельцем и сроком пересмотра. Иначе временная мера быстро становится постоянной, а потом получает почётное название «особенность нашей инфраструктуры».

• Сократить доступ, если это допустимо для работы.
• Записать срок обновления и ответственного.
• Проверять фильтрацию как дополнительную меру.
• Оценивать XSS и RCE по их собственным условиям.

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

Приёмку я начинаю с обычных действий сотрудника: вход, открытие списка писем, изменение отображения колонок, чтение и отправка тестового сообщения. Затем проверяю адресную книгу, вложения и используемые расширения. В инструкции интеграции с mailcow среди плагинов указан managesieve: если через него сотрудники управляют фильтрами, эту функцию тоже включаю в проверку. Открытая страница входа ещё не означает, что почта работает. Для условного центра «Тест-профи» я согласовал бы список действий с сотрудником регистратуры и ответственным за обслуживание: именно они подтвердят пригодность интерфейса для ежедневной работы. Наличие 49 рабочих мест не требует выдавать каждому роль испытателя.

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

Если появились основания подозревать эксплуатацию, я сохраняю доступные журналы приложения и веб-сервера, сопоставляю их с событиями входа и действиями учётных записей. Проверяю неизвестные правила пересылки, изменения настроек и сообщения, отправленные без ведома владельца. Отсутствие ошибок в журнале не доказывает отсутствия атаки: важно, какие события вообще записывались и за какой период данные сохранились. Решения о завершении сессий и замене учётных данных принимаю по обстоятельствам расследования. Обновление закрывает известную ошибку, но не отменяет уже выполненные действия. Этот пункт я обсуждаю до закрытия заявки, чтобы никто не спутал техническое восстановление с завершением разбора инцидента.

В конце я передаю владельцу почты короткий результат: какая установка проверена, полный номер релиза или пакета, основание считать CVE устранённой, результаты пользовательских проверок и место хранения копии. В календаре появляется следующая проверка обновлений с ответственным. Срок хранения комплекта отката согласую с требованиями к данным и резервированию. Для небольшой компании это посильный процесс: важны понятные обязанности и повторяемые действия, а не количество страниц отчёта. В условном кейсе я принял бы работу только после этих проверок и отдельно отметил бы незавершённые вопросы. Кнопка «обновить» запускает работу; доказательства результата позволяют её закончить.

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

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