ケンブリッジ大学の研究者は、ピアレビューされたソースコードに悪意のあるコードをサイレントに挿入する技術を公開しました。 準備された攻撃手法 (CVE-2021-42574) は、Trojan Source という名前で提示されており、コンパイラ/インタプリタとコードを閲覧する人にとって異なるように見えるテキストの形式に基づいています。 このメソッドの例は、C、C++ (gcc および Clang)、C#、JavaScript (Node.js)、Java (OpenJDK 16)、Rust、Go、Python 用に提供されるさまざまなコンパイラーおよびインタープリターで示されています。
この方法は、双方向テキストの表示順序を変更するコード コメントでの特殊な Unicode 文字の使用に基づいています。 このような制御文字を使用すると、テキストの一部を左から右に表示したり、他の部分を右から左に表示したりできます。 日常業務では、このような制御文字は、たとえばヘブライ語やアラビア語のコード行をファイルに挿入するために使用できます。 ただし、指定した文字を使用してテキストの方向が異なる行を XNUMX 行に結合すると、右から左に表示されるテキストの一部が、左から右に表示される既存の通常のテキストに重なる可能性があります。
この方法を使用すると、悪意のある構成要素をコードに追加できますが、次のコメントまたは右から左に表示されたリテラル文字内に追加することで、コードを表示するときにこの構成要素を含むテキストが非表示になります。これにより、完全に悪意のある挿入にさまざまな文字が重ね合わされます。 このようなコードは意味的には正しいままですが、解釈および表示が異なります。
コードをレビューする際、開発者は文字の視覚的な順序に直面し、最新のテキスト エディタ、Web インターフェイス、または IDE で疑わしいコメントを確認することになりますが、コンパイラとインタプリタは文字の論理的な順序を使用し、コメント内の双方向テキストに注意を払わずに、悪意のある挿入をそのまま処理します。 この問題は、さまざまな一般的なコード エディター (VS Code、Emacs、Atom) だけでなく、リポジトリ内のコードを表示するためのインターフェイス (GitHub、Gitlab、BitBucket、およびすべての Atlassian 製品) に影響します。
このメソッドを使用して悪意のあるアクションを実装するには、いくつかの方法があります。非表示の「return」式を追加して、事前に関数を完了させます。 通常は有効な構成として表示される式をコメント アウトします (たとえば、重要なチェックを無効にするため)。 文字列検証の失敗につながる他の文字列値を割り当てる。
たとえば、攻撃者は次の行を含む変更を提案する可能性があります: if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {
これは、access_level != “user” { // admin であるかどうかを確認するかのようにレビュー インターフェイスに表示されます。
さらに、同形文字、外観は似ているが意味が異なり、異なる Unicode コードを持つ文字の使用に関連する別の攻撃亜種 (CVE-2021-42694) が提案されています (たとえば、文字「ɑ」は「」に似ています) a」、「ɡ」 - 「g」、「ɩ」 - 「l」）。 一部の言語では、開発者を誤解させるために、関数や変数の名前に同様の文字が使用されていることがあります。 たとえば、異なるアクションを実行する、区別できない名前を持つ XNUMX つの関数を定義できます。 詳細な分析を行わないと、これら XNUMX つの関数のどちらが特定の場所で呼び出されるのかはすぐにはわかりません。
セキュリティ対策として、Unicode 文字をサポートするコンパイラ、インタープリタ、およびアセンブリ ツールは、コメント、文字列リテラル、または出力方向を変更する識別子 (U+202A、U+202A、 U+202B、U+202C、U+202D、U+2066E、U+2067、U+2068、U+2069、U+061、U+200C、U+200E、U+XNUMXF）。 このような文字は、プログラミング言語仕様でも明示的に禁止されるべきであり、コード エディターやリポジトリ インターフェイスでも尊重される必要があります。
補遺 1: GCC、LLVM/Clang、Rust、Go、Python、binutils 用の脆弱性パッチが用意されています。 GitHub、Bitbucket、Jira も問題を修正しました。 GitLab の修正が進行中です。 問題のあるコードを特定するには、コマンド grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ を使用することをお勧めします。ソース
補遺 2: Plan 9 OS と Go プログラミング言語の開発者の XNUMX 人である Russ Cox は、記載されている攻撃手法 (Go、Rust、C++、Ruby) は以前から知られていたにもかかわらず真剣に受け止められていなかったことを批判しました。 。 Cox 氏によると、この問題は主にコード エディターと Web インターフェイスでの情報の正しい表示に関係しており、レビュー中に適切なツールとコード アナライザーを使用することで解決できます。 したがって、投機的攻撃に注目を集めるのではなく、コードと依存関係のレビュー プロセスの改善に焦点を当てる方が適切です。
Ras Cox 氏はまた、コンパイラは問題を解決するのに適切な場所ではないと考えています。コンパイラ レベルで危険なシンボルを禁止することで、ビルド システム、アセンブラ、パッケージ マネージャーとさまざまな構成パーサーとデータ。 例として、コンパイラでの LTR/RTL コードの処理を禁止した Rust プロジェクトが挙げられますが、Cargo パッケージ マネージャーには修正が追加されておらず、Cargo.toml ファイルを介した同様の攻撃が許可されています。 同様に、BUILD.bazel、CMakefile、Cargo.toml、Dockerfile、GNUmakefile、Makefile、go.mod、package.json、pom.xml、requirements.txt などのファイルも攻撃源となる可能性があります。
出所： オープンネット.ru