ケントンプソンのコンパイラハックは依然として脅威ですか？
ケン・トンプソン・ハック（1984）
ケントンプソンは、1984年にコンパイラバイナリ（および* nixシステムのログインスクリプトのような他のコンパイル済みソフトウェア）を破損させる方法の概要を説明しました。最新のコンパイルでこのセキュリティの欠陥に対処したかどうか知りたくて知りませんでした。
簡単な説明：
2つの欠陥を含むようにコンパイラコードを書き直します。
- 独自のバイナリをコンパイルする場合、コンパイラはこれらの欠陥をコンパイルする必要があります
- 他の事前選択されたコード（ログイン関数）をコンパイルするときは、任意のバックドアをコンパイルする必要があります
したがって、コンパイラは正常に機能します。ログインスクリプトなどをコンパイルすると、セキュリティバックドアが作成され、将来的にそれ自体の新しいバージョンをコンパイルしても、以前の欠陥が保持されます-および欠陥はコンパイラバイナリにのみ存在するため、検出が非常に困難です。
質問：
私はこれらの答えをウェブ上で見つけることができませんでした：
- これはジャストインタイムコンパイルとどのように関連していますか？
- * nixシステムでのログインを処理するプログラムのような関数は、実行時にコンパイルされますか？
- これはまだ有効な脅威ですか、それとも1984年以来、これが重大な問題となるのを妨げるコンパイルのセキュリティの進展がありましたか？
- これはすべての言語に影響しますか？
なぜ知りたいのですか？
宿題をしている最中に出くわしましたが、面白そうでしたが、これが現在の問題なのか、それとも解決済みの問題なのかを具体的に理解できる背景がありません。
参考資料
このハックは、状況に応じて理解する必要があります。それは、あらゆる種類のハードウェア上で実行されているUnixが主流のシステムであるという文化と時代に発表されました。
攻撃をそれほど怖くしたのは、Cコンパイラがtheこれらのシステムの中心的なソフトウェアであったということです。システムのほとんどすべてが最初にインストールされたときにコンパイラーを通過しました（異種のハードウェアのためにバイナリー配布はまれでした）。誰もが常に物事をコンパイルしました。人々は定期的にソースコードを検査し（多くの場合、コンパイルするために調整を行う必要がありました）、コンパイラーにバックドアを挿入させることは、捕まえられない一種の「完全犯罪」のシナリオのように思われました。
現在、ハードウェアの互換性ははるかに高く、したがって、コンパイラーはシステムの日常の操作においてはるかに小さな役割しか持っていません。侵害されたコンパイラは、もはや最も恐ろしいシナリオではありません-ルートキットと侵害されたBIOSは、検出して取り除くのがさらに困難です。
そのスピーチの目的は、対処する必要のある脆弱性を強調することでも、認識しておく必要のある理論的な脆弱性を提案することでもありませんでした。
目的は、セキュリティに関しては誰も信用しないことですが、残念ながらそれは不可能です。あなたは常に信頼する必要があります誰か（そのため、タイトル： "Reflections On Trusting Trust"）
デスクトップハードドライブを暗号化し、自分でコンパイルしなかったソフトウェアの実行を拒否する妄想的なタイプであっても、オペレーティングシステムを信頼する必要があります。また、オペレーティングシステムを自分でコンパイルした場合でも、使用したコンパイラを信頼する必要があります。そしてifあなた自身のコンパイラをコンパイルしても、あなたstillは信頼する必要がありますthatコンパイラ！そして、それはハードウェアメーカーについてさえ言及していません！
あなたは単に誰もを信頼して逃げることはできません。それは彼が乗り越えようとしていた点です。
番号
最初に説明したように、攻撃は脅威ではありませんでした。コンパイラは理論的にはこれを実行できますが、実際に攻撃を阻止するには、コンパイラをプログラミングして
- コンパイルされるソースコードがコンパイラのものである場合を認識します。
- ハックを挿入するために任意のソースコードを変更する方法を理解します。
これには、破損することなくコンパイラーを変更できるように、コンパイラーがソースコードからどのように機能するかを理解する必要があります。
たとえば、リンク形式が、コンパイルされたマシンコードのデータ長またはオフセットを実行可能ファイルのどこかに格納しているとします。コンパイラーは、エクスプロイトペイロードを挿入するときに、これらのうちどれをどこに更新する必要があるかを自ら把握する必要があります。コンパイラの後続のバージョン（無害なバージョン）では、この形式を任意に変更できるため、エクスプロイトコードはこれらの概念を効果的に理解する必要があります。
これは、高レベルの自主プログラミングであり、難しいAI問題です（最後に確認したように、最先端の技術は、そのタイプによって実際に決定されるコードを生成していました）。見てください：これを行うことができる人間はほとんどいません。最初にプログラミング言語を学び、コードベースを理解する必要があります。
AIの問題が解決されたとしても、小さなコンパイラーをコンパイルすると、巨大なAIライブラリーがリンクされたバイナリーが生成される場合があります。
類似の攻撃：信頼のブートストラップ
ただし、攻撃の一般化は重要です。基本的な問題は、信頼の連鎖がどこかから始まる必要があり、多くのドメインでは、Originが連鎖全体を検出しにくい方法で破壊する可能性があることです。
実生活で簡単に引き離すことができる例
Ubuntu Linuxなどのオペレーティングシステムは、ダウンロードした更新パッケージをリポジトリの署名鍵と照合して（公開鍵暗号を使用して）、更新のセキュリティ（整合性）を保証します。ただし、これは、署名鍵が正当なソースによって所有されていることを証明できる場合にのみ、更新の真正性を保証します。
署名キーはどこで入手しましたか？オペレーティングシステムの配布を初めてダウンロードしたとき。
信頼の連鎖の源であるこの署名鍵が悪ではないことを信頼する必要があります。
[〜＃〜] mitm [〜＃〜] あなたとUbuntuダウンロードサーバー間のインターネット接続—これはISP、インターネットアクセスを制御する政府（中国など）、またはUbuntuのホスティングプロバイダー-このプロセスを乗っ取った可能性があります。
- Ubuntu CDイメージをダウンロードしていることを検出します。これは簡単です。リクエストが（公開リストに掲載されている）Ubuntuミラーのいずれかに送信され、ISOイメージのファイル名を要求していることを確認してください。
- 独自のサーバーからリクエストを処理し、Ubuntuの代わりに攻撃者の公開鍵とリポジトリの場所を含むCDイメージを提供します。
その後、攻撃者のサーバーから更新を安全に取得します。更新はrootとして実行されるため、攻撃者が完全に制御できます。
オリジナルが本物であることを確認することで、攻撃を防ぐことができます。ただし、これには、ダウンロードしたCDイメージをハッシュを使用して検証する必要があります（実際にこれを実行する人は少ない）。また、ハッシュ自体を安全にダウンロードする必要があります。 HTTPS経由。また、攻撃者がコンピューターに証明書を追加したり（企業環境では一般的）、認証局（中国など）を制御したりできる場合、HTTPSでも保護は提供されません。
まず、このハックに関する私のお気に入りの記事は Strange Loops と呼ばれています。
この特定のハッキングは、今日の主要なオープンソースOSプロジェクト、特にLinux、* BSDなどで確実に（*）実行できます。私はそれがほぼ同じように機能することを期待します。たとえば、opensshを変更するために悪用されたコンパイラーを持つFreeBSDのコピーをダウンロードします。それ以降、opensshまたはコンパイラをソースごとにアップグレードするたびに、問題が継続します。攻撃者が最初にFreeBSDをパッケージ化するために使用されたシステムを悪用した場合（おそらく、イメージ自体が破損しているか、攻撃者が実際にパッケージャーであるため）、そのシステムがFreeBSDバイナリを再構築するたびに、問題が再注入されます。この攻撃が失敗する方法はたくさんありますが、Kenの攻撃が失敗した方法と基本的に同じです（**）。世界はそれほど変わっていません。
もちろん、同様の攻撃は、所有者によって、Java、iOS SDK、Windows、またはその他のシステムのようなシステムに簡単に（またはより簡単に）注入される可能性があります。特定の種類のセキュリティ欠陥がハードウェアに組み込まれることもあります（特に、乱数生成を弱めます）。
（*）しかし、「確かに」とは「原則として」を意味します。この種の穴が特定のシステムに存在することを期待すべきですか？いいえ。実際のさまざまな理由から、考えられることはほとんどありません。時間の経過とともに、コードが変化するにつれて、この種のハッキングが奇妙なバグを引き起こす可能性が高まります。そして、それが発見される可能性を高めます。独創性の低いバックドアは、陰謀を維持する必要があります。もちろん、「合法的傍受」のバックドアがさまざまな電気通信やネットワーキングシステムにインストールされているため、多くの場合、このような手の込んだハッキングは不要です。ハックはあからさまにインストールされています。
したがって、常に、多層防御を行います。
（**）ケンの攻撃が実際に存在したと仮定します。彼はそれがどのようにできるかについて話し合ったところです。私が知る限り、彼は実際にそれをしたとは言わなかった。
これはすべての言語に影響しますか？
この攻撃は主に、セルフホスティング言語に影響を与えます。それは、コンパイラがその言語自体で書かれている言語です。 C、Squeak Smalltalk、およびPyPy Python=インタプリタはこれによる影響を受けます。Perl、JavaScript、およびCPython Pythonインタプリタは影響を受けません。
これはジャストインタイムコンパイルとどのように関連していますか？
それほど多くない。ハックを隠すことができるのは、コンパイラーのセルフホスティングの性質です。セルフホスティングJITコンパイラについては知りません。 （たぶんLLVM？）
* nixシステムでのログインを処理するプログラムのような関数は、実行時にコンパイルされますか？
通常はありません。しかし、問題はwhenではなく、コンパイラによってです。ログインプログラムが汚染されたコンパイラによってコンパイルされた場合、汚染されます。クリーンなコンパイラでコンパイルされていれば、クリーンです。
これはまだ有効な脅威ですか、それとも1984年以来、これが重大な問題となるのを妨げるコンパイルのセキュリティの進展がありましたか？
これはまだ理論的な脅威ですが、あまりありそうにありません。
これを軽減するためにできることの1つは、複数のコンパイラを使用することです。たとえば、それ自体がGCCによってコンパイルされたLLVMコンパイラは、バックドアを通過しません。同様に、LLVMによってコンパイルされたGCCはバックドアを通過しません。したがって、この種の攻撃が心配な場合は、別の種類のコンパイラを使用してコンパイラをコンパイルできます。つまり、悪意のあるハッカーは（OSベンダーでは？）お互いを認識するために両方のコンパイラを汚染する必要があります。もっと難しい問題。
これが起こる理論的な機会があります。ただし、David A. Wheelerの Diverse double-compileing を使用して、特定のコンパイラ（利用可能なソースコードを含む）が危険にさらされているかどうかをチェックする方法があります。
基本的に、疑わしいコンパイラと独立して開発された別のコンパイラの両方を使用して、疑わしいコンパイラのソースをコンパイルします。これはあなたにSCを与えますsc とSCT。次に、これらのバイナリの両方を使用して、疑わしいソースをコンパイルします。結果のバイナリが同一である場合（さまざまなタイムスタンプなど、正当に変化する可能性のあるさまざまなものを除いて）、疑わしいコンパイラは実際には信頼を乱用していませんでした。
特定の攻撃としては、これまでにないほどの脅威であり、まったく脅威ではありません。
これはジャストインタイムコンパイルとどのように関連していますか？
どういう意味かわからない。 JITterはこれに耐性がありますか？いいえ、もっと脆弱ですか？あんまり。開発者としてのあなたのアプリは、それが行われていないことを検証できないという理由だけでより脆弱です。まだ開発されていないアプリは基本的にこれとすべての実用的なバリエーションに影響されないことに注意してください。コードよりも新しいコンパイラーについてのみ心配する必要があります。
* nixシステムでのログインを処理するプログラムのような関数は、実行時にコンパイルされますか？
それは実際には関係ありません。
これはまだ有効な脅威ですか、それとも1984年以来、これが重大な問題となるのを妨げるコンパイルのセキュリティの進展がありましたか？
コンパイルの本当のセキュリティはありませんし、あり得ません。それは本当に彼の話のポイントでした、ある時点で誰かを信頼しなければなりません。
これはすべての言語に影響しますか？
はい。基本的に、いつか別の時点で、あなたの指示はコンピュータが実行するものに変換されなければならず、その翻訳は誤って行われる可能性があります。