CおよびC ++以外の言語のオープンソースコードでバックドアを非表示にしますか？
私は The Underhanded C Contest および Backdoorsを明白に隠す 彼らは、巧妙にオープンソースコードを記述し、コードを公開し、バックドアを目立たないように隠すことができることを示しています。
これはCの排他的な問題ですか、それともC++の拡張によるものですか？
これは低レベル言語の問題ですか、アセンブラコードとしましょうか？
これは問題ですか、より高水準の言語では、python code？
編集：ケンの仕事との混乱を避けるために、私は彼の引用を削除しました。
これは、「バックドアを一目で隠す」こと、つまりソースコードを簡単にすることです。もはやコンパイラについて話しているのではなく、人間の脳について話している。全体のアイデアは、本当にの時間を割く時間のない人間のコードインスペクターのためにソースコードを「合法に見える」ようにし、すべての癖でタスクに人間の心を使うことです。人間の心が持つことができます。
これは心理学なので、明確な数学的な答えはありません。しかし、言語の複雑さとは多くのことで関係があると私たちはどういうわけか主張することができます。 「目に見えないように隠す」ためには、攻撃者は2つのことを行わなければなりません。
- バックドアとして、プログラミング言語のめったに使用されないサブ機能を使用します。
- 次のように、「自然な」ように見えるコード構造でこのサブ機能を使用します。「正直なプログラマーは、その構造のコードを書いたでしょう」。
極端な例として、アセンブリがあります。アセンブリはnot複雑です。アセンブリは非常に「貧弱」です。いくつかの構造（「ジャンプ」のみ）とオペコードの制限されたリストで機能します。コードライターはめったに使用されないオペコードまたはオペコードの動作を見つけることがありますが、「通常のアセンブリコード」はプログラマが自分で実行する多くの構造を持つ必要があるため、彼のタスクは実行不可能になるため、彼は2番目の条件を満たすのが難しいでしょう。 。まれに使用されるオペコードを使用すると、そのように表示されます。コードはファンキーに見え、コードインスペクタの頭の中でアラームが発生します。したがって、非表示の失敗。
一方、C＃やPythonなどの非常に複雑な言語があります。微妙な詳細と動作のロットがあります（特に、C＃の演算子オーバーロードは、「正常」に見えるコードから多くのことをトリガーするために使用できます）。一方、そのような言語は、非常に「確定的」な仕様になりがちで、未定義の動作がないか、ごくわずかなので、コードインスペクターに役立ちます。
したがって、C、さらにはC++は、バックドアを隠すためのソフトスポットです。それらは、非常に多くの未定義の動作と比較的複雑な構文ゲームを組み合わせています。 C++は、構文に多くの追加のひねりを加え、「隠された動作」を追加する多くの方法（演算子のオーバーロード、暗黙的にコンストラクターおよびデストラクタと呼ばれる...）を追加します。
これらの理由から、異なる言語は明白な隠蔽攻撃に対して異なる方法で脆弱であり、C++は非常に脆弱であると主張できますが、Assemblyのような最低限の言語は、より貧弱な構文により脆弱ではなく、より高いレベルの言語は、コーナーケースでのより厳密な言語仕様により脆弱性が低くなっています。
もちろん、これらすべては非常に議論の余地があります。私が言ったように、それは心理学についてであり、人間の心がどのように機能するかを分析することになると、各人間は最初に自分の心について考えるでしょう。誰もが同じように考えるわけではないため、答えはさまざまです。
また、私は騙されました。 Assemblyがバックドアを簡単に見えないようにする方法についての上記の私の議論は、多くの時間を手にしているコードインスペクターにのみ有効です。特定の重要なタスクを実装するには、通常、C++よりもAssemblyに多くのコード行が必要です。これにより、タスクごととカウントすると、アセンブリでのコード検査が非常に遅くなります。
実際、コードインスペクタが与えられた一連の機能を満たすアプリケーションのソースコードを通過するための固定時間予算を持つように状況を設定した場合、コードインスペクタアセンブリを取得するよりも、C++ソースコードを取得した方がバックドアを見つける可能性が高くなります。確かに、C++ソースコードを指定すると、それをアセンブリ（-SフラグはGCCにあります...）。したがって、彼のタスクはC++の方がアセンブリよりも難しくなることはありません。
したがって、正確な質問を定義することが重要です。隠されたバックドアとコードインスペクターについて話すとき、どのような種類のコードインスペクションがどのくらいの期間、どのような条件下で実行されるかを明確に述べる必要があります。それ以外の場合は、ほぼすべての答えを与えて正当化できます。
質問の元のバージョン への回答
Ken Thompsonの要点は、バックドアがソースコードにないであるということです-これはコンパイラにあり、より正確にはコンパイラの_にあります。実行可能ファイル、コンパイラのソースコードにもありません。
詳細：「悪のコード」があるE1システムログインアプリケーションに挿入されると、攻撃者が知っている「隠された」パスワードの攻撃者へのアクセスを許可します。 別の悪のコードE2、コンパイラの実行可能ファイルに常駐することを意味します。 E2は2つのことを行います。
- コンパイルされているファイルがシステムログインアプリケーションのソースコードである場合、E1生成された実行可能ファイルに。
- コンパイルされているファイルがコンパイラ自体のソースコードである場合、E2（つまり、それ自体）を生成された実行可能ファイルに入れます。
このようにして、システムログインアプリケーションのソースコードにもコンパイラのソースコードにも悪意のあるものが含まれていません。邪悪なコードE2は、実行可能ファイルに感染することにより、ウイルスのように少し繁殖します（ただし、コンパイラの実行可能ファイルのみに感染するため、うるさいです。コンパイラのアクション）。その邪悪なコードの二次機能E2は邪悪なコードを植えることですE1をシステムログインアプリケーションに追加します。
どのソースコードにも悪事はないため、ソースが「オープンソース」であるかどうかにかかわらず、関連性はありません。これが、コンパイラにバックドアを仕掛ける全体のポイントです。したがって、正直なソースコードを変更する必要はありません。
ここではCまたはC++に固有のものはありません。これは、コンパイルされるすべてのプログラミング言語に等しく適用されます。そして、同様のバックドアがインタープリター型言語のために考案される可能性もあります（悪コードE３ inインタープリターは、実行時のスクリプトの動作を変更します。邪悪なコードE4は、それ自体を新しいコンパイラインスタンスに複製し、E３インタプリタ自体がコンパイルされるときにインタプリタに挿入されます）。
それでも不明瞭な場合は、コンパイルの概念を理解するまで the Dragon Book （まともな大学図書館から無料で入手可能）を読んでください。