Video: https://youtu.be/EYBB4BHsp9E
./output に抽出しますmalicious.tar アーカイブを作成し、密輸されたコンテンツの例を示します。コメントでステップごと、ブロックごとの動作を説明しています提供されている 再現スクリプト を使用するか、手動で行います
malicious-payload を実行してペイロード malicious.tar を生成します
このファイルを vulnerable-extract アプリに渡すと次の結果が得られます:
/vulnerable-extract$ ll output/
total 12
drwxrwxr-x 2 airinei airinei 4096 Jan 19 22:40 ./
drwxrwxr-x 5 airinei airinei 4096 Jan 19 22:40 ../
-rw-rw-r-- 1 airinei airinei 0 Jan 1 1970 benign_file.txt
-rw-rw-r-- 1 airinei airinei 18 Jan 1 1970 sh_profile_hijack
一方、OS付属の tar（この例では (GNU tar) 1.35）を実行すると次の結果が得られます:
malicious-payload$ tar -tvf malicious.tar
---------- 0/0 1024 1970-01-01 02:00 benign_file.txt
ファイルサイズが 1024 であることに注意してください
あるいは、放棄された tokio-tar 0.3.1 の代わりに astral-tokio-tar 0.5.6 を使用すると、アーカイブは正しく抽出されます。
CVE-2025-62518（TARmageddon）は、tokio-tar Rust ライブラリで発見されたセキュリティ脆弱性です（Rust の脆弱性 😮）。これは tar 形式のヘッダーの解析方法における論理エラーであり、攻撃者がファイルを密輸することを可能にします。
この欠陥は PAX 拡張ヘッダーを処理するロジックに存在します。TAR アーカイブには異なるヘッダータイプがあります:
USTAR: ファイル名、パーミッション、サイズを含む標準ヘッダー。PAX (Type x): アーカイブ内の次のファイルにメタデータ（非常に大きなファイルサイズなど）を提供するために使用される拡張ヘッダー。PAX ヘッダーが存在する場合、パーサーは標準の USTAR ヘッダーよりも PAX メタデータを優先してファイルの実際のサイズを解決する必要があります。
しかし、なぜ同じように見えるものに優先順位を持つ 2 種類のヘッダーが存在するのでしょうか？TAR 形式は古く（1988 年に標準化）、USTAR には制限があるためです（サイズは最大 8GB、ファイル名は最大 256 文字）。それが問題だったので、2001 年に PAX ヘッダーが追加され、より大きなファイルと長いファイル名を許可しました。
脆弱なバージョンの tokio-tar では、パーサーはファイルコンテンツリーダーに対して PAX ヘッダーのサイズを正しく採用しますが、次のファイルヘッダーの開始位置を決定するために USTAR ヘッダーのサイズを誤って使用します。
問題の核心はポインタの不一致です。脆弱なライブラリがファイルを処理するとき、ストリームを読み取るために2つの異なる内部「ヘッド」を使用します:
通常のアーカイブでは、これら2つのヘッドは一致します。TARmageddon では、それらを不一致に強制します。PAX サイズを 1024 に、USTAR サイズを 0 に設定することで、パラドックスを作成します:
benign_file.txt に格納します。0を見て、「すでにファイルの末尾にいる」と考えます。その場にとどまります。その結果、パーサーヘッドは1024バイトブロック内のデータを次の一連の命令として扱います。そのデータが有効なTARヘッダーのように見える場合、ライブラリはアーカイブの全体的な構造によれば技術的には存在しない2番目のファイルを「発見」して抽出します。
密輸ペイロード:
ペイロードは512バイトブロックのシーケンスとして作成されます。以下は malicious-payload ジェネレーターで使用されるレイアウトです:
| ブロック | 役割 | 説明 |
|---|---|---|
| 1 & 2 | PAX メタデータ | 次のファイルが1024バイトであると主張します。 |
| 3 | ベースヘッダー | benign.txt。サイズを0に設定することが重要です。 |
| 4 | 密輸ヘッダー | backdoor.sh。「データ」領域内に隠されています。 |
| 5 | 密輸データ | 悪意のあるコンテンツ（例: シェルエイリアス）。 |
| 6 & 7 | EOF | 標準のヌルブロック終端。 |
標準ツール（GNU tar など）は PAX サイズを正しく追跡するため、ブロック4と5を benign_file.txt に属する無害なバイナリデータとして認識します。ブロック4のヘッダーを「実行」することはありません。
このクレートの脆弱性はどのように悪用され得るのか、なぜアーカイブ内でファイルが密輸されることが重要なのでしょうか？
攻撃者は悪意のあるファイルをビルドシステムに密輸します。開発中またはCIマシン上でこれを展開すると、正当なビルドファイルを上書きし、そのマシンを侵害し、ビルドシステムを騙して悪意のあるファイルに署名させる可能性があります。
スキャナーが .tar を検査し、正しいモードでのみスキャンする場合、抽出時に望ましくないファイルが存在する可能性がありますが、スキャンされませんでした。
この 解説 に触発されました