🐚 XZ Utils 백도어 (CVE-2024-3094) — '압축 라이브러리'가 sshd의 문을 열다

1. 배경/역사 — 누구나 쓰지만 아무도 안 보는 라이브러리

XZ Utils는 리눅스에서 파일을 압축하는 아주 흔한 도구이자, 그 핵심 라이브러리인 liblzma를 제공하는 프로젝트다. 거의 모든 리눅스 배포판에 깔려 있지만, 일반 사용자는 물론 대부분의 개발자도 그 존재를 의식하지 않고 지나친다. 이런 '보이지 않는 의존성'이 바로 공급망 공격의 최적 표적이다.

프로젝트는 오랜 기간 Lasse Collin이 사실상 혼자 유지보수하고 있었다. 2021년부터 "Jia Tan"이라는 이름의 기여자가 등장해 꾸준히 패치를 제출하며 신뢰를 쌓았고, 여러 개의 가짜 (sock-puppet) 계정으로 "관리자를 더 두자"는 압박 여론을 만들었다. 결국 그는 프로젝트의 공동 관리자 권한을 얻었고, 그 권한으로 2024년 2월 5.6.0 / 3월 5.6.1 릴리스에 백도어를 심었다.

• 왜 유명한가: 악성코드가 바이너리로 배포된 것이 아니라 '소스 저장소의 빌드 절차'에 숨어 들어갔다. 사용자가 받는 압축 tarball 안에서만 동작하도록 설계돼, 눈으로 코드를 읽는 리뷰를 통째로 우회했다. '우리가 읽는 코드'와 '실제로 컴파일되는 코드'가 다를 수 있다는 사실을 세상에 각인시킨 사건이다.
• 2년짜리 장기전: 단순 익스플로잇이 아니라 인간 관계를 공략하는 사회공학 캠페인이었다. 이는 오픈소스 유지보수자의 번아웃과 '관리자 부족'이라는 구조적 약점을 정면으로 겨냥한 최초의 대규모 사례 중 하나다.
• 아이러니한 발견: 2024-03-29, Microsoft에서 일하던 PostgreSQL 개발자 Andres Freund가 Debian 개발판에서 'SSH 접속이 이상하게 느리고 CPU를 잡아먹는다, Valgrind가 에러를 뱉는다'는 성능 문제를 추적하다 백도어를 찾아냈다. 보안 스캐너가 아니라 느린 SSH 하나가 세계를 구한 셈이다.
• 업계 파장: GitHub는 프로젝트 저장소를 일시 비활성화했고, Red Hat·SUSE·Debian 등은 즉시 이전 버전으로 롤백했다. Canonical은 Ubuntu 24.04 LTS 베타를 1주일 늦추고 전체 패키지를 바이너리 재빌드했다.

2. 감염·전파 경로 — '사람'을 뚫고 '빌드 서버'로 들어가다

이 사건의 '전파 경로'는 네트워크가 아니라 신뢰와 배포 파이프라인이다. 악성코드는 사용자 PC로 직접 배포되지 않고, 배포판이 소스를 빌드하는 순간 살아난다.

• ① 신뢰 축적(2021~2023): Jia Tan이 정상 패치를 계속 제출하고, 가짜 계정들로 "새 관리자가 필요하다"는 여론을 조성해 공동 관리자 자리를 얻는다. 악성코드가 아니라 신뢰를 먼저 심는다.
• ② 은닉 주입(2024-02~03): 5.6.0/5.6.1의 tarball에만 build-to-host.m4의 변조 버전을 넣는다. git 저장소에는 정상 스크립트가 있어 리뷰에서 아무 문제가 안 보인다.
• ③ 빌드 시점 실행: 배포판이 tarball을 받아 빌드할 때, 변조된 m4 스크립트가 tests/files/ 안의 '정상 테스트 데이터'로 위장한 파일을 디코드해 악성 오브젝트를 만들어 정상 오브젝트를 덮어쓴다.
• ④ 배포판 패키징: 결과물은 서명된 정상 패키지로 빌드돼 배포된다. 빌드 이후 단계의 어떤 서명·해시 검증도 이 단계에서의 변조는 잡지 못한다.
• ⑤ sshd에서 발동: 피해 시스템의 sshd 프로세스가 liblzma를 로드하는 순간(systemd 경유), 백도어가 열린다. 이후 특정 Ed448 개인키를 가진 공격자가 비밀번호·인증 없이 원격에서 관리자 권한을 얻을 수 있었다.

즉 전파의 핵심은 '테스트 데이터로 위장 → 빌드 시 실행 → 정상 패키지로 위장'이라는 3중 위장이다. 그래서 취약한 버전이 배포판에 들어가기 전까지 누구도 눈치채지 못했다.

3. 동작 원리 상세 분석 — 왜 압축 라이브러리가 SSH를 건드리나

가장 많이 나오는 질문이 "압축 라이브러리가 어떻게 SSH 인증을 우회하나?"다. 답은 liblzma가 sshd 프로세스 안에 '같이 로드된다'는 점에 있다.

• 연결 고리(systemd): 여러 배포판은 OpenSSH를 패치해 systemd 알림을 쓰게 한다. sshd → libsystemd → liblzma 순으로 라이브러리가 함께 로드된다. 즉 liblzma의 코드가 sshd의 주소 공간 안에서 실행된다.
• IFUNC 리졸버 악용: liblzma의 CRC64 함수는 IFUNC(Indirect Function)로 구현돼 있다. IFUNC는 로더가 프로그램을 시작할 때 '실제 함수 주소를 계산하는 리졸버'를 실행한다. 백도어는 바로 그 리졸버에 코드를 심어, main()이 실행되기도 전에 공격자 코드가 돌게 만들었다.
• OpenSSL 후킹: 프로세스에 진입한 백도어는 OpenSSL의 RSA_public_decrypt() 등 인증 관련 함수를 가로챈다. 정상 인증 흐름 사이에 끼어들어, 공격자가 준비한 특정 Ed448 키로 서명된 값을 확인하면 인증을 통과시켜 버린다. 결과적으로 비밀번호 없이 관리자 접근이 가능해진다.
• 빌드 시점 트리거: 주입 스크립트는 x86-64 Linux + glibc + GCC로 tarball을 빌드할 때만 동작하도록 조건을 걸었다. Debian·RPM 패키징 환경을 정확히 겨냥한 '선별적' 설계였다.
• 다단계 난독화: 무작정 디코드하면 깨지도록, m4 매크로 → 압축 파일 → 두 단계 셸 스크립트 → 최종 오브젝트로 이어지는 여러 겹의 위장을 쌓아 정적 검사를 회피했다.

항목	내용
주입 경로	릴리스 tarball의 build-to-host.m4 (git 저장소에는 없음)
위장 수단	tests/files/의 '정상 테스트 데이터'로 위장한 압축 파일
실행 시점	패키징 빌드 시(오브젝트 교체) + sshd 시작 시(IFUNC 리졸버)
후킹 대상	OpenSSL RSA_public_decrypt 등 인증 함수
인증 우회 키	공격자가 보유한 특정 Ed448 개인키
발동 조건	x86-64·glibc·GCC·tarball 빌드 + sshd의 liblzma 로드

4. 피해 규모/영향 — '대재앙'이 될 뻔한 사건

• 영향 범위는 한정적: 백도어는 5.6.0·5.6.1 두 버전에만 있었고, 안정판 배포판은 대개 5.4.x대를 쓰고 있어 취약하지 않았다. Debian bookworm(5.4.1), Ubuntu 안정판, macOS/Homebrew(sshd가 liblzma를 로드하지 않음) 등은 영향 없음.
• 취약했던 곳: Fedora Rawhide·Fedora 41, Debian sid(개발판), openSUSE Tumbleweed, Kali 등 롤링/개발판이 주 표적이었다. 이들은 공격자 입장에서 '다음 안정판에 들어가기 전 미리 심어두는 발판'이었다.
• 왜 실피해가 없었나: 5.6.0 공개(2월)부터 발견(3월 말)까지 약 한 달. 만약 발견이 몇 달만 늦었고 백도어가 다음 안정판에까지 들어갔다면, 전 세계 수백만 대의 서버가 동일한 키 하나로 뚫릴 수 있었다 — '역사상 최악의 공급망 사고'가 될 뻔했다.
• 경제·운영 비용: 각 배포판이 긴급 롤백·재빌드·재배포를 수행했고, Canonical은 Ubuntu 24.04 LTS 베타를 1주 연기하고 전체 패키지를 재빌드했다. 수많은 기업이 '내 시스템이 5.6.x를 쓰는가'를 확인하느라 긴급 점검에 들어갔다.
• 주요 프로젝트 파급: 같은 공격자가 xz 외에도 libarchive, kmod, 리눅스 커널 등 다른 오픈소스 프로젝트에 유사한 방식으로 접근한 정황이 보고됐다. 단일 프로젝트가 아니라 '오픈소스 생태계 전체'를 노린 캠페인이었다.
• 귀속: 미국 보안 연구자 Dave Aitel 등은 APT29(러시아 SVR 연계) 패턴과 유사하다고 지적했으나, 공식 귀속은 아직 없다. 국가 배후 또는 그에 준하는 자원을 가진 행위자로 널리 추정된다.

5. PoC (개념 증명) — 교육용 모의 재현 4종

아래 코드는 실제 악성코드가 아니며, 위에서 설명한 메커니즘을 안전한 모의 객체로 재현한 것입니다. 실제 백도어 페이로드·실제 후킹 코드·실제 우회 키는 포함하지 않습니다. 격리된 랩 환경(인터넷 차단 VM)에서만 실행하세요.

PoC ① 빌드 시점 주입 — '테스트 데이터'가 오브젝트로 바뀌는 순간

import base64, zlib
# 저장소에는 '무해한 테스트 데이터'처럼 보이도록 압축+base64로 위장해 커밋한다.
_MOCK_PAYLOAD = b"[MOCK] replace crc64_fast.o with attacker object"  # 교육용 모의 문자열
CAMOUFLAGED = base64.b64encode(zlib.compress(_MOCK_PAYLOAD))
print("저장소에 커밋된 '테스트 파일':", CAMOUFLAGED[:48].decode(), "...")

# 빌드 스크립트가 실행되는 순간(=autoreconf / make) 페이로드가 꺼내진다.
def build_time_extract(blob):
    return zlib.decompress(base64.b64decode(blob))

injected = build_time_extract(CAMOUFLAGED)
print("빌드 시점에 꺼내진 내용:", injected.decode())

# 정상 빌드 산출물(clean .o)을 이 내용으로 '교체'한다 (모의)
def compile_step(real_obj, injected):
    return injected

print("빌드 산출물:", compile_step(b"crc64_fast.o (clean)", injected).decode())

실행 결과(이번 실행 실제 출력):

저장소에 커밋된 '테스트 파일': eJyL9vV39o5VKEotyElMTlVILko2M4lPSywu0ctXKM8syVBI ...
빌드 시점에 꺼내진 내용: [MOCK] replace crc64_fast.o with attacker object
빌드 산출물: [MOCK] replace crc64_fast.o with attacker object

PoC ② IFUNC 리졸버 — 'main 실행 전'에 코드가 도는 구조

/* hook_demo.c : IFUNC로 심볼을 가로채는 '기법'만 재현 (실제 암호 함수는 건드리지 않음)
 * build: gcc -O0 -o hook_demo hook_demo.c && ./hook_demo */
#define _GNU_SOURCE
#include <stdio.h>

static int real_check(int x) { return x * 2; }            /* 정상 구현 */

/* 심볼이 '처음 참조되는 순간' 로더가 호출하는 리졸버 = 백도어 진입점(모의) */
static int (*resolve_check(void))(int) {
    fprintf(stderr, "[hook] 라이브러리 로드 시점에 리졸버 실행 -> 공격자 코드 진입(모의)\n");
    return real_check;
}

/* check()를 IFUNC로 선언: 로더가 시작될 때 resolve_check()를 호출해 실제 함수 주소를 얻는다 */
int check(int) __attribute__((ifunc("resolve_check")));

int main(void) {
    printf("check(21) = %d\n", check(21));
    return 0;
}

실행 결과(이번 실행 실제 출력): — main()이 출력하는 값보다 '로드 시점' 메시지가 먼저 나오는 것에 주목.

[hook] 라이브러리 로드 시점에 리졸버 실행 -> 공격자 코드 진입(모의)
check(21) = 42

PoC ③ '왜 어떤 시스템만 영향받나' — sshd의 liblzma 연결 점검

# xz 백도어는 liblzma가 sshd 프로세스에 '로드될 때만' 동작한다.
# systemd 배포판은 sshd -> libsystemd -> liblzma 순으로 라이브러리를 끌어온다.
# 아래는 '내 sshd에 liblzma가 로드되는가'를 확인하는 읽기 전용 점검 (격리 랩 전제).
echo "== liblzma/xz 패키지 =="
(pacman -Q xz 2>/dev/null || dpkg -l 'liblzma*' 2>/dev/null | awk '/^ii/{print $2,$3}') 
echo "== sshd의 liblzma 연결 =="
ldd "$(command -v sshd 2>/dev/null)" 2>/dev/null | grep -i lzma || echo "liblzma 미연결 (영향 없음)"

실행 결과(이번 실행 실제 출력 — Arch Linux 랩 VM):

== liblzma/xz 패키지 ==
xz 5.8.3-1
== sshd의 liblzma 연결 ==
liblzma 미연결 (영향 없음)

이 랩 환경의 xz는 이미 패치된 5.8.3이고, sshd에 liblzma가 연결되지 않아 두 조건 모두 안전하다. 실제 사건에서는 이 '연결' 여부가 취약/비취약을 갈랐다.

PoC ④ 공급망 검증 — '릴리스 tarball'과 'git'의 차이 찾기

import difflib
# git 저장소에는 없고 '배포 tar 파일'에만 들어있던 변조 라인을 찾아내는 검증 (모의)
git_version = """AC_DEFUN([AM_INIT_AUTOMAKE],
[ ... 정상적인 빌드 설정 ... ])
# (정상) 특별한 은닉 동작 없음"""

tarball_version = """AC_DEFUN([AM_INIT_AUTOMAKE],
[ ... 정상적인 빌드 설정 ... ])
# --- 아래는 tarball에만 존재하는 은닉 라인 (문서화된 실제 패턴을 축약) ---
gl_am_configmake=`grep -aErls "#{4}[[:alnum:]]{5}#{4}$" $srcdir/ 2>/dev/null`
xz -dc $srcdir/tests/files/good-large_compressed.lzma | sed ... > liblzma_la-crc64-fast.o"""

injected = [l for l in tarball_version.splitlines() if l not in git_version.splitlines()]
print("tarball에만 존재하는 의심 라인:", len(injected), "개")
for l in injected:
    print("  +", l.strip()[:72])

실행 결과(이번 실행 실제 출력):

tarball에만 존재하는 의심 라인: 3 개
  + # --- 아래는 tarball에만 존재하는 은닉 라인 (문서화된 실제 패턴을 축약) ---
  + gl_am_configmake=`grep -aErls "#{4}[[:alnum:]]{5}#{4}$" $srcdir/ 2>/dev/null`
  + xz -dc $srcdir/tests/files/good-large_compressed.lzma | sed ... > liblzma_la-crc64-fast.o

6. 방어 방법/교훈 — 무엇을 배우나

• '읽은 코드'와 '빌드된 코드'가 같다고 믿지 말라(최우선): 리뷰는 git 트리를 보지만, 실제 빌드는 배포 tarball을 본다. 릴리스 tarball과 git 태그의 빌드 스크립트를 자동으로 diff하고, 배포판은 upstream tarball을 그대로 신뢰하지 말고 재현 가능한 빌드로 검증해야 한다.
• 재현 가능한 빌드(Reproducible Builds): 소스에서 동일한 바이너리가 나오는지 여러 독립 환경에서 검증하면 빌드 시점 주입이 드러난다. Debian·Fedora가 진행 중인 이 프로젝트가 바로 이 사건의 구조적 해법이다.
• 빌드 의존성도 실행 표면이다: sshd에 liblzma를 끌어오는 연결 고리 하나가 곧 공격 표면이었다. 불필요한 라이브러리 링크를 줄이고, 네트워크 서비스 프로세스의 라이브러리 구성을 최소화하라.
• 오픈소스 '사람' 리스크 관리: 관리자 권한이 한 사람에게 집중되고 소진되면 공격자가 사회공학으로 그 자리를 대체할 수 있다. 기업·재단의 유지보수자 지원·펀딩과 다중 관리자·서명 체계가 실질적 방어다.
• 공급망 SBOM·아티팩트 서명: 사용 중인 라이브러리 목록(SBOM)과 릴리스 아티팩트의 독립 서명·투명성 로그(Sigstore 등)로 '누가 무엇을 언제 만들었나'를 검증한다.
• '느린 SSH'도 신호다: 이상탐지는 익스플로잇만 잡지 않는다. CPU 급증·지연·Valgrind 경고 같은 미세한 성능 이상이 최악의 사고를 막은 단서였다. 기저 성능과 무결성을 모니터링하라.
• 신속한 롤백 체계: 이번엔 한 달 만에 발견돼 큰 피해가 없었다. 배포판·기업 모두 취약 버전을 즉시 식별·롤백·재빌드할 수 있는 절차를 평소에 준비해야 한다.

7. 출처

• Andres Freund — oss-security: backdoor in upstream xz/liblzma leading to ssh server compromise (2024-03-29, 최초 공개) — openwall.com (oss-security)
• NIST NVD — CVE-2024-3094 (CVSS 3.1 10.0, 공격 벡터) — nvd.nist.gov/vuln/detail/CVE-2024-3094
• Red Hat — Urgent security alert for Fedora Linux 40 and Fedora Rawhide users (2024-03-29) — redhat.com
• Lasse Collin — Remove the backdoor found in 5.6.0 and 5.6.1 (CVE-2024-3094) (수정 커밋·5.6.2 릴리스) — github.com/tukaani-project/xz
• Wikipedia — XZ Utils backdoor (타임라인·영향 배포판·사회공학 캠페인·귀속 논의 개요) — en.wikipedia.org/wiki/XZ_Utils_backdoor
• Andy Greenberg (Wired) — The Mystery of 'Jia Tan,' the XZ Backdoor Mastermind — wired.com
• Oxide Computer Company — Oxide and Friends: Discovering the XZ Backdoor with Andres Freund (발견 과정 상세) — youtube.com

※ 본문의 PoC 코드는 구조 이해 목적의 교육용 모의 코드이며, 실제 백도어 페이로드·실제 오브젝트 파일· 실제 Ed448 우회 키·실제 OpenSSL 후킹 코드는 포함하지 않습니다. 모든 실습은 인터넷과 분리된 격리 랩 VM을 전제로 하며, 실제 시스템·타인 자산에 대한 실행은 불법입니다.

함께 읽기: 🦅 SolarWinds SUNBURST (2020) — 공급망을 무기로 신뢰를 뚫은 백도어 · 🌐 Log4Shell (2021) — 오픈소스 라이브러리 한 줄이 공급망을 흔든 제로데이 · Malware Deep-Dive: MOVEit / Cl0p (CVE-2023-34362) — '신뢰하던 소프트웨어'로 조직을 대량 유출 · ⚡ Industroyer / CrashOverride — 프로토콜을 그대로 말한 산업제어 파괴형 공격