GH Actions - Cache Poisoning
자세한 내용은 원본 게시물 https://scribesecurity.com/blog/github-cache-poisoning/을 확인하세요.
캐시 독점
Git 액션 action/cache는 CI(Continuous Integration) 프로세스에서 캐싱 메커니즘을 도입하여 두 가지 중요한 단계를 포함합니다:
액션 실행: 이 단계에서는 CI 실행 중에 캐시된 데이터를 검색하고 검색에는 고유한 캐시 키가 사용됩니다. 이로 인해 두 가지 결과가 발생합니다:
캐시 히트: 요청한 데이터가 캐시에서 찾아지고 즉시 사용하기 위해 검색됩니다.
캐시 미스: 캐시에서 일치하는 데이터를 찾을 수 없으므로 필요한 파일과 디렉토리를 처음 요청하는 것과 유사하게 새로 다운로드합니다.
워크플로우 후 액션: 이 단계는 CI 워크플로우 이후에 데이터를 캐싱하는 데 사용됩니다. 특히, 실행 액션 중에 캐시 미스가 발생하는 경우 지정된 디렉토리의 현재 상태가 제공된 키를 사용하여 캐시됩니다. 이 프로세스는 자동화되며 명시적으로 호출할 필요가 없습니다.
보안 조치: 캐시 격리 및 액세스 제한
보안을 유지하고 캐시 격리를 보장하기 위해 액세스 제한이 적용되어 서로 다른 브랜치 간에 논리적인 분리가 이루어집니다. 예를 들어, 메인 브랜치를 기반으로 한 브랜치 Feature-A에 대한 캐시는 메인 브랜치를 기반으로 한 브랜치 Feature-B의 풀 리퀘스트에서 접근할 수 없습니다.
캐시 액션은 특정 검색 순서를 준수합니다:
먼저 워크플로우 실행과 동일한 브랜치 내에서 캐시 히트를 찾습니다.
실패한 경우 상위 브랜치 및 다른 상위 브랜치로 검색을 확장합니다.
중요한 점은 캐시 액세스가 브랜치 범위로 제한되어 특정 브랜치의 모든 워크플로우와 실행에 걸쳐 확장된다는 것입니다. 또한 GitHub는 캐시 항목이 생성된 후에는 읽기 전용 정책을 강제로 적용하여 수정을 금지합니다.
실제 시나리오: 낮은 권한 워크플로우 공격에서 높은 권한 워크플로우로의 승격
실제 CI 시나리오에서 공격자가 캐시 독점을 이용하여 낮은 권한 워크플로우에서 높은 권한 워크플로우로 권한을 승격할 수 있는 방법을 보여줍니다:
Unit-test 워크플로우는 단위 테스트와 코드 커버리지 도구를 실행하는 역할을 담당하며, 손상된 또는 취약한 도구를 사용한다고 가정합니다. 이 워크플로우는 action/cache Git 액션을 사용하여 캐시를 모든 워크플로우에서 접근할 수 있게 합니다.
Release 워크플로우는 애플리케이션 아티팩트를 빌드하고 릴리스하는 작업을 수행하며, Golang 종속성을 캐싱하여 작업을 최적화합니다.
이 시나리오에서 unit-test 워크플로우는 정상적인 Golang 로깅 라이브러리(`go
最終更新