소스코드가 깨끗해도 해킹된다: 리눅스 전체를 속이는 ‘Trusting Trust’ 공격

우리는 공개된 소스코드를 확인하면 그 프로그램을 믿을 만하다고 생각하기 쉽습니다. 하지만 코드를 기계어로 옮기는 컴파일러가 거짓말한다면 얘기가 달라집니다. Trusting Trust 공격이 무서운 건 리눅스 배포판 전체의 신뢰 기반을 흔들 수 있기 때문입니다.

깨끗한 소스코드가 깨끗한 프로그램을 보장하지 않는다

이 공격은 1984년 켄 톰프슨이 발표한 글을 통해 널리 알려졌습니다. 요점은 컴파일러 안에 악성 동작을 숨기는 것입니다.

감염된 컴파일러는 특정 프로그램을 발견하면 몰래 백도어를 심습니다. 예를 들어 로그인 프로그램을 컴파일하면서 공격자의 비밀번호도 받아들이는 코드를 끼워 넣을 수 있습니다.

여기까지만 보면 컴파일러 소스를 조사하면 될 듯합니다. 하지만 공격자는 한발 더 나아갑니다. 컴파일러가 자기 자신을 컴파일할 때 악성 기능을 다음 컴파일러 바이너리에 다시 심게 만드는 것입니다.

그 뒤 소스코드에서 문제의 코드를 지워도 백도어는 그대로 남습니다. 사람이 읽는 소스는 깨끗한데 실제로 실행되는 파일은 오염된 상태입니다. 번역본에 거짓말을 넣은 다음, 번역가의 교본에서는 그 흔적을 지워 버리는 셈입니다.

컴파일러 하나가 배포판 전체의 문제로 번지는 과정

리눅스 배포판에서는 수천 개의 패키지를 자동으로 빌드합니다. 이때 컴파일러와 링커, 패키지 도구, 설치 스크립트가 쓰입니다. 이들이 서로 얽혀 돌아가는 거대한 생산 라인입니다.

공격자가 핵심 컴파일러나 빌드 도구를 장악하면 원하는 특정 패키지에만 악성 코드를 심을 수 있습니다. 패키지 관리자나 서명 도구까지 노리면 피해 범위는 더 넓어집니다. 이후 만들어지는 프로그램도 줄줄이 영향을 받을 수 있습니다.

물론 컴파일러 하나를 감염시켰다고 모든 리눅스 배포판이 자동으로 장악되는 것은 아닙니다. 공격자는 빌드 서버 접근권한을 확보하고 배포판의 도구 구성과 업데이트 경로까지 파악해야 합니다. 장기간 들키지 않고 숨어 있을 기술도 필요합니다.

그렇다고 현재 공개적으로 확인된 리눅스 배포판 전체 감염 사례가 있다는 뜻도 아닙니다. 최근 한 달 동안 공개 커뮤니티에서 확인할 만한 새로운 논의도 거의 없었습니다. 이번 주제는 새로 확인된 사고라기보다 오래된 공격 개념이 현대의 중앙화된 빌드 시스템에서 얼마나 큰 피해를 낼 수 있는지 보여주는 위협 모델에 가깝습니다.

전자서명과 재현 가능한 빌드도 만능은 아니다

패키지 전자서명은 파일이 배포되는 동안 바뀌지 않았음을 확인해 줍니다. 하지만 빌드 단계에서부터 파일이 오염됐다면 얘기가 다릅니다. 정상 권한으로 악성 바이너리에 서명하면 사용자는 그 파일을 정상 업데이트로 받아들이게 됩니다.

재현 가능한 빌드는 같은 소스와 환경으로 빌드했을 때 완전히 똑같은 결과물이 나오는 체계입니다. 공식 바이너리와 독립적으로 만든 결과가 다르다면 이상 징후를 알아챌 수 있습니다.

문제는 두 빦드가 같은 감염 컴파일러를 쓰면 똑같은 악성 결과가 나올 수 있다는 점입니다. 결과가 일치했다는 이유만으로 컴파일러까지 정직했다고 단정할 수는 없습니다. 두 사람이 같은 거짓 답안지를 보고 있다면 결론도 똑같이 나옵니다.

따라서 중요한 건 재현 횟수가 아니라 신뢰 기반의 다양성입니다. 서로 다른 조직과 운영체제, 컴파일러 계열을 이용해 결과를 교차 검증해야 합니다.

방어의 핵심은 신뢰를 한곳에 몰아주지 않는 것

대표적인 검증 방법으로 다양한 이중 컴파일이 있습니다. 의심되는 컴파일러를 서로 다른 계보의 신뢰 가능한 컴파일러로 다시 만든 뒤, 여러 단계에서 나온 결과물을 비교하는 방식입니다. 결과가 일치하는지 확인하면 배포된 컴파일러와 공개 소스의 관계를 검증할 수 있습니다.

배포판 운영자는 독립 빌드 기관도 늘려야 합니다. 공식 빌드 서버와 관계없는 여러 주체가 같은 패키지를 재생산하고 결과를 공개하면, 공격자는 모든 환경을 동시에 속여야 합니다.

빌드 기록도 빠짐없이 남겨야 합니다. 파일을 만들 때 어떤 소스와 도구, 의존성을 썼는지 추적할 수 있어야 합니다. 핵심 패키지는 한 사람이나 한 서버의 승인만으로 배포되지 않도록 권한을 나누는 편이 좋습니다.

컴파일러보다 아래쪽도 살펴봐야 합니다. 부트스트랩용 바이너리와 운영체제, 펌웨어, 하드웨어까지 신뢰의 사슬에 들어가기 때문입니다. 결국 공급망 보안은 “어디까지 믿을 것인가”보다 “그 믿음을 어떻게 독립적으로 검증할 것인가”의 문제입니다.

우리가 확인해야 할 것은 코드만이 아니다

Trusting Trust 공격은 오픈소스가 무의미하다는 이야기가 아닙니다. 소스를 공개하는 것만으로는 충분하지 않고, 빌드 과정과 도구까지 검증해야 한다는 경고입니다. 여러분이 쓰는 소프트웨어는 누가 만들었고, 그 사람이 사용한 컴파일러는 또 누가 검증했을까요?