IBM раскрыла сведения о двух десятках с лишним уязвимостей в DataStage на Cloud Pak for Data. Проблемы затрагивают версию 5.4.0.0 - платформу, на которой компании собирают и выполняют конвейеры обработки данных. Часть ошибок позволяет атакующему с действующей учётной записью запускать команды на сервере, читать чужие учётные данные и вызывать отказ в обслуживании. Самая высокая оценка по шкале CVSS (методика расчёта опасности уязвимостей) достигает 9.9.
Детали уязвимостей
Cloud Pak for Data разворачивают в кластерах Kubernetes. DataStage занимает там место инструмента для интеграции данных: он забирает сведения из десятков источников, преобразует их и складывает в хранилища. Такие системы ставят рядом с корпоративными базами и учётными записями сервисов. Поэтому список уязвимостей касается прежде всего компаний, которые перенесли интеграционные сценарии в контейнеры: банков, ритейлеров, промышленных холдингов. Бюллетень опубликован 21 сентября 2026 года, сведений об эксплуатации в реальных атаках в нём нет.
Больше всего в списке ошибок, которые ведут к выполнению команд. Причина у них общая: продукт не очищает служебные символы в данных, попадающих в системные вызовы. Из-за этого атакующий подставляет свои команды вместо ожидаемых значений. У большинства таких уязвимостей оценка 8.8. Одна выделяется уровнем 9.9, и связана она с недостаточной проверкой прав. Злоумышленнику хватает самой обычной учётной записи. Векторы различаются. В одном случае опасные значения приходят через свойства коннектора, то есть компонента, который связывает DataStage с внешним источником данных. В другом - через переменные окружения.
Вторая крупная группа - обход каталогов. Так называют приём, при котором программа выходит за пределы папки, отведённой ей по правилам. Здесь оценки 9.6, 9.6, 8.8 и 7.1. Одна ошибка оборачивается отказом в обслуживании, другая - выполнением произвольного кода, третья - чтением файлов вне рабочего каталога. Отдельная уязвимость проявляется при распаковке архивов. Проверка путей внутри них неполная, поэтому файл можно записать в произвольное место файловой системы.
Ещё несколько проблем открывают доступ к данным. Одна ошибка с рейтингом 9.6 ведёт к утечке чувствительной информации. Другая с тем же баллом допускает подделку запроса на стороне сервера. Так называют класс атак SSRF: сервер формирует запрос к произвольному адресу по указанию злоумышленника. Внешние сущности XML (XXE, механизм подстановки парсеру ссылки на чужой файл) дают читать файлы на сервере, оценка - 7.7. Десериализация недоверенных данных приводит к выполнению кода, 8.8. Монтирование томов с секретами делает их доступными всем пользователям пространства имён Kubernetes, тоже 8.8.
Самой неприятной по последствиям выглядит уязвимость в обработке секретов. Конечная точка pull расшифровывает любые блоки данных общим для всего региона ключом, а потом шифрует их заново ключом, который задал вызывающий. Ключ не меняют, поэтому любой аутентифицированный пользователь восстанавливает пароли подключений, токены Git и ключи API других арендаторов региона. Формально нужны два условия, но одно из них продукт создаёт сам: шифротекст доступен по его же логике. Оценка - 7.7.
Ещё одна ошибка касается проверки сертификатов TLS (протокол шифрования сетевого трафика). Атакующий класса "человек посередине" подсовывает поддельный сертификат, перехватывает соединение и снимает заголовок Authorization с токеном IAM, системы управления доступом в облаке IBM. Такой токен даёт полный доступ к проектам, потокам и определениям конвейеров жертвы. Код работает на машине самого пользователя, поэтому злоумышленнику нужен перехватчик в сети, а не сосед по кластеру. Оценка - 7.4.
В бюллетень попали и ошибки в сторонних компонентах. Podman до версии 5.6.1 позволяет через команду kube play перезаписать файл на хосте. Условие - символическая ссылка на путь за пределами тома с Secret или ConfigMap. Содержимое файла атакующий при этом не контролирует, оценка - 8.1. В библиотеке rubyipmi, которую Red Hat Satellite использует при работе с контроллером управления платой, вредоносное имя пользователя приводит к выполнению кода, 8.8. В ветках Django 6.0, 5.2 и 4.2 до последних обновлений запрос с множеством одинаковых заголовков вызывает отказ в обслуживании, 7.5.
Исправление одно: обновить DataStage на Cloud Pak for Data до 5.4 patch 7 или более поздней версии. Компенсирующих мер IBM не предлагает, обходных путей тоже нет. Часть уязвимостей открывает доступ к учётным данным других арендаторов. После обновления разумно сменить пароли подключений, токены репозиториев и ключи API. Заодно стоит проверить журналы на предмет обращений к чужим проектам.
Набор уязвимостей в DataStage повторяет картину, знакомую по другим платформам для работы с данными. Проверка путей, экранирование аргументов команд и разграничение прав арендаторов остаются слабым местом продуктов, выросших из серверных приложений. В контейнеры такие системы переехали позже, а вместе с ними переехали и старые ошибки в коде. Пока вендор выпускает исправления крупными пакетами, администраторам имеет смысл держать эти системы в отдельном сегменте сети и сокращать круг сотрудников с правом запускать конвейеры.
Ссылки
