Краткое описание

get_resource(resource="artifact" | "asset", ...) загружает файл с предварительно подписанного S3 URL и, когда вызывающий код передаёт savePath / fileName, сохраняет его на локальный диск через:

В версиях <= 0.1.4 функция validate_write_path() делает лишь следующее:

1. Разрешает save_path с помощью os.path.realpath(os.path.expanduser(...)).
2. Отклоняет пути из короткого списка запрещённых каталогов (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd).
3. Удаляет компоненты каталога из file_name с помощью os.path.basename().

Она никогда не ограничивает вычисленный каталог какой-либо базовой/рабочей директорией, а BLOCKED_FILENAMES (.bashrc, .zshrc, authorized_keys, id_rsa, …) применяется только при чтении, но не при записи. Поэтому любой MCP-клиент этого сервера — включая агента, подвергнутого косвенной промпт-инъекции через недоверенное содержимое заданий/задач/сообщений, получаемое им через этот же инструмент, — может задать savePath как абсолютный путь, обход через ../.. или имя чувствительного dotfile-файла, и сервер запишет туда байты, контролируемые атакующим. Это примитив записи файла за пределами каталога, в котором, как полагает оператор, ограничены загрузки; в рекомендации отмечается, что это «может привести к локальному выполнению кода» (например, к перезаписи стартового файла оболочки).

В 0.1.5 это исправлено: добавлена явная базовая директория из списка разрешённых (_ALLOWED_WRITE_BASE, берётся из $AWS_TRANSFORM_MCP_WRITE_DIR или рабочего каталога сервера при запуске), в которую должен входить каждый вычисленный путь записи, а также BLOCKED_FILENAMES теперь применяется к итоговому вычисленному пути записи.

Полный diff, показывающий первопричину: vendor/0.1.4-vulnerable/file_validation.py против vendor/0.1.5-fixed/file_validation.py (оба взяты дословно из PyPI / GitHub, Apache-2.0).

Как выглядит реальная атака

MCP-клиент (Q Developer, Kiro, Claude и т.п., подключённый к этому серверу) выполняет вызов инструмента, например:

или из относительного sandbox-каталога:

Поскольку инструмент описывает ответы resource="task" как данные, которые агент должен прочитать и на которые должен отреагировать, а содержимое resource="messages" берётся из данных чата/заданий, участнику рабочего пространства (или скомпрометированному вышестоящему источнику заданий/сообщений) не нужно убеждать человека вводить это вручную — достаточно направить уже подключённого агента на вызов get_resource со злонамеренным savePath. Для демонстрации самой уязвимости не требуются реальные учётные данные AWS, поскольку ошибка целиком находится в локальной обработке путей — до и после загрузки из S3.

Запуск PoC

Без сторонних зависимостей, учётной записи AWS и сетевого доступа к AWS. Скрипт:

1. Включает настоящий, неизменённый file_validation.py из версий 0.1.4 и 0.1.5+ (см. vendor/).
2. Запускает одноразовый локальный HTTP-сервер, выступающий в роли предварительно подписанного S3 URL.
3. Повторно реализует download_s3_content() с точным потоком управления из оригинального tool_utils.py (httpx заменён на urllib из стандартной библиотеки — ноль зависимостей, та же логика) и использует её точно так же, как это делал бы get_resource.
4. Отправляет три вредоносные пары savePath/fileName — выход через абсолютный путь, относительный обход через ../.. и имя dotfile-файла, блокируемое только при чтении, — в уязвимый валидатор, а затем в исправленный.

Всё происходит внутри одноразового временного каталога, создаваемого mkdtemp(); ваш настоящий $HOME никогда не затрагивается. Пример вывода:

Устранение

Обновитесь до awslabs.aws-transform-mcp-server >= 0.1.5. Для старых версий не существует обходного решения на стороне сервера; рекомендация советует обновиться. Операторы, которые не могут обновиться немедленно, должны запускать сервер с рабочим каталогом (CWD), установленным на выделенный пустой каталог, и считать любой файл, в который сервер может записать, скомпрометированным.

Структура репозитория