Git의 캐리지 리턴 및 클론 RCE 취약점

Hacker News 의견

• 이 모든 결과로 서브모듈 클론을 수행할 때, 읽기는 path = ... 형태로 하면서, 쓸 때는 ^M 으로 끝나지 않는 다른 경로로 기록하는 현상 발생 설명

  • 기사에서 말하는 "원격 코드 실행"이 여기서 어떻게 일어나는지, 그리고 보안적으로 얼마나 심각한지 궁금증 제기

  • 아직 PoC는 공개하지 않았지만, CVE-2024-32002 익스플로잇을 거의 그대로 변형한 내용이며, 이를 수정한 커밋의 테스트도 큰 힌트 제공 언급

  • CVE-2024-32002 설명 인용: 서브모듈이 들어간 저장소를 악의적으로 조작해 Git의 버그를 이용, 서브모듈 워크트리가 아니라 .git/ 디렉터리에 파일을 쓸 수 있음. 덕분에 클론 동작 중에 바로 실행되는 hook을 쓸 수 있어서 사용자가 실제로 실행되는 코드를 점검할 기회조차 갖지 못하는 상황 가능

  • 요약하면, 악성 git hook을 저장소에 넣을 수 있고, 일반적으로 git hook은 ‘git clone’ 시 설치되지 않지만 이번 공격에서는 이를 가능하게 만들어줘서 클론 과정 중 hook 실행 가능성 제시

  • 새로운 CVE에 대한 더 많은 정보는 여기에서 확인 가능성 안내

    • 설정값 읽을 때 Git이 CR, LF 문자를 제거하지만, 기록할 때는 CR을 인용하지 않아 읽을 때 손실 문제 설명
    • 서브모듈 경로 끝에 CR 문자가 포함될 경우, 제거된 경로를 사용하게 되어 서브모듈이 잘못된 위치에 체크아웃 가능성
    • 해당 제거된 경로와 서브모듈 hook 디렉터리 사이에 이미 symlink가 존재할 경우, 공격자가 post-checkout hook을 통해 임의 코드 실행 가능성
    • 이번 CVE 외에도 많은 Git 취약점들이 있으니 함께 살펴볼 가치가 있다는 의견

  • 임의 파일 쓰기가 가능하면 대부분 RCE까지 이어질 수 있다는 단순하지만 불편한 진실 언급

• ad-hoc DSL로 설정 파일을 쓸 때의 위험성 언급

  • 문법에 대한 공식 명세가 없는 경우가 많고, 파싱에 대한 진짜 기준이 직접 만든 직렬화/역직렬화 구현에 분산되어 있음 지적

  • 둘이 따로 놀면(예를 들면, 파서엔 새 문법 추가했는데 라이터는 반영 못한 경우 등) 파서 차이로 인해 폭탄이 될 수 있음 강조

  • 교훈: 하나의 source of truth를 두고, 그에 의존하는 부분은 이를 기반으로 자동 생성하는 구조 필요하다는 것임

  • 이 버그는 source of truth 문제와는 별개라는 점 지적

    • 순수한 논리 오류로, 만약 유닉스에 이런 표준 시스템 라이브러리가 있었다면 거기서도 똑같이 터질 수 있었던 문제로 설명
    • 만약 그런 표준 라이브러리에 있었다면, 문제의 영향은 훨씬 심각했을 것이고, 지금은 주로 개발자들에 한정되어 피해가 적은 상황이라 언급

  • 여기서 사용된 DSL(ini 파일 포맷)은 ad-hoc이긴 해도 매우 흔하고 익숙하게 잘 정리되어 있어서, 일반적으로 실질적인 명세로 충분하다는 의견

    • 버그의 본질은 포맷 문제가 아니라 중간에 들어간 핸드코딩 파서(또는 렉서)에 있으며, 이런 코드를 이제는 그만둬야 한다고 주장
    • Clever하게 핸드코딩하는 게 필요한 자리는 아직 일부 남아 있지만, 데이터 교환 포맷에는 절대 쓰면 안 되며, ini가 필요하면 toml, 별로면 JSON, 심지어 YAML도 괜찮고, 정말 고통을 찾으면 XML, 꼭 이진 포맷이 필요하다 우긴다면 protobufs 안내
    • 결론적으로, 프로그래밍 언어 저자가 아니라면 직접 파서를 쓰지 말고, 꼭 라이브러리를 활용해야 함 강조

• 직접 문제 재현 후, 이 저장소에 올림

  • 바로 git 최신 버전으로 업데이트 시도, 아직 Arch에는 적용 안 됨

  • 새로운 패치 전까지는 pull을 자제할 예정, 자동 pull이 걸려있는 유명 저장소에서 문제가 생길 수 있으니 업그레이드에 시간이 많이 걸릴 것 같다는 우려

  • 이번 취약점이 패치 전에 공개된 것이냐는 의문 제기

    • 예전엔 누가 얼마나 취약점 공격 가능한지 설명하는 글이 대부분 패치된 지 몇 달 뒤에 올라왔는데, 요즘은 모든 게시글에서 "이건 진짜 지금 위험하다"와 "이미 패치되어 걱정 없다"는 걸 명확히 구별해 지나가듯 언급해주길 바라는 마음

• 기존 익스플로잇에서 "간단한 변형만 했다"는 언급 보며, Git이 왜 Landlock을 사용하지 않는지 궁금증 제기(Landlock은 리눅스 전용 샌드박스 보안 기능)

  • "git clone" 작업은 config 디렉토리엔 읽기 전용, clone 대상 디렉토리엔 읽기/쓰기 권한, 그리고 하위 프로세스 호출 금지 구조 필요성 제시

  • 익스플로잇마다 항상 계산기 띄우는 딥 모먼트 비꼼

  • 하위 프로세스 호출 금지라면 post-checkout 등 모든 git hook이 깨진다는 문제 제기

    • 필요 없다면 seccomp 같은 컨테이너 환경에서 git 실행도 가능하지만, 많은 기능이 제한될 것임 설명

  • 그리고 하위 프로세스가 없으면 ssh를 통한 git 사용을 못하게 되는 점 지적

• Homebrew 자체가 문제가 되는지(즉, recursive clone을 하는지) 질문 제기

  • 이 코드에서 가능성 발견

  • 홈브류 목표 자체가 저장소 코드를 실행시키는 것이라, recursive clone이 없다면 오히려 이상할 정도라는 의견

    • 문제는 clone하는 데이터가 실행되면 안 되는 경우에만 RCE가 의미 있는데, 그런 케이스는 드뭄을 지적

• Jon Postel의 CR+LF 관련 명언을 보며 추억 회상

  • 이 글 링크 및, 2003년과 비교해 지금은 그 조언이 맞지 않을 수 있다는 평가 공유
  • Mark Crispin이 당시 해설했던 대로, 사람들이 오해하고 있다는 것, 1990년대 말 Daniel J. Bernstein가 사람-기계간 변환(parsing/quoting) 과정에서 생기는 문제를 지적했던 사례와 연결
  • 25년이 지나도 CR을 escape하지 않는 quoter 코드 문제가 반복되고, 수정된 뒤에도 whitespace 전부를 체크하진 않는다는 점 관찰
  • git blame 결과, 문제의 코드는 19년 전에 작성된 것으로, Bernstein의 10주년 회고와 시기가 겹침
  • 관련 커밋, qmail 논문 등 추가 자료 공유
  • 결국 20세기 힘들게 배운 교훈을 21세기에도 반복해서 배워야 한다는 현실 강조

• Homebrew에 git 2.50.1 업데이트가 아직 없어서 조금 더 기다려야 할 듯

  • 이 이슈 혹은 brew install git --HEAD로 업데이트 시도 안내

• Homebrew와 Debian Bookworm 모두 여전히 취약 버전을 제공 중이라는 사실 공유

  • 이제 Homebrew에서도 2.50.1 버전 사용 가능하다고 알림

• 디렉터리 목록을 불러오는 시스템 콜이 만약 파일명에 ASCII 제어문자(bytes)가 존재한다면 해당 파일의 존재를 부정해야 하는지, 디스크 손상으로 간주해야 하는지, 아니면 다른 처리를 해야 할지 고민

  • 현재 로케일에서 그 바이트들이 다른 의미를 가질 수도 있으니, 윈도우즈처럼 파일명을 모두 UTF-16으로 가정하는 게 아니니 의외의 상황 발생 가능성 제시

  • Unix 계열 시스템에서 파일명(및 기타 문자열)은 단순한 바이트 배열이기 때문에 생기는 문제임을 간단히 지적