▲

NixOS와 재현 가능한 빌드로 탐지된 xz 백도어

 (luj.fr)
1P by GN⁺ 11일전 | ★ favorite | 댓글 1개
  • 2024년 3월, Linux 배포판에서 소스 타르볼을 압축 해제하는 데 사용되는 xz 소프트웨어에 백도어가 발견됨.
  • 이 백도어는 악의적인 유지보수자 _Jia Tan_에 의해 3년 동안 은밀하게 삽입됨.
  • 이 사건은 원격 코드 실행을 가능하게 하여 큰 영향을 미쳤으며, 발견하기 매우 어려웠음.
  • Microsoft의 Postgres 개발자인 Andres Freund가 성능 저하를 조사하던 중 우연히 발견하여 큰 재앙을 피할 수 있었음.

공격 작동 방식

  • 백도어는 ssh 프로그램을 하이재킹하여 원격 코드 실행을 가능하게 함.
  • RSA_public_decrypt 함수를 수정하여 특정 RSA 키로 로그인할 때 공격자가 임의의 명령을 실행할 수 있도록 함.
  • 두 가지 주요 구성 요소로 구성됨:
    1. 악성 객체 파일을 xz 빌드 프로세스의 일부로 설치하는 스크립트.
    2. RSA_public_decrypt 함수를 후킹하는 절차.

1. 악성 객체 파일 설치 스크립트

  • 악성 객체 파일은 xz git 저장소의 테스트 파일에 숨겨져 있음.
  • 백도어는 유지보수자가 제공한 릴리스 타르볼에서만 활성화됨.

2. RSA_public_decrypt 함수 후킹 절차

  • 동적 로딩 시간에 실행되는 코드를 강제 실행하기 위해 glibc의 ifunc 기능을 사용함.
  • ssh가 실행될 때 libsystemd와 liblzma가 로드되며, 이 과정에서 백도어가 임의의 코드를 실행함.

xz 재앙을 피하기 위한 방법

  • 오픈 소스 소프트웨어의 신뢰성을 높이기 위해 소셜 문제와 기술적 문제를 모두 다루어야 함.
  • 소프트웨어 공급망 보안 프로세스를 개선해야 함.

신뢰할 수 있는 소스에서 소프트웨어 빌드

  • 많은 배포판이 유지보수자가 제공한 타르볼을 사용하여 xz를 빌드했기 때문에 공격이 효과적이었음.
  • 가능한 경우, 가장 신뢰할 수 있는 소스에서 소프트웨어를 빌드해야 함.

상황이 허락할 때...

  • NixOS는 기능적 패키지 관리 모델을 기반으로 하는 배포판이며, 각 패키지는 Nix라는 함수형 프로그래밍 언어로 표현됨.
  • NixOS는 GitHub에서 자동 생성된 소스 아카이브를 사용하는 문화가 있음.

신뢰할 수 없는 릴리스 타르볼에 신뢰 구축

  • NixOS는 부트스트랩 단계에서 유지보수자가 제공한 타르볼을 사용해야 했음.
  • 소프트웨어 공급망 보안을 강화하기 위해 특정 보호 조치를 마련해야 함.

1. 소스 비교

  • 배포판에서 사용하는 소스 타르볼이 GitHub의 것과 동일한지 확인하는 것이 중요함.
  • 그러나 릴리스 타르볼이 소스와 다른 경우가 종종 있으며, 이는 문제가 아님.

2. 비트 단위 재현성 활용

  • 재현 가능한 빌드는 동일한 조건에서 두 번 빌드할 때 동일한 아티팩트를 생성하는 소프트웨어 프로젝트의 속성임.
  • 비트 단위 재현성을 통해 신뢰할 수 없는 유지보수자 제공 타르볼에 대한 신뢰를 구축할 수 있음.

결론

  • xz 백도어 사건은 오픈 소스 소프트웨어 공급망 보안의 중요성을 일깨워줌.
  • NixOS와 같은 시스템은 재현 가능한 빌드를 통해 보안을 강화할 수 있음.
▲
GN⁺ 11일전  [-]
Hacker News 의견

  • NixOS와 재현 가능한 빌드가 xz 백도어를 탐지하지 못했음. NixOS는 악성 xz 빌드를 배포했지만, NixOS를 목표로 한 것이 아니었기 때문에 문제는 없었음

    • NixOS 개발자는 백도어가 드러났을 때 악성 xz 버전이 사용자에게 배포된 것을 보고 놀랐음
    • 이론과 현실은 다르며, xz가 가능했던 이유는 기술적 취약점이 아닌 '현실 세계'의 문제였음. 소프트웨어로 현실 세계를 패치할 수 없음을 인식하는 데 어려움이 있음

  • 저자는 이번 사건에만 집중하고 있는 것 같음. Jiatan 사건은 단일 사례이며, 다른 시나리오에서도 방어가 실패할 수 있음

    • NixOS 사용자로서 NixOS가 이를 잡아내지 못했을 가능성이 높다고 생각함. 증거가 없으면 NixOS에 신뢰를 두는 것은 어리석음

  • NixOS는 xz 백도어가 RedHat과 Debian을 목표로 했기 때문에 관련이 없음. 아이러니하게도 백도어는 Microsoft 직원에 의해 발견됨

  • 기사에서는 배포판이 전통적인 설치용 tarball 대신 VCS(예: Github)에서 직접 소스 코드를 가져와야 한다고 언급함

    • 그러나 악의적인 유지보수자가 소스 코드 저장소에 직접 바이너리 블롭을 추가할 수 있음
    • 저자는 Github가 코드를 검증하는 것처럼 신뢰할 수 있다고 제안하지만, 실제로 Github는 코드를 검증하지 않음

  • NixOS가 예방할 수 있었던 사건에 집중하려면 CrowdStrike 사건에 집중해야 함. 어제의 설정으로 부팅할 수 있었다면 대부분의 문제를 완화할 수 있었음

  • NixOS는 소스에서 모든 것을 컴파일하고, 사용된 소스가 변조되지 않았음을 암호학적으로 검증하며, 패키지 간 버전 종속성을 가짐. Debian도 재현 가능한 빌드를 가짐

    • 문제는 빌드 시스템이 소스에서 빌드하기 전에 사전 컴파일된 객체 파일을 제거하지 않았다는 것임. 소스 코드를 아무도 확인하지 않으면 백도어를 추가할 수 있으며, NixOS나 다른 배포판도 이를 막을 수 없음

  • "할 수 있었다"는 것은 증명되지 않았음을 의미하며, 실제로 그들은 이를 배포했음

  • 훌륭한 설명적 분석. 잘못된, 오해를 불러일으키는 제목, 아마도 "기술적으로 정확"하지만, "백도어가 있는" 의미로 최선임

    • 빌드 매니저 도구의 필요성과 사용을 강조하며, 빌드 과정에서 파일이 파일에 영향을 미치는 인과 추적 그래프를 명시적으로 만들고, 그 그래프를 강제하거나 이전 추적 그래프와의 편차를 보고하는 방법을 구축해야 함

  • Jia Tan의 PR이 승인되었다면, 악성 아티팩트가 tarball과 마찬가지로 Github 릴리스로 쉽게 갈 수 있었음. Github 릴리스가 보안 완화라는 점을 이해하기 어려움

  • 릴리스 tarball이 소스와 다르다는 점

    • 유지보수자가 제공한 tarball이 원본 소스 코드에서 정직하게 생성되었다면, 어떻게 다른 버전 등이 문제가 되는지 이해하기 어려움
    • 생성된 tarball이 소스 코드 자체에서 생성될 수 있도록 하고, 아무것도 제외하지 말고, git add & commit을 해야 함. 이 경우에도 커밋 기록을 확인해야 하며, 육안으로는 무해했기 때문에 어떻게 검증할 수 있는지 의문임
    • 유지보수된 tarball이 소유자의 소스 코드에서 생성되고 Github에 없으면 문제가 됨

  • 독이 든 테스트 파일을 푸시하는 것 이상의 문제가 있었지만, Nix가 이를 어떻게 예방할 수 있었는지 이해하기 어려움

    • 유명 프로젝트가 리더를 변경했다면, 커밋을 주의 깊게 보고 누가 리더인지 확인해야 할 것임

  • 기사를 잘못 이해했는지, 놓친 것이 있는지 궁금함

답변달기