Git의 숨겨진 옵션, 보안의 새로운 지평을 열다

Git의 --end-of-options 플래그는 옵션 파싱 종료를 명확히 하여 보안 취약점을 방지함

기존 `--` 구분자는 Git 내부에서 이미 사용 중이라 새로운 플래그가 필요했음

패키지 관리자(Package Managers)에서 Git URL/Ref를 안전하게 처리하기 위한 핵심 요소로 부상함

CWE-88 (Argument Injection) 사례와 함께 Git, Hg, SSH 등에서 발생하는 보안 문제점을 분석함

Git 옵션 파싱의 복잡성과 --end-of-options의 등장

커뮤니티에서는 Git의 옵션 파싱 방식이 복잡하며, 특히 `--`가 이미 예약되어 있어 옵션과 경로/리비전 분리에 어려움이 있었다고 지적한다. `--end-of-options` 플래그는 이러한 모호성을 해결하고 안전한 인수 전달(Safe Argument Passing)을 가능하게 하는 중요한 개선 사항으로 평가받는다. 다만, Git 버전 2.24.0 이후에 도입되어 하위 호환성 문제가 발생할 수 있다는 점이 언급된다.

CWE-88 (Argument Injection)과 Git의 취약점

논의에서는 CWE-88 (Argument Injection)이 쉘을 거치지 않고 `exec` 시스템 콜을 통해 직접 실행될 때 발생하는 문제임을 강조한다. Git의 `--upload-pack`이나 `-c core.sshCommand`와 같은 옵션은 신뢰할 수 없는 입력이 전달될 경우 원격 코드 실행(Remote Code Execution)으로 이어질 수 있는 심각한 보안 위협이 된다. 특히 Docker build의 CVE-2019-13139 사례가 이를 명확히 보여준다.

패키지 관리자의 Git 인수 처리 방식 비교

대부분의 패키지 관리자(Gem, npm, Pip 등)가 Git 바이너리를 직접 포크(fork)하여 사용하는 방식이 일반적임을 지적한다. 이 과정에서 Git URL이나 Ref를 안전하게 처리하기 위해 `--` 또는 선행 대시(-) 검사를 사용하지만, `--end-of-options`를 채택한 경우는 Go 언어의 `cmd/go`가 유일하다는 점이 주목받는다. 이는 라이브러리(libgit2 등) 사용과 직접 바이너리 호출 간의 트레이드오프를 보여준다.

Git 라이브러리 사용의 장단점

libgit2, gitoxide, go-git 등 Git 프로토콜을 구현한 라이브러리를 사용하면 argv 경계(argv Boundary)를 우회하여 인수 주입(Argument Injection) 문제를 근본적으로 해결할 수 있다. 하지만 이러한 라이브러리들은 업스트림 Git의 보안 패치를 지속적으로 추적하고 적용해야 하는 유지보수 비용(Maintenance Cost)이 발생한다는 단점이 있다. 이는 특정 호출 지점에서의 검사보다 더 큰 부담이 될 수 있다.

최소 Git 버전 요구사항과 배포판 호환성

글에서는 `--end-of-options` 플래그의 도입 시점(Git 2.24.0)과 하위 호환성 문제를 고려할 때, 이를 채택하기 위한 최소 Git 버전 요구사항(Minimum Git Version Requirement) 상향이 불가피함을 설명한다. Amazon Linux 2 (Git 2.14.3)와 같은 오래된 배포판 지원 중단 시점과 맞물려, 최신 Git 기능 활용과 배포판 호환성(Distribution Compatibility) 사이의 균형점을 찾아야 함을 시사한다.