GitHub Actions переводит кэш в режим только для чтения для ненадежных триггеров, закрывая опасную уязвимость

GitHub Actions переводит кэш в режим только для чтения для ненадежных триггеров, закрывая опасную уязвимость. Фото: из архива компании

Это нововведение реализует принцип минимальных привилегий и, что самое главное, предотвращает распространенные пути повышения привилегий через отравление кэша, когда злоумышленники могли внедрять вредоносный код в доверенные рабочие процессы, такие как push или schedule.

Ранее служба Actions выдавала токены кэша для чтения и записи для каждого события рабочего процесса, включая опасные триггеры, такие как pull_request_target, issue_comment и каскады запросов на слияние workflow_run, что позволяло внешнему субъекту через внедрение скриптов записывать данные в кэш ветки по умолчанию. Теперь GitHub выдает токен кэша только для чтения, когда инициирующее событие является ненадежным, то есть его может запустить кто-то кроме участников проекта, и контекст выполнения рабочего процесса с областью действия кэша определяется с помощью общего SHA-хеша ветки по умолчанию.

Наиболее распространенные триггеры рабочих процессов, которые записывают данные в кэш ветки по умолчанию, включая push, schedule, workflow_dispatch, repository_dispatch, delete, registry_package и page_build, а также любой триггер, использующий область действия, отличную от ветки по умолчанию, например pull_request и release, сохраняют полное кэширование на чтение и запись, так что легитимные сценарии не пострадают.

Однако это изменение приводит к регрессии кэширования для небольшого набора ненадежных рабочих процессов, которые записывают данные в кэш из контекста default-branch-SHA, и при ограничении записи actions/cache теперь просто логирует предупреждение в журнале выполнения, а задание продолжается без сохранения.

Чтобы сохранить преимущества кэширования в этих рабочих процессах, потребуется отдельный рабочий процесс, запускаемый событием с доступом к кэшу на чтение и запись, например, push, который будет выполнять сохранение кэша, позволяя последующим рабочим процессам с доступом только для чтения восстанавливать и использовать его.

Это обновление, которое будет применено как к github.com, так и к GitHub с использованием Data Residency, является прямым ответом на реальные атаки, включая нашумевший инцидент с компрометацией Ultralytics, где злоумышленники через pull_request_target отравили кэш pip и получили контроль над публикацией в PyPI, а также на многочисленные исследования, документирующие, как кэш может быть использован для эскалации привилегий.

Actions переводит кэш в режим только для чтения для ненадежных триггеров, закрывая опасную уязвимость. Фото: СС0

Это нововведение реализует принцип минимальных привилегий и, что самое главное, предотвращает распространенные пути повышения привилегий через отравление кэша, когда злоумышленники могли внедрять вредоносный код в доверенные рабочие процессы, такие как push или schedule.

Ранее служба Actions выдавала токены кэша для чтения и записи для каждого события рабочего процесса, включая опасные триггеры, такие как pull_request_target, issue_comment и каскады запросов на слияние workflow_run, что позволяло внешнему субъекту через внедрение скриптов записывать данные в кэш ветки по умолчанию. Теперь GitHub выдает токен кэша только для чтения, когда инициирующее событие является ненадежным, то есть его может запустить кто-то кроме участников проекта, и контекст выполнения рабочего процесса с областью действия кэша определяется с помощью общего SHA-хеша ветки по умолчанию.

Наиболее распространенные триггеры рабочих процессов, которые записывают данные в кэш ветки по умолчанию, включая push, schedule, workflow_dispatch, repository_dispatch, delete, registry_package и page_build, а также любой триггер, использующий область действия, отличную от ветки по умолчанию, например pull_request и release, сохраняют полное кэширование на чтение и запись, так что легитимные сценарии не пострадают.

Однако это изменение приводит к регрессии кэширования для небольшого набора ненадежных рабочих процессов, которые записывают данные в кэш из контекста default-branch-SHA, и при ограничении записи actions/cache теперь просто логирует предупреждение в журнале выполнения, а задание продолжается без сохранения.

Чтобы сохранить преимущества кэширования в этих рабочих процессах, потребуется отдельный рабочий процесс, запускаемый событием с доступом к кэшу на чтение и запись, например, push, который будет выполнять сохранение кэша, позволяя последующим рабочим процессам с доступом только для чтения восстанавливать и использовать его.

Это обновление, которое будет применено как к github.com, так и к GitHub с использованием Data Residency, является прямым ответом на реальные атаки, включая нашумевший инцидент с компрометацией Ultralytics, где злоумышленники через pull_request_target отравили кэш pip и получили контроль над публикацией в PyPI, а также на многочисленные исследования, документирующие, как кэш может быть использован для эскалации привилегий.