전 세계를 거의 감염시킬 뻔한 xz Utils 백도어에 대해 알려진 것

 (arstechnica.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Microsoft의 Andres Freund가 Debian 시스템의 SSH 성능 이상을 추적하다가, 거의 모든 Linux/Unix 계열 환경에 쓰이는 xz Utils에 심어진 백도어를 발견함
  • 악성 코드는 xz Utils 5.6.0과 5.6.1에 들어갔고, 특정 개인 키를 가진 공격자가 SSH 로그인 인증서에 코드를 숨겨 백도어가 있는 장치에서 실행할 수 있게 설계됨
  • 공격자는 GitHub 소스가 아닌 릴리스 tarball, 테스트 파일, 빌드 스크립트, glibc IFUNC를 이용해 liblzma를 거쳐 sshd 인증 루틴을 후킹하려 함
  • 백도어는 amd64/x86_64, glibc, Debian 또는 Red Hat 계열 패키지 빌드 조건을 확인했으며 Fedora Rawhide, Fedora 41, Debian testing/unstable/experimental, openSUSE Tumbleweed/MicroOS, Kali Linux 일부 기간 릴리스에 포함됨
  • Jia Tan이라는 개발자 페르소나는 수년에 걸쳐 xz Utils 유지보수에 관여했고, 사건은 CVE-2024-3094로 추적되며 Binarly 검사 페이지와 xzbot 같은 탐지·분석 도구가 나옴

발견과 영향 범위

  • Andres Freund는 Microsoft의 PostgreSQL 관련 작업을 하던 개발자이자 엔지니어로, Debian 시스템에서 SSH 로그인이 CPU를 과도하게 사용하고 valgrind 오류를 내는 현상을 조사하다가 이상 징후를 발견함
  • 원인은 xz Utils 업데이트였고, Freund는 Open Source Security List에 이 업데이트가 압축 소프트웨어에 의도적으로 심어진 백도어라고 공개함
  • xz Utils는 Linux를 포함한 거의 모든 Unix 계열 운영체제에서 손실 없는 데이터 압축과 해제를 제공하며, 레거시 .lzma 형식도 지원함
  • Filippo Valsorda는 이를 “공개적으로 설명된 공급망 공격 중 가장 잘 실행된 사례일 수 있으며, 널리 쓰이는 라이브러리의 악의적이고 유능하며 권한 있는 upstream이라는 악몽 같은 시나리오”라고 평가함

백도어가 노린 동작

  • 악성 코드는 xz Utils 5.6.0과 5.6.1에 추가되어 소프트웨어 동작 방식을 바꿈
  • 백도어는 원격 SSH 연결에 쓰이는 실행 파일인 sshd를 조작함
  • 사전에 정해진 암호화 키를 가진 사람은 SSH 로그인 인증서에 원하는 코드를 숨기고, 이를 업로드한 뒤 백도어가 있는 장치에서 실행할 수 있음
  • 실제로 업로드된 코드는 확인되지 않아 공격자가 어떤 코드를 실행하려 했는지는 알려지지 않음
  • 이론적으로는 암호화 키 탈취나 악성코드 설치를 포함해 거의 어떤 작업도 가능할 수 있음

압축 라이브러리가 SSH에 닿은 경로

  • 라이브러리는 자신과 링크된 실행 파일의 내부 동작을 조작할 수 있음
  • OpenSSH의 대표적인 sshd 구현은 기본적으로 liblzma와 링크하지 않음
  • Debian과 여러 Linux 배포판은 sshd를 systemd와 연결하는 패치를 추가함
    • systemd는 부팅 중 여러 서비스를 로드하는 프로그램임
    • systemd는 liblzma에 링크됨
    • 이 연결 경로 때문에 xz Utils가 sshd에 영향을 줄 수 있었음

수년에 걸친 준비 정황

  • 2021년 JiaT75라는 사용자가 오픈소스 프로젝트에 처음으로 알려진 커밋을 남김
    • libarchive 프로젝트에서 safe_fprint 함수를 더 덜 안전한 것으로 오래 알려진 변형으로 바꾼 변경이었고, 당시에는 아무도 알아차리지 못함
  • 2022년 JiaT75는 xz Utils 메일링 리스트에 패치를 제출함
    • 곧 Jigar Kumar라는 신규 참여자가 Lasse Collin이 xz Utils를 충분히 자주 또는 빠르게 업데이트하지 않는다고 압박함
    • Dennis Ens와 다른 신규 참여자들도 Collin에게 추가 유지보수자를 들이라고 압박함
  • 2023년 1월 JiaT75는 xz Utils에 첫 커밋을 남겼고, Jia Tan이라는 이름으로 xz Utils 업무에 더 깊게 관여함
    • oss-fuzz의 Collin 연락처를 자신의 연락처로 바꿈
    • oss-fuzz 테스트 중 IFUNC 기능을 비활성화해, 이후 xz Utils에 들어갈 악성 변경을 탐지하지 못하게 하는 변경을 요청함
  • 2024년 2월 Tan은 xz Utils 5.6.0과 5.6.1 커밋을 냈고, 이 업데이트가 백도어를 구현함
  • 이후 Tan 또는 다른 사람들이 Ubuntu, Red Hat, Debian 개발자들에게 해당 업데이트를 운영체제에 병합하라고 요청함

포함된 배포판과 실행 조건

  • Tenable에 따르면 백도어 버전 또는 관련 업데이트는 다음 릴리스에 들어감
    • Fedora Rawhide: Fedora Linux의 개발 배포판
    • Fedora 41
    • Debian testing, unstable, experimental: 5.5.1alpha-0.1부터 5.6.1-1
    • openSUSE Tumbleweed와 openSUSE MicroOS: 3월 7일부터 3월 28일 사이 백도어 xz 버전 포함
    • Kali Linux: 3월 26일부터 3월 28일 사이 xz-utils 5.6.0-0.2 포함
  • Sam James의 분석에 따르면 악성 스크립트는 빌드 대상이 amd64/x86_64인지, linux-gnu 이름을 쓰는지, GCC와 GNU ld를 쓰는지 확인함
  • 또한 Debian 패키지 빌드인지 또는 RPM_ARCH가 x86_64인지 확인함
  • 공격은 amd64 시스템에서 glibc를 사용하고 Debian 또는 Red Hat 파생 배포판을 빌드하는 환경을 겨냥한 것으로 보임
  • 다른 시스템이 취약한지는 당시 알려지지 않음

구현 방식과 은닉 기법

  • Sam James는 백도어가 여러 구성요소로 이뤄졌다고 정리함
    • upstream이 배포한 릴리스 tarball은 GitHub의 코드와 같지 않음
    • 릴리스 tarball의 build-to-host.m4는 GitHub upstream의 것과 크게 다름
    • git 저장소의 tests/ 폴더에는 조작된 테스트 파일이 있음
      • tests/files/bad-3-corrupt_lzma2.xz
      • tests/files/good-large_compressed.lzma
    • build-to-host.m4가 호출한 스크립트가 악성 테스트 데이터를 풀고 빌드 과정을 수정함
    • glibc의 IFUNC가 OpenSSH 인증 루틴을 런타임 후킹 또는 리다이렉션하는 데 사용됨
  • HD Moore는 최종 백도어 단계가 amd64에서 라이브러리를 빌드하고 Debian 또는 RPM 패키지를 만들 때만 실행된다고 확인함
  • 연구자들의 분석에 따르면 SSH 공개 키 검증 과정에서 특정 fingerprint 함수와 공개 키가 맞으면, 공개 키를 실제 검증하기 전에 사전 공유 키로 키 내용을 복호화함
  • 복호화된 내용은 특정 형식에 맞을 때 system으로 직접 전달됨
  • fingerprint가 맞지 않거나 복호화된 내용이 형식에 맞지 않으면 일반 키 검증으로 돌아가며, 사용자는 차이를 알아차리기 어려움

Akamai가 정리한 실행 체인

  • Akamai 연구자들은 백도어가 xz GitHub 저장소가 아니라 소스 코드 tarball 릴리스에만 포함되어 탐지를 피하려 한 것으로 봄
  • 백도어는 여러 커밋에 걸쳐 구성됨
    • 빌드 과정에서 IFUNC를 사용해 악성코드가 심볼 해석 함수를 가로챌 수 있게 함
    • 테스트 파일 안에 난독화된 공유 객체를 숨김
    • 라이브러리 빌드 과정에서 공유 객체를 추출하는 스크립트를 실행함
    • 프로세스 권한을 제한하는 보안 기능인 landlocking을 비활성화함
  • 실행 체인은 여러 단계로 이어짐
    • build-to-host.m4가 라이브러리 빌드 중 실행되어 bad-3-corrupt_lzma2.xz를 bash 스크립트로 디코딩함
    • 이 bash 스크립트가 good-large_compressed.lzma를 더 복잡한 방식으로 디코딩해 또 다른 스크립트를 만듦
    • 그 스크립트가 liblzma_la-crc64-fast.o 공유 객체를 추출하고, 이를 liblzma 컴파일 과정에 추가함
  • 이 공유 객체는 liblzma에 컴파일되어 일반 함수 이름 해석 과정을 대체함
  • 악성 라이브러리는 OpenSSH의 RSA_public_decrypt 함수 포인터를 자신이 만든 악성 함수로 바꿀 수 있음
  • Filippo Valsorda의 분석에 따르면 이 악성 함수는 인증 클라이언트의 인증서에서 명령을 추출하고, 위협 행위자임을 확인한 뒤 system()으로 넘겨 인증 전 원격 코드 실행을 달성함

Jia Tan과 남은 의문

  • Jia Tan에 대해 알려진 정보는 매우 적음
  • 이 개발자 페르소나는 지난 몇 년 동안 수십 개의 다른 오픈소스 소프트웨어에도 관여함
  • Jia Tan이라는 사용자명 뒤에 실제 인물이 있었는지, 완전히 조작된 인물인지는 알려지지 않음
  • 추가 기술 분석은 Filippo Valsorda의 Bluesky 스레드, Kevin Beaumont의 분석, Freund의 금요일 공개 자료에서 확인할 수 있음

CVE와 확인 도구

  • 이 취약점의 추적 식별자는 CVE-2024-3094임
  • Binarly의 xz.fail 페이지는 IFUNC 구현을 탐지하며 행동 분석을 기반으로 함
    • 유사한 백도어가 다른 곳에 심어졌을 때도 불변 조건을 자동 탐지할 수 있음
  • xzbot은 분석과 실험용 기능을 제공함
    • honeypot: 익스플로잇 시도를 탐지하기 위한 가짜 취약 서버
    • ed448 patch: 자체 ED448 공개 키를 사용하도록 liblzma.so 패치
    • backdoor format: 백도어 페이로드 형식
    • backdoor demo: ED448 개인 키를 알고 있다고 가정하고 RCE를 트리거하는 CLI

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 목표는 표준화된 테스트 프레임워크를 써서 XZ의 테스트 작성을 쉽게 하는 것이었음
    아직 테스트되지 않은 기능이 많아서, 장기적인 프로젝트 안정성을 위해 테스트를 늘리는 데 도움이 될 거라고 Jia가 2022-06-17에 썼던 내용임
    오래전부터 준비되어 온 변화였던 셈

  • lib가 RSA_public_decrypt에 끼어들 수 있게 만든 링킹 메커니즘은 많이 논의되지 않은 것 같음
    프로세스 분리 같은 얘기는 많지만, 그 함수 호출 리다이렉트에 대한 얘기는 적음
    SSH로 들어오는 코드 같은 핵심 구성요소를 라이브러리와 계층적 신뢰 방식으로 링크해서, “내가 호출하는 위치에서는 신뢰하지만 다른 호출 지점에 스스로 끼어드는 건 허용하지 않는다” 같은 모델을 만들 수 있지 않을까 싶음
    우회 방법이 있으니 의미 없다는 식의 “보안 은폐” 반사 반응을 부를 수는 있겠지만, 그래도 공격 표면 축소로 볼 수 있음

    • 프로그램 하위 구성요소들이 각자 보안 컨텍스트를 가진 채 메시지 전달로 서로 호출하는 Erlang 액터 같은 모델이 작동할 수도 있음
      다만 운영체제에는 여러 보안 컨텍스트가 겹쳐 있음. XZ 백도어와 관련해서는 주로 모듈 수준의 capability 기반 보안이지만, 프로그램 수준 capability, 메모리 수준 격리(페이징), 마이크로아키텍처 수준 격리 등도 있음
      이 요소들이 함께 작동하면서 성능까지 내게 만드는 건 꽤 어렵고, Unix 계열이 이런 모델로 이동하는 건 프로세스 개념 자체를 대체해야 해서 사실상 불가능해 보임
    • 내가 보기엔 문제는 glibc의 IFUNC 사용임
      이게 XZ 테스트를 깨뜨렸고, 갑자기 그 테스트를 비활성화하자고 로비하는 계정들이 나타났으며, 그 결과 익스플로잇이 가능해졌음
    • 본질적으로 이 코드는 빌드 시점(./configure && make 실행 시)에 C 파일을 몰래 수정해 ifunc resolver를 패치하고, 제공된 악성 객체를 호출하게 만듦
      손상된 객체 파일은 now 링커 플래그와 함께 링크되어 라이브러리 로드 시점에 ifunc가 즉시 해석되고, 이때 프로세스 링크 테이블이 아직 쓰기 가능한 상태라 패치된 resolver가 호출됨
      바로 이 부분이 중요해서, 라이브러리가 로드될 때 메모리 안의 RSA_public_decrypt 함수를 그냥 가로챌 수 있었음
      백도어 주입 과정을 아주 잘 분석한 글: https://research.swtch.com/xz-script
    • systemd는 최근 압축 라이브러리에 dlopen을 쓰도록 변경을 병합했음: https://github.com/systemd/systemd/pull/31550
      그런 의미에서는 더 안전한 링킹 방식임
    • ltrace가 호출하는 심볼을 감시하는 방식이면 충분할지 궁금함

  • 왜 “거의” 전 세계를 감염시켰다고 표현하는지 모르겠음
    적어도 꽤 인기 있는 Linux 배포판 3개, Arch, Gentoo, openSUSE Tumbleweed가 몇 주 동안 백도어를 배포했고, Tumbleweed에서는 확실히 작동하고 있었음
    몇 주 동안 백도어가 들어간 SSH였으니, “거의”라고 하기엔 약함

    • 그 배포판들에서는 익스플로잇이 실제로 실행되지는 않았음
      deb/rpm 대상에서만 동작했으니, 실질적으로는 프로덕션에 닿기 전에 막힌 셈임
    • Arch와 Gentoo는 취미용 배포판으로는 꽤 인기 있지만, 이 공격이 노린 SSH 서버 같은 전문 운영 환경에서는 훨씬 덜 흔함
      그렇다고 괜찮다는 뜻은 아니고, 이게 RHEL이나 Debian/Ubuntu stable에 들어갈 만큼 오래 발견되지 않았다면 은행이나 의료기관 같은 곳에서 알림을 받게 됐을 것임
      인증 전 원격 코드 실행이면, 네트워크를 강하게 제한하고 흐름 로깅을 잘 갖춘 곳이 아니라면 “영향받지 않았다”고 말하기 어려웠을 것
    • Arch 바이너리 패키지에는 실제로 포함되지 않은 것처럼 보이는데, 그 이유는 백도어 빌드 시스템 자체가 Arch용 백도어를 넣지 않았기 때문임
      xz-5.6.1-1과 xz-5.6.1-2의 liblzma.so.5.6.1을 cmp -l로 비교하면 아주 작은 차이만 있음
      권고문을 쓰기 전에는 이걸 몰랐던 것 같음
      https://github.com/QubesOS/qubes-issues/issues/9067#issuecom...
    • sshd를 돌리는 Linux 머신 대부분은 롤링 릴리스가 아니라 LTS 배포판을 쓸 것 같음
      다만 이걸 뒷받침할 데이터를 어떻게 얻을지는 모르겠음
    • 오픈소스 유지보수자들과 대기업들이 메시지를 받았으면 좋겠음. 오픈소스 유지보수의 재정적 전망을 바꿔야 함

  • 앞으로 12개월 안에 비슷한 무언가가 실제 환경에서 발견된다는 데 101달러를 걸겠음
    유지보수자들이 서로의 과거 커밋을 의심하며 들여다보기 시작할 테니까

    • 이런 공격은 지난 10년 동안 늘어났다고 봄
      중요하지만 잘 알려지지 않았고 유지보수자가 아주 적은 코드베이스를 보면 됨
    • 이미 실행되고 사용된 사례를 찾아낼 수 있을지 궁금함
      내가 이런 걸 갖고 있었고 잘 작동했다면, 나중에 다른 계정으로 “발견”해서 고치게 만들었을 것 같음

  • 이번 일에서 얻은 개인적인 결론은 여러 가지임
    첫째, 소스 저장소와 다른 코드를 담은 소스 배포 tarball은 좋지 않고, 멀어져야 함. 다른 큰 공급망 공격인 event-stream도 비슷한 점을 이용했음
    그 결과로 자동 생성 산출물은 항상 커밋되어야 함
    둘째, 코드 리뷰에서 모두가 Page Down으로 넘겨버리는 자동 생성 산출물은 문제임. 이런 파일이 저장소에 있다면 누군가 조작하지 않았는지 확인하는 자동 테스트도 있어야 하고, 오래된 자동 생성 파일을 방치하지 않게도 해줌
    셋째, 1과 2의 귀결로 autotools는 나쁘고 autotools 문화도 나쁨
    넷째, Libsystemd는 생태계에 문제임. 이걸 말하면 systemd 혐오자로 치부되지만, 크고 복잡하며 의존성이 많고 대부분의 프로그램은 아주 작은 일부만 씀. 모든 서비스가 초기화 알림을 위해 여기에 의존하도록 장려하는 건 미친 일임
    다섯째, 코드 재사용은 항상 좋고 작은 기능 때문에 큰 라이브러리에 의존해도 좋다는 문화가 있는데 사실이 아님. 의존성은 유지보수 부담이자 보안 위험이고, 가져오는 기능과 저울질해야 함
    여섯째, 배포판 유지보수자가 패키지에 큰 패치를 적용하는 것도 문제임. 실제 유지보수자가 살피지 않는 라이브러리와 애플리케이션의 널리 쓰이는 사실상 포크가 생김
    일곱째, 개발자 입장에서 OSS가 재정적으로 지속 가능해져야 함. Liblzma와 xz-utils는 수천만 설치가 있을 텐데, 정신건강 문제를 겪는 유지보수자 한 명에게 기대고 있었음
    여덟째, 말하기 싫지만 지금은 코드 리뷰와 유지보수권 이양에서 지정학적 고려도 해야 함

    • 지정학적 고려는 도움이 안 됨
      Jia Tan이 실명이라는 증거도 없고, 실제 인물이라는 증거조차 없음
      프로젝트들이 아시아계처럼 들리는 이름의 기여를 받지 않기 시작하면 다음 공격은 Richard Jones라는 이름을 쓰면 그만임
    • Libsystemd에 대해서는 전적으로 동의함
      BSD 세계에서 오면 systemd는 충격적이고, 괴물 같으며 여기저기 촉수를 뻗고 있음
    • 추가로 든 개인적인 관찰이 있음
      소비자도 순진하지만, 소프트웨어 업계 자체도 보안 위협에 대해 순진함
      사회적 익스플로잇은 코드 익스플로잇의 일부임
      FOSS의 “코드를 보는 눈이 많을수록 좋다”는 원칙은 맞지만, 그 눈들이 교육받은 눈일 때만 작동함. FOSS에는 업계의 물질적 지원이 필요함
      MSFT 엔지니어가 이 익스플로잇을 잡았지만, 그래도 Fedora 41, openSUSE, Kali의 일반 공개판에는 들어갔음
      개발 도구 체인과 테스트 과정은 보안을 테스트하도록 설계된 적이 없음. SolarWinds도 참고할 만함: https://www.wired.com/story/the-untold-story-of-solarwinds-t...
    • tarball 배포를 중단하자는 얘기는 왜 릴리스 산출물이 있는지 완전히 무시함
      릴리스 산출물에는 autoconf 스크립트만 들어 있는 게 아님
      바이너리 blob을 릴리스 아카이브에 넣을 이유는 많음. 게임 리소스, 펌웨어 이미지, 테스트 케이스 등이 있음. mpv가 독점 인코더로 생성한 미디어 파일 일부를 테스트 케이스로 포함한다는 얘기도 있었는데, 그건 나쁜 게 아니라 좋은 일임
      잘 유지되는 sqlite는 어디에나 쓰이고 훌륭한 테스트 스위트도 있음. 릴리스마다 tarball을 하나가 아니라 컴파일 단계별로 두 개 배포함. 이걸 중단하는 건 쉽겠지만 패키지 유지보수자의 일을 늘릴 뿐이고, 보안 개선에는 도움이 안 됨
      Debian이 선별된 tarball에서 빌드하는 이유는 사람이 선별하고 잘 알려진 키로 서명하기 때문임. 물론 git에서 빌드할 수도 있지만 그게 상황을 개선할지는 불확실함. 모든 프로젝트가 릴리스 태그에 서명하는 것도 아니고, 서명하더라도 자동화되어 있을 가능성이 더 큼
      우리는 변경이 먼저 upstream 유지보수자에게, 그다음 패키지 유지보수자에게 검토되길 원하고, 이 두 주체가 서로 무관하길 선호함
      이번에는 부패한 upstream 유지보수자가 그 과정을 공격했지만, 그렇다고 upstream 유지보수자를 없애야 한다는 뜻은 아님. 지난 몇 년 동안 이 구조 덕분에 여러 백도어 시도가 막혔고, 신중한 검토 없이 버릴 과정이 아님
      계속 말해온 개선 방향은 그대로임. 재현 가능한 빌드를 더 추구하고, 가능하면 공격 표면과 빌드 복잡도를 낮춰야 하며, 유지보수자를 신뢰하되 작업은 검증해야 함
    • systemd 유지보수자들은 모든 서비스가 libsystemd에 의존하도록 장려한 적이 없음
      오히려 그 지점에서 혼란스러워하며, libsystemd 없이 단순 데이터그램을 구현하는 방법에 대한 문서를 추가하고 있음
      liblzma와 xz-utils의 설치 수는 수천만보다 훨씬 많을 것임. Python, PHP, Ruby 등 많은 언어가 libxml2에 의존하고, libxml2는 liblzma를 사용함. 다른 의존성도 많음
      지정학적 고려는 유지보수자의 일이 아님. OSS는 보증 없이 제공됨
      게다가 “Jia Tan”은 완전히 가짜였을 가능성이 있음. 커밋 타임스탬프를 보면 같은 날에도 시간대가 동유럽에서 아시아로 바뀜. 적어도 정체성 게임을 하고 있었던 건 분명함

  • 이 문제를 발견한 사람이 Azure Postgres에서 일하는 Microsoft 엔지니어였다는 걸 몰랐음
    고맙다 Microsoft, 이제 Azure가 좋아졌음

    • 이제 사람들은 Valgrind의 이상 징후를 모두 살펴봐야 한다고 생각함
      이 문제가 그렇게 발견됐기 때문임
      그런 다음 문제가 된 라이브러리를 보고, 가짜 페르소나가 프로젝트를 장악하는 비슷한 이상치를 찾아야 함
      이런 오류를 무시하는 게 흔한 관행처럼 보임
    • 그건 Microsoft가 고용한 PostgreSQL PGDG 엔지니어임
      이런 식의 포장은 정말 못 참겠음

  • xz의 원래 유지보수자가 Jia Tan을 직접 보거나 최소한 통화도 해보지 않고 책임을 넘긴 것 같음
    이메일이나 GitHub로만 소통하는 게 흔한 일인지 궁금함
    이번 일 이후로 일부 오픈소스 프로젝트 유지보수자들은 더 조심하게 될 것 같음

    • 이메일/GitHub로만 소통하는 건 완전히 흔함
      나도 실제 사람이 누구인지 전혀 모른 채 텍스트만으로 소통하고 라이브러리 유지보수를 넘겨받거나 넘긴 적이 있음
      하지만 이번 일에서 “유지보수자가 더 조심해야 한다”는 결론은 완전히 잘못됐다고 봄
      사람들이 자기 프로젝트에 끌어들이는 것에 대한 책임은 유지보수자가 아니라 그 프로젝트에서 일하는 사람들에게 있음
      유지보수자를 신뢰하든지, 신뢰하지 않든지 둘 중 하나이고, 라이브러리에 의존하기 시작하는 순간 누구를 신뢰하는지 계속 업데이트하겠다고 암묵적으로 동의하는 셈임
    • 지금 구조가 사실상 그렇음
      수백만 회사가 무급 오픈소스 개발자의 작업에 무임승차하고 있음
      그래서 그들이 떠나고 문제가 생기는 건 놀랍지 않음
    • 전화 통화가 무슨 차이를 만들었을까 싶음
      그 사람의 의도에 대해 어떤 신뢰를 더해줬겠음?
    • 이메일/GitHub로만 소통하는 건 맞음
      GitHub 스타 100개부터 3만 개까지 다양한 규모의 오픈소스 프로젝트 여섯 개 정도에 참여했지만, 누구와도 통화한 적 없고 문자 기반 소통이 표준이었음
    • 여러 사람이 작업 속도에 대해 몰아붙이면, 유지보수자가 자신이 문제라고 느끼고 당시 최선이라고 생각한 사람에게 프로젝트를 넘겨도 이상하지 않음
      하지만 개인적으로 안다고 해서 문제가 꼭 해결되지는 않음
      오래전에 익명으로 한 오픈소스 프로젝트에서 일한 적이 있는데, 여기서 이름은 밝히고 싶지 않음. 리드 프로그래머에게는 꽤 잘 아는 것처럼 보이는 공동 유지보수자가 있었음
      그 공동 유지보수자는 나와 나중의 다른 유지보수자들을 계속 가스라이팅하고, 깎아내리고, 아주 작은 버그로 비난해서 떠나게 만들었음. 모욕을 걷어내면 교육적인 Linus Torvalds식 호통과도 달랐음
      리드 유지보수자는 그 주장의 기술적 핵심에 동의했기 때문에 그를 부추겼음
      몇 년 뒤 그 공동 유지보수자는 프로젝트를 적대적으로 장악하려 했고, 예상대로 흘러가지 않았음. 얼마 지나지 않아 여러 사적인 서신이 공개되면서, 그가 항상 그걸 원했고 다른 유지보수자들을 가스라이팅한 것도 그 목표의 일부였음이 드러났음
      두 사람이 서로 알고 있었는데도 이런 일이 벌어졌음

  • 모두가 이 백도어가 일찍 잡혔다고 생각하지만, 이미 목적을 달성했을 수도 있음
    특히 표적이 Kali나 Debian 같은 롤링 릴리스 배포판을 쓰는 개발자였다면 그럴 수 있음

  • “Lasse Collin이 xz Utils를 충분히 자주 또는 빠르게 업데이트하지 않았다”는 식의 밈은 실수였음

  • SSH가 왜 xz를 쓰는지 모르겠음
    그래야 하나? 정말 그렇게 중요한가?

    • OpenSSH는 xz를 쓰지 않음
      OpenSSH가 시작 알림을 제공하려고 libsystemd를 끌어왔고, libsystemd가 liblzma를 끌어왔음. 보통 liblzma의 코드는 OpenSSH 안에 들어가지 않음
      하지만 libsystemd의 의존성으로 빌드되기 때문에, 빌드 스크립트가 libsystemd 및 OpenSSH와 같은 환경에서 실행됨
      공격 페이로드는 liblzma 테스트 디렉터리에 압축 테스트 케이스처럼 위장한 난독화된 바이너리 blob으로 숨겨져 있었음
      git 소스에서 lzma를 컴파일하고 autotools로 빌드 스크립트를 생성할 때는 수상한 일이 없었음. 하지만 배포판 패키저들이 쓰는 소스 tarball에는 autotools가 이미 실행되어 있었고, 공격자는 자동 생성된 읽기 어려운 스크립트 출력을 바꿔치기했음
      그 스크립트는 liblzma가 OpenSSH와 같은 환경에서 컴파일되는지, 그리고 .deb 또는 .rpm 패키지로 들어가도록 컴파일되는지 확인했고, 둘 다 참이면 공격 페이로드를 OpenSSH에 심었음
      이후 페이로드는 OpenSSH가 init 스크립트로 정상 시작됐는지 수동 실행됐는지, 일반적인 디버깅 도구가 있는지 등 여러 검사를 했고, 디버깅 도구 없이 “자연스러운” 부팅처럼 보일 때만 실행 중인 프로세스에 붙었음
      실행 중에는 개인키 검증에 hook을 걸고, 올바른 개인키가 로그인을 시도하면 들어온 패킷의 나머지를 system으로 호출해 root 권한 원격 코드 실행을 제공했음
    • OpenSSH는 xz를 쓰지 않지만, 일부 배포판에서는 systemd와 연동할 때 xz가 사용됨
답변달기