ケントンプソンのコンパイラハック
ケントンプソンのコンパイラハックペーパー ;コンパイラのソースコードを調べてバックドアをチェックできないのではないでしょうか。この記事の要点は何ですか。
PythonまたはPHPなど）の言語の最新のソースコードをチェックした場合、バックドアがないことを確認できますか？
いいえ、表示できるソースは、使用しているバイナリと必ずしも一致しません。この論文で説明されている特定の攻撃には、複数のコンパイラソースバージョンが含まれています。このコンパイラを使用してコンパイルされたものにバックドアを挿入するコードを含む悪意のある攻撃と、このコードを含まないクリーンな攻撃があります。
攻撃者はまず悪意のあるバージョンをコンパイルし、コンパイラの今後のビルドにバックドアを挿入するコンパイラを生成します。次に、悪意のあるコンパイラを使用してクリーンバージョンをコンパイルします。ソースコードはきれいでしたが、これの出力も悪意のあるものになりました-ソースとバイナリは一致しなくなりましたが、それをチェックすることは困難です。悪意のあるコマンドを探すために、バイナリをリバースエンジニアリングする必要があります。ここでさらに複雑になるのは、リバースエンジニアリングツールが悪意のあるコンパイラでコンパイルされた場合、使用時にバイナリの追加機能を十分に隠すことができるということです。
したがって、オプションは、異なるバージョンのコンパイラでコンパイルされた、まったく異なるマシンからのリバースエンジニアリングツールを使用することです。ただし、元のバックドアがいつ作成されたかによっては、別のマシンのコンパイラも悪意のあるものである可能性があります。たとえば、両方が同じOSを実行している場合、同じコンパイラが組み込まれている可能性があり、両方のデバイスで侵害されます。そうでない場合は、侵害されたコンパイラからブートストラップされた、または侵害されたコンパイラがあった別のOSからクロスコンパイルされた以前のバージョンが存在する可能性があります。
チェーン全体が妥協されていないことを確認する唯一の方法は、プロセッサが実行できるバイナリを手動で構築し、これを段階的に改善して追加の機能を許可することです。サードパーティのソフトウェアに依存することはできません（テキストエディターが悪意のあるソフトウェアを挿入する可能性があります）ソースコードを見るときにコードを非表示にし、シェルは変更されたソースファイルのファイルサイズなどを非表示にする場合があります）。実際、サードパーティのハードウェアに依存することすらできません。CPUは、ビルドされているコンパイラー、RAM、マザーボード、ネットワークアダプター、またはネットワーク上のその他のポイントのように見えるものをバックドアする可能性があります。渡されたコンパイラコードまたはバイナリ...
さて、これは少し偏執的ですが、どちらの場合も、書き込まれるソースと実際に実行されるソースとの間に区別があるとすぐに、表示されるソースと実行されるバイナリが一致することを100％確実にすることはできません。アップ。
これはハッキングが発生したことを意味するわけではありませんが、コンピューターを最初から構築し、それを使用してすべてを確認することなしに確認できなかったことを示唆していることに注意してください-この場合、最初から、原料から、絶対的に出力に影響を与える可能性のあるものを何も使用せずに確実。ハンマーはおそらく大丈夫ですが、CNCデバイスは悪意があるかもしれません、またはファブ工場、またはそれらのワイヤー、または...
スズ箔の帽子をかぶると、侵害された可能性のある他の誰かによって作成されたことがわかります
コンパイラのソースコードを調べてバックドアをチェックすることはできません。この記事の要点は何ですか。
この記事の要点は、バックドアコンパイラのソースコードにないであるため、-できないであるということです。
Thompsonはこれをさまざまなステップで説明しています。
loginプログラムのソースコードにバックドアを配置します。明らかに、loginのソースコードを調べると、このバックドアが見つかります。- 代わりに、コードの一部をコンパイラのソースコードに挿入して、
loginプログラムをコンパイルするときに、このバックドアを挿入します。現在、バックドアはloginのソースコードのどこにも表示されません。明らかに、コンパイラのソースコードを調べると、このメタバックドアが見つかります。 - 代わりに、他のコンパイラのコンパイルに使用されたコンパイラのソースコードにコードの一部を挿入します。これにより、コンパイラのコンパイル時に、
loginのコンパイル時にメタバックドアが挿入されます。プログラムは、バックドアを挿入します。これで、メタバックドアはコンパイラのソースコードに表示されなくなります。繰り返しますが、bootstrapコンパイラのソースコードを調べると、このmeta-meta-backdoorが見つかります。 - 等々 …
だが！！！これが問題です。ある時点で、あなたは必要すでにコンパイルされているため、bootstrapコンパイラをコンパイルして、コンパイラをコンパイルできるようにすることができます。 loginプログラム。そして、あなたはcannot自分でこのコンパイラをコンパイルします（そのためにanotherコンパイラが必要になるため）。したがって、あなたはcannot検査は、実際にはコンパイラのコンパイルに使用されたものです。
そしてそれが問題です：ソースコードを挿入して検査する中間コンパイラーの数に関係なく、自分でコンパイルできず、must信頼できる究極の「最初の」コンパイラーが1つあります。
Thompson氏は、このホワイトペーパーの後半で、コンパイラは一例にすぎないとも説明しています。 Any格納、読み取り、書き込み、変換、操作、処理、表示、またはその他の方法でコードに触れるエンティティは、同様の方法で侵害される可能性があります。
コンパイラーの代わりに、動的リンカーを使用できます。これは、実行中のloginプログラムを検出すると、それをCライブラリのバージョンにリンクして、常にtrueを返します。たとえば、どのパスワードを入力しても許可されます。または、マザーボードのメモリバスを変更して、loginプログラムがRAMをCPUに送信し、命令を変更します。または、CPUを変更して、実行中のloginプログラムを検出することもできます。ハードディスクのマイクロコントローラーを変更して、ディスクからloginプログラムをロードしていることを検出すると、SATAバス経由で送信する前にプログラムを変更することができます。
コンパイルによってバックドアを巧みに隠そうとする代わりに、代わりにテキストエディターを変更して、loginのソースコードを検査してもバックドアが表示されないようにすることもできます。コンパイラのソースコードを表示するときも同じようにできます。そしてもちろん、エディター自体。
などなど。
その要点は次のとおりです。コンピューティングシステム全体を個別のワイヤーから構築し、スイッチを最初から作成しない限り、コードを処理するコンポーネントが他のどこかから取得され、そこにバックドアが存在する可能性があります。
コンパイラはソースコードからバイナリを作成します。通常のコンパイラの場合、バイナリはソースコードの別の表現であり、プログラムの動作はソースで完全に指定されています。ただし、悪意のあるコンパイラがバイナリに追加機能を追加する可能性があります。これは、ソースには存在しないため、ソースを読み取って検出することはできません。
これは、コンパイラのソースにも当てはまります。コンパイラをコンパイルすると、悪意のあるコンパイラがこの悪意のある機能をターゲットバイナリに追加し、サークルが完成します。