git apply의 함정: 커밋 메시지에 숨긴 가짜 diff가 진짜 패치를 덮어쓴다

평소 무심코 쓰던 git apply, 사실은 위험한 친구였어요

오픈소스 프로젝트에 패치 파일을 받아본 적 있나요? 메일링 리스트에서 .patch 파일을 받아서 git am이나 git apply로 적용하는 흐름은 리눅스 커널 같은 큰 프로젝트에서는 지금도 흔한 워크플로우거든요. 그런데 최근 samizdat.dev에서 공개된 "Phantom Patch"라는 발견이 좀 충격적이에요. 한마디로, 커밋 메시지 안에 가짜 diff를 숨겨두면 git이 진짜 코드 변경 대신 그 가짜 diff를 적용해버린다는 거예요. 이게 뭐냐면, 코드 리뷰어가 보는 변경 내용과 실제로 머지되는 변경 내용이 다를 수 있다는 뜻이에요. 공급망 공격(supply chain attack)의 새로운 통로가 될 수 있죠.

어떻게 이런 일이 가능한 걸까

원리는 의외로 단순해요. 우리가 보통 git format-patch로 만드는 .patch 파일은 사실 이메일 형식이에요. 헤더가 있고, 그 다음에 커밋 메시지가 있고, 그 아래에 --- 구분자가 오고, 그리고 진짜 diff가 붙거든요. 문제는 git apply가 파일 어디서든 diff --git 같은 패턴을 만나면 그걸 패치로 인식한다는 점이에요.

그래서 공격자가 커밋 메시지 안에 "예시 코드"인 척하면서 diff --git a/auth.c b/auth.c 같은 블록을 넣어두면 어떻게 될까요? 사람이 패치 파일을 GitHub PR이나 메일 클라이언트로 볼 때는 "아, 그냥 설명 안에 들어 있는 예시구나" 하고 넘기지만, git apply는 그 가짜 diff까지 같이 적용해요. 게다가 진짜 변경 사항이 그 뒤에 있다면 둘 다 적용될 수도 있고, 어떤 경우엔 진짜 변경 대신 가짜만 적용되기도 하죠.

리뷰어 입장에서 더 무서운 건, GitHub UI나 일반적인 diff 뷰어는 커밋 메시지를 텍스트로만 보여준다는 점이에요. 거기 들어 있는 가짜 diff 블록은 그냥 "문서화 목적의 코드 스니펫"처럼 보이거든요. 누가 PR 본문에 "참고로 이렇게 바뀝니다" 하면서 코드 블록을 넣어두면 자연스럽잖아요.

기존의 비슷한 트릭들과 어떻게 다를까

사실 git 생태계에서 "보이는 것과 적용되는 것이 다르다"는 트릭은 처음이 아니에요. 몇 년 전에는 유니코드 양방향 텍스트(bidi)를 이용한 "Trojan Source" 공격이 화제였죠. 소스 코드를 IDE에서 보면 정상으로 보이는데, 실제 컴파일되는 바이트는 다른 의미인 그런 트릭이었어요. 또 git submodule URL에 셸 메타문자를 넣어서 git clone 시점에 명령을 실행시키는 CVE도 있었고요.

Phantom Patch가 흥미로운 건, 사람이 신뢰하는 형식 자체를 공격한다는 점이에요. 메일링 리스트 기반 워크플로우에서는 메인테이너가 패치 파일을 받아서 적용하기 전에 한번 훑어보는데, 이때 사람의 눈은 자연스럽게 --- 아래 진짜 diff 부분에 집중해요. 위쪽 커밋 메시지는 "설명이겠지" 하고 빠르게 스크롤하죠. 이 인지적 편향을 노린 거예요.

한국 개발자라면 어떻게 대응해야 할까

국내 회사에서 메일 패치를 직접 받아 처리하는 곳은 많지 않아요. 대부분 GitHub PR 워크플로우라서 직접적인 위험은 적은 편이죠. 하지만 다음 상황은 한번 점검해볼 만해요. 첫째, CI 파이프라인에서 외부 패치를 자동 적용하는 스크립트가 있다면 입력 검증을 추가하세요. 패치 파일에 diff --git 블록이 두 번 이상 등장하거나, --- 구분자 위쪽에 diff 패턴이 있으면 경고를 띄우는 정도만 해도 효과적이에요. 둘째, 리눅스 커널이나 QEMU 같은 메일 기반 프로젝트에 기여한다면, 받은 패치를 적용하기 전에 git am --interactive로 한 번 더 확인하는 습관이 안전해요. 셋째, AI 도구가 자동으로 PR을 만들어 주는 경우가 많아졌는데, 만약 그 도구가 외부에서 받은 텍스트를 그대로 커밋 메시지로 넣는다면 이런 인젝션이 가능해질 수 있어요.

마무리

결국 이 이슈의 본질은 "포맷의 모호성을 신뢰에 의존해 처리해 왔다"는 거예요. git이 1.x 시절부터 유지해 온 관대한 파싱이 이제는 위험 요소가 된 셈이죠. 여러분의 팀에서는 외부 패치나 자동화된 PR을 어떻게 검증하고 계신가요? 코드 리뷰 단계에서 "커밋 메시지"까지 꼼꼼히 보는 문화가 정착되어 있나요?