NixOS 부트스트랩 시드의 GNU strip 하나로 최종 설치 이미지 거의 모든 바이너리를 감염시키는 Trusting Trust 공격

논문 내용에 AI는 전혀 없는데, 모든 얘기에 AI를 끼워 넣는 건 지겹다.

이건 결국 CI 머신에 악성코드가 있으면 산출물을 감염시킬 수 있다는 얘기임. strip 트로이목마 대신 최종 산출물이 나올 때까지 기다렸다 감염시키는 평범한 악성코드여도 됨.

깨끗한 소스에서 strip을 다시 빌드해도 해결 안 됨. 부트스트랩 시드의 strip이 자기 대체본을 변조하고, 그 대체본이 계속 전파하니 출처 기록도 정상처럼 보일 수 있음.

Thompson 본인도 컴파일러 말고 어셈블러, 로더, 하드웨어 마이크로코드를 택할 수 있었다고 했음. 잘 구현한 사례이긴 하지만 공격 개념 자체가 새롭진 않음.

그래도 이 공격을 컴파일러 고유 위협으로 보는 인식은 널리 퍼져 있다고 봄. Karger는 MULTICS 보안 평가에서 Thompson보다 먼저 이런 공격을 설명했음.

Wheeler의 Diverse Double-Compiling은 환경까지 다양화하면 strip에도 적용 가능해 보임. 오염된 배포판 환경에서 만든 A와 별도 OS, 하드웨어, strip 환경에서 만든 B, B로 다시 만든 C를 비교해 A와 C가 다르면 공격을 잡을 수 있음.

서로 다른 환경에서 만든 바이너리를 비교하는 일 자체가 어렵지 않나. 동일한 환경의 재현 빌드도 아직 해결하기 까다로운 문제로 앎.

이건 사실상 ELF 실행 파일을 감염시키는 바이러스임. 새롭다고 보긴 어려움.

현재 x86_64-linux와 i686-linux의 nixpkgs 부트스트랩 시드는 25개 번들 바이너리가 아니라 181바이트임. 논문이 출간됐을 때는 aarch64-linux, riscv64-linux 같은 x86 외 플랫폼에는 여전히 적용될 수 있었고, 다른 Linux 플랫폼에도 일반화할 수 있을 듯함.

1980년대 TCSEC 시절 해법은 요구사항부터 코드까지 추적 가능하고, 보안 정책을 증명하며, 고객이 신뢰하는 도구로 로컬에서 빌드할 수 있는 시스템이었음. 하지만 그런 방식은 비용과 출시 기간 때문에 대부분의 소프트웨어에 적용하기 어려움.

ELF를 다루는 strip만 문제가 아님. strings, strace, objdump, nm, ldd 같은 명령도 백도어 대상으로 삼을 수 있음.

Nix는 배포판 전체를 처음부터 부트스트랩할 수 있지만, 전통적 방식은 최초 컴파일러를 미리 빌드된 바이너리 시드에 의존함. 재현 빌드와 시드 축소는 그 신뢰 경계를 줄이려는 시도이고, Guix는 이미 전체 소스 부트스트랩을 지원함.

live-bootstrap의 작은 시드 단계와 실행 과정을 T 다이어그램으로 검토했음. 더 큰 대신 문서화가 나은 시드로 단계를 줄이는 작업도 했고 x86_64와 arm64를 지원하며 RISC-V 작업도 시작됐음.