Gemini CLI: 작업 공간 신뢰 및 도구 허용 목록 우회를 통한 원격 코드 실행
Gemini CLI(@google/gemini-cli) 및 run-gemini-cli GitHub Action은 특히 GitHub Actions와 같이 신뢰할 수 없는 환경에서 사용될 때 작업공간 신뢰 및 도구 허용 목록을 강화하기 위해 업데이트되고 있습니다. 이 업데이트는 비대화형(헤드리스) 환경이 폴더 신뢰를 처리하는 방법에 대한 주요 변경 사항을 도입하며, 이는 특정 조건에서 기존 CI/CD 워크플로에 영향을 미칠 수 있습니다.
헤드리스 모드의 폴더 신뢰
이전 버전에서는 CI 환경(헤드리스 모드)에서 실행되는 Gemini CLI가 구성 및 환경 변수를 로드할 목적으로 작업 공간 폴더를 자동으로 신뢰했습니다. Gemini CLI가 헤드리스 모드의 신뢰할 수 없는 폴더에서 실행되는 상황(예: 사용자가 제출한 끌어오기 요청을 검토하는 CI 워크플로)에서는 이는 잠재적으로 위험합니다. 신뢰할 수 없는 디렉터리 콘텐츠와 함께 사용하면 로컬 .gemini/ 디렉터리의 악성 환경 변수를 통해 원격 코드가 실행될 수 있습니다.
일관성과 사용자 제어를 보장하기 위해 최신 업데이트에서는 헤드리스 모드 동작을 대화형 모드에 맞춰 구성 파일(예: '.env')을 처리하기 전에 폴더를 명시적으로 신뢰하도록 요구합니다.
이 변경으로 인해 이전 자동 신뢰 동작을 사용하는 GitHub Actions 및 기타 자동화된 파이프라인은 명시적 신뢰 메커니즘을 사용하도록 업데이트될 때까지 작업 영역별 설정을 로드하지 못합니다.
--yolo 아래의 도구 허용 목록
이전 버전에서는 Gemini CLI가 --yolo 모드에서 실행되도록 구성되면 ~/.gemini/settings.json에 있는 모든 세분화된 도구 허용 목록을 무시했습니다(예: run_shell_command(echo)는 모든 명령을 허용합니다). 이는 Gemini CLI가 '--yolo'를 사용하여 신뢰할 수 없는 입력에서 실행되는 상황에서 잠재적으로 위험합니다(예: 엄격한 허용 목록을 권장하는 사용자가 제출한 GitHub 문제를 분류하는 CI 워크플로). 신뢰할 수 없는 콘텐츠와 'run_shell_command'를 허용하는 도구 허용 목록과 함께 사용하면 프롬프트 삽입을 통해 원격 코드가 실행될 수 있습니다.
'0.39.1' 버전에서 Gemini CLI 정책 엔진은 이제 '--yolo' 모드에서 도구 허용 목록을 평가합니다. 이는 신뢰할 수 없는 입력을 처리할 때 실행할 몇 가지 안전한 명령을 허용 목록에 추가하는 CI 워크플로에 유용합니다. 결과적으로 이전에 이 동작에 의존했던 일부 워크플로는 작업에 맞게 도구 허용 목록을 수정하지 않으면 자동으로 실패할 수 있습니다.
이러한 영향은 헤드리스 모드에서 Gemini CLI를 사용하는 워크플로로 제한됩니다. 폴더 신뢰 없이 헤드리스 모드에서 Gemini CLI를 사용하려면 폴더 신뢰를 올바르게 구성하기 위해 수동 검토가 필요합니다. 이는 모든 Gemini CLI GitHub 작업에 영향을 미칩니다. 사용자는 자신의 워크플로를 검토하고 다음 두 가지 접근 방식 중 하나를 취해야 합니다.
1. 워크플로가 신뢰할 수 있는 입력(예: 신뢰할 수 있는 협력자의 PR 검토)에서 실행되는 경우 워크플로에서 GEMINI_TRUST_WORKSPACE: 'true'를 설정하세요.
2. 워크플로가 신뢰할 수 없는 입력에서 실행되는 경우 google-github-actions/run-gemini-cli의 지침을 검토하여 악성 콘텐츠에 대한 워크플로를 강화하고 환경 변수를 설정하세요.
폴더 신뢰 및 도구 허용 목록 완화는 @google/gemini-cli 버전 0.39.1 및 0.40.0-preview.3에서 사용할 수 있습니다. 기본적으로 run-gemini-cli GitHub Action은 gemini-cli의 최신 버전을 받아 실행합니다. 그러나 워크플로에서 gemini_cli_version을 설정하여 gemini-cli 버전을 지정하는 경우 패치 버전 중 하나로 업그레이드하고 Gemini CLI를 사용하는 워크플로 설정을 감사하는 것이 좋습니다.
Gemini는 취약점 보상 프로그램(g.co/vulnz)을 통해 이 문제를 보고해 주신 다음 보안 연구원들에게 감사드립니다.
왜 이 VPI인가 (설명가능 · 실험적)
VPI 산정 기준
| 영향도 | 100.00 |
| 악용 신호(추가 악용신호 없음) | ×1.00 |
| VPI | 100.00 |
VPI 공식 vpi-v1 기준