Исходный контроллер — это оператор Kubernetes, специализирующийся на получении артефактов из внешних источников, таких как Git, OCI, репозитории Helm и S3-совместимые корзины. В версиях с 0.0.17 по 1.8.4 актер, имеющий возможность влиять на содержимое сегмента, на который ссылается ресурс Bucket, может заставить контроллер источника записывать полученные данные объекта в пути за пределами рабочего каталога для каждой сверки. Поверхность повреждения ограничена проверкой дайджеста контроллера-источника и нижестоящих контроллеров Flux: контроллер-источник проверяет сохраненные дайджесты артефактов во время согласования и перестраивает в случае расхождения; потребители (customize-controller, helm-controller) проверяют дайджест полученных артефактов и отклоняют несоответствия.
Эти проверки предотвращают попадание манипулируемого артефакта в кластер, но злоумышленник по-прежнему может записывать файлы в любом месте, где у модуля исходного контроллера есть разрешение на запись. Кроме того, пользователь с разрешением на создание или обновление ресурсов GitRepository может заставить контроллер источника проверять наличие путей за пределами клонированного репозитория. Поскольку результат отображается через состояние ресурса, это позволяет ограниченное перечисление путей к файлам в модуле контроллера.
Эта поверхность существует только в исходном контроллере версии 1.6.0 и более поздних версиях, где была введена функция разреженной проверки. Эта уязвимость была исправлена в исходном контроллере версии 1.8.5. В продукте нет обходного пути.
Пользователям следует перейти на исправленную версию. В качестве меры глубокой защиты поверхности разреженной проверки GitRepository можно развернуть ValidatingAdmissionPolicy (или сторонний механизм политики, такой как Kyverno или OPA Gatekeeper), чтобы отклонять ресурсы GitRepository, чьи записи .spec.sparseCheckout содержат `..` или сегменты абсолютного пути.
Показать оригинальное описание (EN)
The source-controller is a Kubernetes operator, specialised in artifacts acquisition from external sources such as Git, OCI, Helm repositories and S3-compatible buckets. In versions 0.0.17 through 1.8.4, an actor with the ability to influence the contents of a bucket referenced by a `Bucket` resource can cause source-controller to write fetched object data to paths outside the per-reconciliation working directory. The corruption surface is bounded by source-controller's own and downstream Flux controllers' digest verification: source-controller verifies stored artifact digests during reconciliation and rebuilds on divergence; consumers (kustomize-controller, helm-controller) verify the digest of fetched artifacts and reject mismatches. These checks prevent a manipulated artifact from reaching the cluster, but an attacker can still write files anywhere the source-controller pod has permission to write. Separately, a user with permission to create or update `GitRepository` resources can cause source-controller to test for the existence of paths outside the cloned repository. Because the result is exposed via the resource's status, this allows limited enumeration of file paths on the controller pod. This surface exists only on source-controller v1.6.0 and later, where the sparse-checkout feature was introduced. This vulnerability was fixed in source-controller v1.8.5. There is no in-product workaround. Users should upgrade to a patched version. As a defense-in-depth measure for the GitRepository sparse-checkout surface, a `ValidatingAdmissionPolicy` (or a third-party policy engine such as Kyverno or OPA Gatekeeper) can be deployed to reject `GitRepository` resources whose `.spec.sparseCheckout` entries contain `..` or absolute path segments.
Характеристики атаки
Последствия
Строка CVSS v4.0