Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation

• 원문: arXiv:2607.24888
• 발표: SCORED 2026
• 저자: Julien Malka 외
• Tags: TrustingTrust, Linux, NixOS, 부트스트랩, 공급망, ELF, strip, 재현빌드, 컴파일러신뢰, 바이너리변조

본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.

한눈에 보기

배포판 bootstrap seed의 실행 파일 하나인 strip을 교체하면, 이후 소스에서 strip을 다시 빌드해도 감염이 자기 자신에게 전파되고 거의 모든 하위 ELF에 marker를 주입할 수 있음을 NixOS ISO 빌드로 보였다. 1,199개 package output의 사용자 실행 ELF 3,799개 중 CLI 대상 3,791개, 그중 3,790개가 marker를 출력했다. 강력한 실증이지만 “seed 바이너리 하나를 이미 바꿀 수 있다”는 공급망 침해가 선행되고 payload는 무해한 marker다.

연구 배경

Ken Thompson의 trusting-trust 공격은 컴파일러 바이너리가 자신의 소스에는 없는 백도어를 후대 컴파일러에 전파하는 사고실험이다. 현대 배포판도 최초 빌드에는 미리 만들어진 bootstrap binary를 신뢰한다. 연구는 컴파일러 대신 거의 모든 바이너리에 적용되는 strip을 successor로 선택해 배포판 전체 전파를 보인다.

공격 모델 / 전제 조건

공격자는 소스와 build recipe를 바꿀 수 없지만 bootstrap seed 안의 실행 파일 하나를 교체할 수 있다. 이는 배포 서버·미러·릴리스 서명·검수 과정 중 하나가 이미 침해됐다는 강한 전제다. 피해자는 해당 seed에서 전체 배포판을 빌드한다. 공격은 현재 구현상 x86_64 little-endian ELF와 Nix sandbox 동작에 맞춰져 있다.

비판적 검토 / 아쉬운 점

1. 초기 권한의 크기: bootstrap 실행 파일 교체가 가능하면 이미 심각한 공급망 침해다. 이 연구의 추가 기여는 초기 침해가 소스 재빌드 후에도 퍼지는 경로이지 최초 침입 방법이 아니다.
2. 악성 능력의 직접 입증 범위: payload는 marker 출력이며 네트워크·credential 탈취·권한 상승을 구현하지 않았다. 동일 권한 코드 실행으로 더 할 수 있다는 주장은 합리적이나 영향별 실증은 별도다.
3. 플랫폼 특화: NixOS·binutils 2.44·x86_64와 PT_NOTE 가용성에 의존한다. Debian/Fedora, 다른 linker·strip, static PIE, 다른 아키텍처의 전파율이 필요하다.
4. 탐지 가능성: PoC는 파일명·marker와 ELF entry/segment 변화를 남긴다. 완전 은닉형 공격이 기존 재현 빌드·ELF 정책을 얼마나 우회하는지는 추가 비교가 필요하다.

핵심 Root Cause

깨진 불변조건은 “도구를 소스에서 다시 빌드하면 bootstrap binary에 대한 신뢰가 끊긴다”는 가정이다. 실제 빌드 그래프에는 이전 도구 C1이 새 복사본 C2를 처리하고, C2가 이후 같은 연산을 수행하는 successor edge가 있다. strip은 빌드 결과 대부분에 반복 적용되므로 감염된 strip0가 strip1을 감염시키고 strip1이 다음 세대를 감염시킨다.

핵심 공격 원리

parasite를 ELF 뒤에 추가하고 기존 PT_NOTE program header를 executable PT_LOAD로 바꾼다. e_entry를 parasite로 돌리고 section header 위치를 재배치한다. parasite는 원래 entry 전에 실행되고 레지스터를 복원해 정상 동작을 유지한다. basename이 strip이고 Nix build 내부이면 대상 ELF를 다시 감염시켜 자기 전파한다.

공격 흐름

1. bootstrap seed의 strip0를 감염본으로 교체한다.
2. strip0가 binutils 빌드 산출물의 strip1을 처리하며 parasite를 주입한다.
3. strip1은 후속 패키지의 ELF를 strip할 때 같은 감염을 복제한다.
4. 감염은 runtime closure를 따라 ISO의 사용자 실행 파일 대부분으로 전파된다.
5. 테스트 PoC는 실행 시 marker를 출력한 뒤 원래 프로그램으로 제어를 돌린다.

성공 조건 / 실패 조건

bootstrap seed 변조, successor edge, strip 대상 ELF, spare PT_NOTE, 호환되는 ET_EXEC 또는 interpreter가 있는 ET_DYN이 필요하다. disable-strip 패키지, shared library, 호환되지 않는 정적 PIE, PT_NOTE 부재, 다른 endian·아키텍처에서는 실패하거나 제외된다. 독립 bootstrap으로 만든 artifact와 비교하거나 seed를 강하게 attest하면 초기 단계에서 차단 가능하다.

연구진의 실험 환경

nixpkgs revision fef9403a3e4d, binutils 2.44, x86_64-linux에서 graphical ISO를 빌드했다. 결과 크기는 6.16GB이고 runtime closure는 1,199개 package output으로 구성됐다. 정상 기능 테스트도 수행해 감염이 일반 동작을 깨지 않는지 확인했다.

주요 실험 결과

사용자 실행 가능한 ELF 3,799개를 찾았고 CLI 대상은 3,791개였다. 이 중 3,790개가 marker를 출력했다. Firefox는 disable-strip 설정 때문에 유일하게 감염되지 않았다. 전체 NixOS 빌드와 기능 테스트는 성공했다. 이 수치는 광범위한 코드 도달을 증명하지만 marker 이상의 악성 결과 성공률은 아니다.

실제 발견된 취약점 / 사례

특정 CVE라기보다 bootstrap trust graph의 구조적 취약점이다. strip, patchelf, install/cp처럼 다음 세대 바이너리를 처리하면서 이후에도 동일 역할을 하는 도구가 후보가 된다. 연구진은 실제 NixOS ISO에서 strip successor edge를 악용했다.

저자 주장 vs 실제 증명 범위

“한 bootstrap binary로 전체 배포판에 전파”는 NixOS 사례에서 3,790개 ELF marker로 강하게 입증됐다. “임의 백도어 가능”은 동일 권한의 native code 실행에서 합리적으로 추론되지만 데이터 탈취·root 권한·원격 제어는 직접 보이지 않았다. “Linux 배포판 전체”라는 제목을 다른 배포판 전반으로 일반화하면 안 된다.

기존 공격 / 기존 점검 방식과의 차이

전통 trusting-trust는 compiler가 compiler를 감염시킨다. 이 연구는 빌드 후처리 도구의 successor edge를 이용해 컴파일 언어와 무관하게 ELF 전반으로 퍼진다. 소스 감사나 동일 seed 기반 reproducible build만으로는 같은 감염 결과를 재생산할 수 있어 충분하지 않다.

연구의 한계와 주의해서 볼 부분

little-endian ELF, spare PT_NOTE, 특정 파일 유형과 Nix 빌드 문맥에 묶인다. 감염 표시가 명시적이고 anti-analysis는 없다. 저자가 인정한 구현 한계와 별도로, 독립 seed·다양한 배포판·서명 투명성 환경에서의 탐지율 비교가 빠져 있다.

공개 PoC / Exploit / Tool / Artifact 분석

공식 GitHub 저장소는 공개되어 있으며 fake_strip.c, injector.c, parasite.c, Nix 설정과 재현 스크립트를 포함한다. MIT 라이선스이고 저장소 안내대로 Nix 환경에서 PoC와 ISO 빌드를 재현할 수 있다. 공개 코드는 무해한 marker를 사용하며 네트워크 연결·명령 실행·권한 상승 payload를 제공하지 않는다.

레드팀 / 모의해킹에서 어떻게 활용할까

실제 배포 seed를 바꾸지 말고 격리된 복제 build graph에서 canary marker로 successor edge를 찾는다. bootstrap tool hash, 새로 빌드된 동일 도구, 하위 artifact의 e_entry·PT_NOTE 변화를 비교한다. marker가 격리 영역 밖 artifact에 나타나거나 서명 저장소로 전파되면 즉시 중단한다.

실제 점검 시 추가할 체크리스트

• bootstrap seed의 최소 구성·해시·서명·provenance를 독립 보관하는가
• 서로 다른 bootstrap chain으로 동일 artifact를 교차 빌드하는가
• strip·patchelf·install처럼 successor edge를 갖는 도구를 목록화했는가
• e_entry, PT_NOTE→PT_LOAD, 비정상 appended data를 검사하는가
• disable-strip 예외와 unstripped artifact도 비교하는가
• 재현 빌드가 동일 seed 의존성을 공유하지 않는가

실무 가치 평가

배포판·컴파일러·빌드 시스템 운영자에게 매우 가치가 높다. “소스가 깨끗하고 빌드가 재현된다”는 사실만으로 bootstrap 신뢰를 해결할 수 없음을 구체적 그래프로 보여준다. 일반 웹 모의해킹보다 소프트웨어 공급망·릴리스 엔지니어링 점검에 적합하다.

결론

신뢰의 뿌리인 bootstrap binary는 소스 재빌드만으로 자동 정화되지 않는다. successor edge를 찾아 끊고, 독립 bootstrap과 artifact 투명성·서명·ELF 구조 검사를 결합해야 한다.