GH Actions - Cache Poisoning
For further details check the original post https://scribesecurity.com/blog/github-cache-poisoning/
Cache Poisoning
Git action action/cache는 지속적 통합(CI) 프로세스에서 캐싱 메커니즘을 도입하며, 두 가지 중요한 단계로 구성됩니다:
Run Action: 이 단계에서는 CI 실행 중에 캐시된 데이터를 검색하고 가져옵니다. 검색은 고유한 캐시 키를 사용하여 두 가지 결과를 생성합니다:
Cache-hit: 요청된 데이터가 캐시에서 발견되어 즉시 사용을 위해 가져옵니다.
Cache-miss: 캐시에서 일치하는 데이터를 찾을 수 없어 필요한 파일과 디렉토리를 새로 다운로드합니다. 이는 처음 요청하는 것과 유사합니다.
Post Workflow Action: 이 단계는 CI 워크플로 후에 데이터를 캐시하는 데 전념합니다. 특히, 실행 작업 중에 캐시 미스가 발생하면 지정된 디렉토리의 현재 상태가 제공된 키를 사용하여 캐시됩니다. 이 과정은 자동화되어 있으며 명시적인 호출이 필요하지 않습니다.
Security Measures: Cache Isolation and Access Restrictions
보안을 유지하고 캐시 격리를 보장하기 위해 접근 제한이 시행되어 서로 다른 브랜치 간의 논리적 분리를 생성합니다. 예를 들어, Feature-A 브랜치(기본 브랜치에서 파생된)의 캐시는 Feature-B 브랜치(또한 기본 브랜치에서 파생된)의 풀 리퀘스트에서 접근할 수 없습니다.
캐시 작업은 특정 검색 순서를 따릅니다:
먼저 워크플로 실행과 동일한 브랜치 내에서 캐시 히트를 찾습니다.
실패할 경우, 부모 브랜치 및 기타 업스트림 브랜치로 검색을 확장합니다.
중요하게도, 캐시 접근은 브랜치 범위로 제한되며 특정 브랜치의 모든 워크플로 및 실행에 걸쳐 확장됩니다. 또한, GitHub는 캐시 항목이 생성된 후 읽기 전용 정책을 시행하여 수정할 수 없도록 합니다.
Real-World Implication: From Low to High-Permission Workflow Attack
일반적인 CI 시나리오는 공격자가 캐시 오염을 이용하여 낮은 권한의 워크플로에서 높은 권한의 워크플로로 권한을 상승시킬 수 있는 방법을 보여줍니다:
Unit-test 워크플로는 단위 테스트 및 코드 커버리지 도구를 실행하는 책임이 있으며, 손상되었거나 취약한 도구를 사용할 것으로 가정합니다. 이 워크플로는 action/cache Git 작업을 사용하여 캐시를 모든 워크플로에서 접근할 수 있도록 합니다.
Release 워크플로는 애플리케이션 아티팩트를 빌드하고 배포하는 책임이 있으며, Golang 종속성을 캐싱하여 작업을 최적화합니다.
이 시나리오에서 단위 테스트 워크플로는 합법적인 Golang 로깅 라이브러리(`go
Last updated
