켄 톰슨 해킹 (1984)

Ken Thompson은 1984 년에 컴파일러 바이너리 (및 * nix 시스템의 로그인 스크립트와 같은 다른 컴파일 된 소프트웨어)를 손상시키는 방법을 설명했습니다. 최신 컴파일이이 보안 결함을 해결했는지 궁금합니다.

간단한 설명:

두 가지 결함을 포함하도록 컴파일러 코드를 다시 작성하십시오.

• 자체 바이너리를 컴파일 할 때 컴파일러는 이러한 결함을 컴파일해야합니다
• 미리 선택된 다른 코드 (로그인 기능)를 컴파일 할 때 임의의 백도어를 컴파일해야합니다

따라서 컴파일러는 정상적으로 작동합니다-로그인 스크립트 또는 이와 유사한 것을 컴파일 할 때 보안 백도어를 만들 수 있으며 향후 새로운 버전을 컴파일 할 때 이전 결함을 유지 하며 결함은 컴파일러에만 존재합니다 바이너리 이므로 감지하기가 매우 어렵습니다.

질문 :

웹에서 이에 대한 답변을 찾을 수 없습니다.

• 이것은 적시 컴파일과 어떤 관련이 있습니까?
• * nix 시스템에서 로그인을 처리하는 프로그램과 같은 기능이 실행될 때 컴파일됩니까?
• 이것이 여전히 유효한 위협입니까, 아니면 1984 년 이후로 컴파일 보안에 중대한 문제가되지 않도록하는 개발이 있었습니까?
• 이것이 모든 언어에 영향을 줍니까?

왜 알고 싶어?

나는 숙제를 하면서이 문제를 겪었지만 재미있어 보였지만 이것이 현재 문제인지 또는 해결 된 문제인지에 대한 구체적인 방법을 이해하는 배경이 부족합니다.

참고 자료

• 개요
• 일부 코드

이 핵은 맥락에서 이해되어야합니다. 한 번에 여러 종류의 다른 하드웨어에서 실행되는 Unix가 지배적 인 시스템 인 문화에 출판되었습니다.

공격이 무섭게 된 것은 C 컴파일러가 이러한 시스템 의 핵심 소프트웨어라는 점이었습니다. 시스템의 거의 모든 것이 컴파일러가 처음 설치되었을 때 컴파일러를 통과했습니다 (이진 배포는 이기종 하드웨어로 인해 드물었습니다). 모두가 항상 물건을 편집했습니다. 사람들은 정기적으로 소스 코드를 검사하여 (컴파일을하기 위해 조정을해야했기 때문에) 컴파일러가 백도어를 주입하는 것은 일종의 "완전한 범죄"시나리오 인 것처럼 보였습니다.

오늘날 하드웨어는 훨씬 더 호환 가능하므로 컴파일러는 일상적인 시스템 작동에서 훨씬 작은 역할을합니다. 손상된 컴파일러는 더 이상 가장 무서운 시나리오가 아닙니다. 루트킷과 손상된 BIOS는 감지하고 제거하기가 훨씬 어렵습니다.

이 연설의 목적은 해결해야 할 취약성을 강조하거나 심지어 알아야 할 이론적 취약성을 제안하는 것이 아닙니다.

보안에 관해서는, 우리는 누군가를 믿지 않아도되지만 불행히도 불가능하다는 것이 목적이었습니다. 당신은 항상 누군가 를 믿어야 합니다 (따라서 제목 : "Trusting On Trusting Trust"

데스크탑 하드 드라이브를 암호화하고 자신이 컴파일하지 않은 소프트웨어의 실행을 거부하는 편집증 유형 인 경우에도 운영 체제를 신뢰해야합니다. 그리고 운영 체제를 직접 컴파일하더라도 사용하는 컴파일러를 신뢰해야합니다. 심지어 그리고 경우에 당신이 당신의 자신의 컴파일러를 컴파일, 당신은 여전히 믿을 필요 가 컴파일러를! 그리고 그것은 하드웨어 제조업체를 언급하지도 않습니다!

당신은 단순히 아무도 신뢰 하지 않고 도망 갈 수 없습니다 . 그것이 그가 만나고 자하는 요점입니다.

아니

원래 설명했듯이 공격은 결코 위협이되지 않았습니다. 컴파일러는 이론적으로이 작업을 수행 할 수 있지만 실제로 공격을 시작하려면 컴파일러를 프로그래밍해야합니다.

• 컴파일되는 소스 코드가 컴파일러 인 경우를 인식하고
• 임의의 소스 코드를 수정하여 해킹을 삽입하는 방법을 알아 봅니다.

이를 위해서는 컴파일러가 소스 코드에서 작동하는 방식을 파악하여 손상없이 수정할 수 있습니다.

예를 들어, 링크 형식이 실행 파일 어딘가에 컴파일 된 기계 코드의 데이터 길이 또는 오프셋을 저장한다고 가정하십시오. 컴파일러는이 중 어느 것을 업데이트해야하는지, 익스플로잇 페이로드를 삽입 할 때 어디에 있는지 알아 내야합니다. 이후 버전의 컴파일러 (무해한 버전)는이 형식을 임의로 변경할 수 있으므로 익스플로잇 코드는 이러한 개념을 효과적으로 이해해야합니다.

이것은 높은 수준의 자체 지향 프로그래밍, 어려운 AI 문제입니다. 보세요 :이 일을 할 수있는 사람은 거의 없습니다. 프로그래밍 언어를 배우고 코드베이스를 먼저 이해해야합니다.

AI 문제가 해결 되더라도 작은 컴파일러를 컴파일하면 거대한 AI 라이브러리가 연결된 바이너리가 생성되는지 알 수 있습니다.

유사한 공격 : 부트 스트랩 신뢰

그러나 공격의 일반화는 관련이 있습니다. 기본적인 문제는 신뢰 체인이 어딘가에서 시작해야한다는 것입니다. 많은 도메인에서 그 체인의 기원이 감지하기 어려운 방식으로 전체 체인을 파괴 할 수 있습니다.

실생활에서 쉽게 벗어날 수있는 예

Ubuntu Linux와 같은 운영 체제는 리포지토리의 서명 키 (공개 키 암호화 사용)와 비교하여 다운로드 한 업데이트 패키지를 확인하여 업데이트의 보안 (무결성)을 보장합니다. 그러나 서명 키가 합법적 인 소스에 의해 소유되어 있음을 증명할 수있는 경우 에만 업데이트의 신뢰성 을 보장 합니다 .

서명 키는 어디서 얻었습니까? 운영 체제 배포를 처음 다운로드 한 경우

신뢰의 근원 인이 서명 키가 악한 것이 아니라는 것을 신뢰해야합니다.

귀하와 Ubuntu 다운로드 서버 간의 인터넷 연결을 MITM 할 수있는 사람 (이는 ISP, 인터넷 액세스를 제어하는 ​​정부 (예 : 중국) 또는 Ubuntu 호스팅 제공 업체)이이 프로세스를 가로 챌 수 있습니다.

• Ubuntu CD 이미지를 다운로드하고 있음을 감지하십시오. 이것은 간단합니다. 요청이 (공개적으로 나열된) 우분투 미러 중 하나에 가고 ISO 이미지의 파일 이름을 요청하는 것을보십시오.
• 자신의 서버에서 요청을 처리하여 우분투 대신 공격자의 공개 키 및 리포지토리 위치가 포함 된 CD 이미지를 제공합니다.

그런 다음 공격자의 서버에서 안전하게 업데이트를받습니다. 업데이트는 루트로 실행되므로 공격자는 모든 권한을 갖습니다.

원본이 정품인지 확인하여 공격을 방지 할 수 있습니다. 그러나이를 위해서는 해시를 사용하여 다운로드 한 CD 이미지의 유효성을 검사해야합니다 ( 실제로이 작업을 수행하는 사람은 거의 없음 ). 해시 자체는 HTTPS를 통해 안전하게 다운로드해야합니다. 또한 공격자가 컴퓨터에 회사 환경에서 일반적으로 사용되는 인증서를 추가하거나 인증 기관 (예 : 중국)을 제어 할 수있는 경우 HTTPS조차도 보호 기능을 제공하지 않습니다.

먼저,이 핵의 가장 좋아하는 글을 Strange Loops 라고 합니다.

이 특정 해킹은 오늘날 주요 오픈 소스 OS 프로젝트, 특히 Linux, * BSD 등에서 확실히 (*) 수행 될 수 있습니다. 나는 거의 똑같이 작동 할 것으로 기대합니다. 예를 들어, openssh를 수정하기 위해 악용 된 컴파일러가있는 FreeBSD 사본을 다운로드합니다. 그때부터는 소스별로 openssh 또는 컴파일러를 업그레이드 할 때마다 문제점이 계속됩니다. 공격자가 FreeBSD를 패키징하는 데 사용 된 시스템을 처음부터 사용했다고 가정하면 (이미지 자체가 손상되었거나 공격자가 실제로 패키저이기 때문에) 시스템이 FreeBSD 바이너리를 다시 빌드 할 때마다 문제가 다시 발생합니다. 이 공격은 실패 할 수있는 방법이 많이 있지만 Ken의 공격이 실패한 방법 (**)과 근본적으로 다르지 않습니다. 세상은 그렇게 많이 변하지 않았습니다.

물론 소유자는 Java, iOS SDK, Windows 또는 기타 시스템과 같은 시스템에 유사한 공격을 쉽고 쉽게 주입 할 수 있습니다. 특정 종류의 보안 결함은 하드웨어로 엔지니어링 될 수 있습니다 (특히 난수 생성 약화).

(*) 그러나 "확실히"는 "원칙적으로"를 의미합니다. 이러한 종류의 구멍이 특정 시스템에 존재한다고 기대해야합니까? 아니요. 여러 가지 실용적인 이유로 생각하지 않을 것입니다. 시간이 지남에 따라 코드가 변경되고 변경되면 이러한 종류의 핵이 이상한 버그를 일으킬 가능성이 높아집니다. 그리고 그것이 발견 될 가능성을 높입니다. 덜 독창적 인 백도어는 유지하기 위해 음모가 필요합니다. 물론 우리는 다양한 통신 및 네트워킹 시스템에 "합법적 인 가로 채기"백도어가 설치되어 있다는 사실을 알고 있습니다. 핵은 명백하게 설치됩니다.

따라서 항상 심층 방어입니다.

(**) Ken의 공격이 실제로 존재했다고 가정합니다. 그는 방금 어떻게 할 수 있는지에 대해 논의했습니다 . 그는 내가 아는 한 실제로 그렇게했다고 말하지 않았다.

이것이 모든 언어에 영향을 줍니까?

이 공격은 주로 자체 호스팅 언어에 영향을줍니다. 그것은 언어 자체로 컴파일러가 작성되는 언어입니다. C, Squeak Smalltalk 및 PyPy Python 인터프리터가 이에 영향을받습니다. Perl, JavaScript 및 CPython Python 인터프리터는 그렇지 않습니다.

이것은 적시 컴파일과 어떤 관련이 있습니까?

별로. 해킹을 숨길 수있는 것은 컴파일러의 자체 호스팅 특성입니다. 자체 호스팅 JIT 컴파일러를 모르겠습니다. (아마도 LLVM?)

* nix 시스템에서 로그인을 처리하는 프로그램과 같은 기능이 실행될 때 컴파일됩니까?

보통은 아닙니다. 그러나 질문은 컴파일 될 때가 아니라 어떤 컴파일러에 의해 이루어 집니다. 로그인 프로그램이 오염 된 컴파일러에 의해 컴파일되면 오염됩니다. 깨끗한 컴파일러로 컴파일하면 깨끗합니다.

이것이 여전히 유효한 위협입니까, 아니면 1984 년 이후로 컴파일 보안에 중대한 문제가되지 않도록하는 개발이 있었습니까?

이것은 여전히 ​​이론적 인 위협이지만 그럴 가능성은 낮습니다.

이를 완화하기 위해 할 수있는 한 가지는 다중 컴파일러를 사용하는 것입니다. 예를 들어, GCC에 의해 자체 컴파일 된 LLVM 컴파일러는 백도어를 통과하지 않습니다. 마찬가지로 LLVM에서 컴파일 한 GCC는 백도어를 통과하지 않습니다. 따라서 이런 종류의 공격이 걱정된다면 다른 종류의 컴파일러로 컴파일러를 컴파일 할 수 있습니다. 즉, 악의적 인 해커 (OS 공급 업체의 경우)는 서로를 인식하기 위해 두 컴파일러를 손상시켜야합니다. 훨씬 더 어려운 문제입니다.

이것이 일어날 수있는 이론적 인 기회가 있습니다. 그러나 David A. Wheeler의 Diverse double-compiling을 통해 특정 컴파일러 (사용 가능한 소스 코드가있는)가 손상되었는지 확인하는 방법이 있습니다 .

기본적으로 의심되는 컴파일러와 독립적으로 개발 된 다른 컴파일러를 사용하여 의심스러운 컴파일러의 소스를 컴파일하십시오. 이를 통해 SC _sc 및 SC _{T가 제공} 됩니다. 이제이 바이너리를 모두 사용하여 의심스러운 소스를 컴파일하십시오. 결과 바이너리가 동일하면 (일정한 타임 스탬프와 같이 합법적으로 다양 할 수있는 다양한 항목을 제외하고) 의심되는 컴파일러는 실제로 신뢰를 남용하지 않았습니다.

특정 공격 으로서는 그 어느 때보 다 위협이 될 수 있습니다. 이는 전혀 위협이되지 않습니다.

이것은 적시 컴파일과 어떤 관련이 있습니까?

그게 무슨 뜻인지 잘 모르겠습니다. 지터가 이것에 면역성이 있습니까? 아니요. 더 취약합니까? 실제로는 아닙니다. 개발자는 앱이 완료되지 않았 음을 확인할 수 없기 때문에 앱이 더 취약합니다. 아직 개발되지 않은 앱은 기본적으로 이것과 모든 실제 변형에 영향을받지 않으므로 코드보다 최신 인 컴파일러에 대해서만 걱정하면됩니다.

* nix 시스템에서 로그인을 처리하는 프로그램과 같은 기능이 실행될 때 컴파일됩니까?

그것은 실제로 관련이 없습니다.

이것이 여전히 유효한 위협입니까, 아니면 1984 년 이후로 컴파일 보안에 중대한 문제가되지 않도록하는 개발이 있었습니까?

컴파일의 실제 보안은 없으며 불가능합니다. 그것은 그의 대화의 요점이었습니다. 어떤 시점에서 당신은 누군가를 믿어야합니다.

이것이 모든 언어에 영향을 줍니까?

예. 근본적으로, 언젠가는, 컴퓨터가 실행하는 것으로 귀하의 지시가 이루어져야하며, 번역이 잘못 될 수 있습니다.

David Wheeler는 좋은 기사를 가지고 있습니다 : http://www.dwheeler.com/trusting-trust/

저는 하드웨어 공격이 더 걱정됩니다. FLOSS 소스 코드가 포함 된 완전히 VLSI 디자인 툴체인이 필요하다고 생각합니다. 수정하고 컴파일하여 툴에 의해 백도어가 삽입되지 않은 마이크로 프로세서를 만들 수 있습니다. 툴은 또한 칩상의 모든 트랜지스터의 목적을 이해하도록해야한다. 그런 다음 완성 된 칩 샘플을 열어 현미경으로 검사하여 도구가 가지고 있어야하는 것과 동일한 회로를 가지고 있는지 확인할 수 있습니다.

최종 사용자가 소스 코드에 액세스 할 수있는 시스템은 이러한 유형의 공격을 숨겨야합니다. 이것이 오늘날 세계의 오픈 소스 시스템입니다. 문제는 모든 Linux 시스템의 단일 컴파일러에 의존하지만 모든 주요 Linux 배포판의 빌드 서버에 대한 공격이 이루어져야한다는 것입니다. 이들은 각 컴파일러 릴리스마다 컴파일러 바이너리를 직접 다운로드하지 않기 때문에 공격 소스는 적어도 하나의 이전 컴파일러 릴리스에서 빌드 서버에 있어야했습니다. 바이너리 또는 바이너리로 다운로드 한 컴파일러의 첫 번째 버전이 손상되었을 수 있습니다.

제공된 소스 파일의 내용 이외의 것에 의존하지 않아야하는 컴파일러 / 빌드 시스템의 소스 코드가 있고 다른 컴파일러가 여러 개 있고 모두 동일한 컴파일러 해킹을 포함하고 있지 않다는 것을 알고 있다면 소스 코드 이외의 것에 의존하는 실행 파일을 얻는 지 확인하십시오.

하나의 컴파일러 / 링커 패키지 (예 : Groucho Suite)의 소스 코드가 출력이 지정되지 않은 동작이나 입력 소스 파일의 내용 이외의 다른 것에 의존하지 않는 방식으로 작성된 것으로 가정하고 독립적으로 생산 된 다양한 컴파일러 / 링커 패키지 (예 : Harpo Suite, Chico suite 및 Zeppo Suite)를 코딩하는 링크를 통해 각기 다른 실행 파일 세트를 생성합니다 (G-Harpo, G-Chico 및 G-Zeppo). 이러한 실행 파일이 다른 명령 시퀀스를 포함하는 것은 예기치 않은 일이 아니지만 기능적으로 동일해야합니다. 그러나 모든 경우에 기능적으로 동일하다는 것을 증명하는 것은 다루기 힘든 문제 일 것입니다.

다행스럽게도 Groucho Suite를 다시 컴파일하는 단일 목적으로 만 실행 파일을 사용하는 경우에는 그러한 증거가 필요하지 않습니다. G-Harpo (일괄 GG-Harpo), G-Chico (GG-Chico) 및 G-Zeppo (GG-Zeppo)를 사용하여 Groucho 제품군을 컴파일하는 경우 세 개의 결과 파일 인 GG-Harpo, GG-Chico , GG-Zeppo는 바이트 단위가 모두 같아야합니다. 파일이 일치하면 해당 파일에 존재하는 "컴파일러 바이러스"가 모든 파일에 동일하게 존재해야 함을 의미합니다 (세 개의 파일이 모두 바이트 단위로 동일하므로 해당 동작이 다른 방식으로 다를 수있는 방법은 없습니다) 방법).

다른 컴파일러의 연령과 계보에 따라 그러한 바이러스가 그럴듯하게 존재하지 않도록하는 것이 가능할 수 있습니다. 예를 들어, 골동품 Macintosh를 사용하여 2007 년에 처음부터 작성된 컴파일러에 1980 년대에 작성된 MPW 버전을 공급하는 경우 1980 년대의 컴파일러는 2007 컴파일러에서 바이러스를 삽입 할 위치를 모를 것입니다. 오늘날 컴파일러가이를 파악하기에 충분한 코드 분석을 수행하는 것이 가능할 수도 있지만, 그러한 분석에 필요한 계산 수준은 단순히 코드를 컴파일하는 데 필요한 계산 수준을 훨씬 능가 할 것입니다. 편집 속도가 주요 판매 지점이었던 시장에서

생성 된 실행 파일의 바이트가 제출 된 소스 파일의 내용 이외의 다른 것에 의존해서는 안되는 컴파일 도구로 작업하는 경우 Thompson으로부터 상당히 좋은 면역을 얻을 수 있다고 주장합니다 스타일 바이러스. 불행히도 어떤 이유로 컴파일에서 비결정론은 일부 환경에서 정상적인 것으로 간주됩니다. 다중 CPU 시스템에서 코드 생성의 특정 측면이 두 개의 스레드 중 어느 것이 먼저 작업을 완료하는지에 따라 달라지면 컴파일러가 더 빠르게 실행될 수 있음을 알고 있습니다.

반면에 컴파일러 / 링커가 소스 파일에만 의존하는 "정식 출력"모드와 사용자가 재정의 할 수있는 "컴파일 날짜"를 제공하지 않아야하는 이유는 확실하지 않습니다. . 이러한 모드에서 코드를 컴파일하는 데 일반 컴파일 시간의 두 배가 걸리더라도 소스 자료에서 "릴리스 빌드", 바이트 단위의 바이트를 완전히 다시 만들 수 있다면 상당한 가치가 있다고 제안합니다. 릴리스 빌드는 "일반 빌드"보다 오래 걸립니다.