Ветка Metabase 64 получила набор исправлений безопасности. Выпуск устраняет слабую проверку входных данных в интерфейсах программирования (API) и при компиляции запросов, а также правит проверки прав и выдачу метаданных. Затронуты открытая версия продукта и редакции Pro и Enterprise. Вендор называет это плановым усилением защиты, а не откликом на один конкретный дефект.
Проверки входных данных, права доступа и метаданные
Отдельного описания каждой уязвимости вендор не приводит. Из уведомления видно, где усилены проверки: значения в фильтрах, единицах дат, регулярных выражениях и при приведении типов проходят дополнительный контроль. Права проверяют строже для связанных моделей (сохранённых наборов данных), метрик и вопросов (сохранённых запросов). Отдельные правки касаются обработки сеансов при деактивации и повторной активации пользователей, содержимого корзины и конечных точек отдельных арендаторов. Из выгрузки настроек убрали секреты баз данных, а ограничения по доменам почты теперь проверяют при отправке уведомлений и рассылок.
Какое действие становится возможным без этих проверок, вендор не уточняет, поэтому тип атаки по уведомлению не восстановить. Выпуск он описывает как усиление защиты с сокращением поверхности атаки, то есть числа функций и данных, доступных без проверки. Отдельно вендор благодарит исследователей и команды, чьи отчёты помогли улучшить защиту продукта в этом и предыдущих выпусках.
Оценку CVSS (общей шкалы оценки опасности уязвимостей) вендор не публикует, в уведомлении указан только уровень Critical. Уязвимы сборки ветки 64 младше 0.64.3.4 в открытой версии и младше 1.64.3.4 в редакциях Pro и Enterprise. Исправление вышло в 0.64.3.4 и 1.64.3.4; номера различаются, потому что открытая версия и коммерческие редакции нумеруются по-разному. Тем, кто развернул Metabase на своих серверах, вендор советует перейти на эти сборки или более поздние. Выпуск относится к линии LTS (Long Term Support, длительная поддержка): ветку 64 будут сопровождать исправлениями дольше обычного.
Сведений об эксплуатации в реальных атаках в уведомлении нет. Публикация рекомендации означает, что детали исправлений доступны, но не то, что уязвимости уже применяют в атаках. Условия атаки вендор не описывает: не сказано, нужен ли доступ по сети или локально, требуются ли учётные данные и участие пользователя. Идентификатора CVE у проблемы нет, классификацию типов ошибок CWE вендор не приводит. Отслеживать исправления стоит по коду GHSA-v44v-x8x4-mvcw, а подробности искать в самом уведомлении и в списке изменений к выпуску.
Обходных мер для уже работающих установок вендор не приводит; предложенный путь один - обновление до исправленных сборок и сверка с чек-листом по безопасности. В выпуске появились и настройки, которые снижают риск: политики исходящих соединений для поддерживаемых подключений к хранилищам данных, вебхуков (автоматических уведомлений на внешний адрес), карт и провайдеров ИИ. В редакциях Pro и Enterprise администраторы могут сделать двухфакторную аутентификацию обязательной для входа по паролю и по протоколу LDAP (доступ к каталогу пользователей). Ключи подписи сеансов и шифрования доступны во всех редакциях, но вендор называет их необязательными: их включают вручную, если нужно защитить сеансы и чувствительные значения в базе приложения.
Практический эффект выпуска шире одной правки: меняются проверки прав, выдача метаданных и обработка сеансов. Какие из изменений касаются конкретной установки, видно по списку изменений и чек-листу, на которые ссылается вендор.
Ссылки
