Skip to content
KitploitKITPLOIT
ИнструментыБлог
Log in
Отправить
ИнструментыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

··Ленты·Контакты·Конфиденциальность·© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
Инструменты/GitHubGitHub/murataydemir/aws-sam-cli-vulnerabilities
Безопасность контейнеровАнализ уязвимостейБезопасность облачных средDevSecOpsБезопасность Цепочки ПоставокНеправильная Конфигурация
GitHubmurataydemir/aws-sam-cli-vulnerabilities

AWS-SAM-CLI-Vulnerabilities

Проблема с AWS SAM CLI (CVE-2025-3047, CVE-2025-3048)

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться
Репозиторий
151 год назадЕщё не проверено

Уязвимости AWS SAM CLI (CVE-2025-3047 и CVE-2025-3048)


В этом README представлен подробный анализ двух уязвимостей безопасности, обнаруженных в AWS Serverless Application Model CLI (AWS SAM CLI) – CVE-2025-3047 и CVE-2025-3048 – а также проблемы и исправления на уровне кода. Обе уязвимости связаны с некорректной обработкой символических ссылок (symlinks) во время процесса сборки с использованием контейнеров Docker. Каждый раздел ниже описывает один CVE с кратким обзором, затронутым кодом (со ссылками на исходный код SAM CLI), исправлением и тем, как оно решает проблему, а также рекомендациями по устранению.

Эти недостатки связаны с некорректной обработкой символических ссылок во время sam build --use-container. Обе проблемы затрагивают локальные среды разработки (они не влияют на развернутые сервисы или ресурсы AWS)​, но могут позволить несанкционированный доступ к файлам на хост-машине путем злоупотребления тем, как AWS SAM CLI обрабатывает символические ссылки. Настоятельно рекомендуется обновить AWS SAM CLI до исправленных версий (1.133.0+ для CVE-2025-3047 и 1.134.0+ для CVE-2025-3048)​.

CVE-2025-3047 – Обход пути через символические ссылки при сборке в контейнере

GHSA-px37-jpqx-97q9 – это уязвимость обхода пути в AWS SAM CLI <= v1.132.0, которая позволяла несанкционированный доступ к файлам на хост-машине во время sam build --use-container. При сборке серверного приложения внутри контейнера Docker SAM CLI по умолчанию следовал символическим ссылкам в проекте. Злоумышленник, разместивший вредоносную символическую ссылку в проекте (указывающую на конфиденциальный файл хоста), мог воспользоваться повышенными привилегиями контейнера Docker, чтобы смонтировать этот файл в контейнер и скопировать его в доступное внутри контейнера место. По сути, это означало, что привилегированные файлы хоста (вне каталога проекта) могли быть прочитаны и выкрадены через сборочный контейнер. Проблема была исправлена в v1.133.0. (Для сохранения обратной совместимости в легитимных случаях SAM CLI v1.133.0 ввел опциональный флаг --mount-symlinks для повторного включения старого поведения при необходимости​.)

Основная причина и затронутый компонент: Основная проблема заключается в том, как AWS SAM CLI монтирует каталоги проекта и их символические ссылки в контейнер Docker, используемый для сборки. В коде AWS SAM CLI (модуль samcli.local.docker.container) до исправления все символические ссылки верхнего уровня в каталоге проекта автоматически разрешались и монтировались в контейнер с теми же повышенными привилегиями, что и процесс контейнера. Контейнер по умолчанию работает от имени root, поэтому разрешение и монтирование символической ссылки, указывающей на конфиденциальный путь хоста, давало контейнеру доступ к этому файлу, который непривилегированный пользователь хоста обычно не имел. Уязвимый код недостаточно ограничивал, за какими символическими ссылками следовать/какие монтировать.

В частности, в функции, создающей тома Docker для сборки, SAM CLI безусловно обрабатывал символические ссылки как фактические файлы/каталоги для монтирования. Уязвимость находилась в логике оркестрации контейнеров SAM CLI, а именно в методе Container.create файла samcli/local/docker/container.py. В уязвимых версиях этот метод всегда пытался разрешить и смонтировать цели символических ссылок из проекта в контейнер Docker, независимо от контекста. Проблемный код показан ниже, из SAM CLI v1.132.0:

# samcli/local/docker/container.py (v1.132.0 - уязвимый фрагмент)
if self._host_dir:
    mount_mode = "rw,delegated" if self._mount_with_write else "ro,delegated"
    LOG.info("Mounting %s as %s:%s, inside runtime container", self._host_dir, self._working_dir, mount_mode)
_volumes = {
    self._host_dir: {
        "bind": self._working_dir,
        "mode": mount_mode,
    },
    **self._create_mapped_symlink_files(),  # Всегда разрешать и монтировать символические ссылки (уязвимо) 
}

В приведенном выше коде _create_mapped_symlink_files() сканирует символические ссылки в каталоге проекта и подготавливает их к монтированию. Поскольку это было включено безусловно, все символические ссылки (включая те, что указывают за пределы проекта) монтировались в контейнер​. (см. aws/aws-sam-cli#7865)

Недостаток здесь в том, что во время sam build --use-container SAM CLI рассматривает символические ссылки как файлы для монтирования в контейнер. Если символическая ссылка указывала, скажем, на /etc/shadow на хосте, контейнер Docker (который может работать с повышенными привилегиями) смонтировал бы этот файл. Это классический обход пути на основе символических ссылок, приводящий к повышению привилегий – файлы хоста, к которым у пользователя обычно нет доступа, могли быть прочитаны контейнером и затем оказаться в выводе сборки.

Исправление (исправленный код в v1.133.0): Исправление вводит понятие контекста сборки и отключает разрешение символических ссылок во время сборки в контейнере. В исправленной версии Container.create принимает дополнительный параметр, указывающий контекст (BUILD или INVOKE), и будет разрешать символические ссылки только если контекст – вызов (при локальном запуске функций), а не во время сборки. Ниже приведен исправленный код из исправленной версии:

# samcli/local/docker/container.py (v1.133.0+ - исправленный фрагмент)
if self._host_dir:
    mount_mode = "rw,delegated" if self._mount_with_write else "ro,delegated"
    LOG.info("Mounting %s as %s:%s, inside runtime container", self._host_dir, self._working_dir, mount_mode)
    mapped_symlinks = self._create_mapped_symlink_files() if self._resolve_symlinks(context) else {} 
_volumes = {
    self._host_dir: {
        "bind": self._working_dir,
        "mode": mount_mode,
    },
    **mapped_symlinks,  # Монтировать символические ссылки только если это явно разрешено контекстом (не при сборке) 
}

В исправленном коде _create_mapped_symlink_files() обернута проверкой контекста. Новое перечисление ContainerContext определяет контексты BUILD и INVOKE, и _resolve_symlinks(context) возвращает False для контекста сборки​. Таким образом, mapped_symlinks будет пустым словарем во время сборки, что означает по умолчанию никакие символические ссылки не монтируются в контейнер.

Ссылка на изменение кода: Исправление было реализовано в Pull Request#7865 («fix: Resolve symlinks on local invoke only») и выпущено в составе v1.133.0. Различие на GitHub показывает введение ContainerContext и условную логику монтирования. Отказ от монтирования целей символических ссылок во время сборки означает, что контейнер больше не получает доступа к файлам за пределами каталога проекта. (Если пользователь все же хочет разрешить символические ссылки на пути хоста, теперь он должен явно указать флаг --mount-symlinks​, который был добавлен после этого исправления.)

Скачать инструмент