チェック時から使用時まで

ソフトウェア開発において、チェック時間から使用時間( TOCTOU、TOCTTOU、またはTOC/TOU ) は、システムの一部 (セキュリティ資格情報など) の状態のチェックとそのチェック結果の使用を伴う競合状態によって発生するソフトウェア バグの一種です。

TOCTOU競合状態は、 Unixではファイルシステム上の操作間でよく見られますが^[1] 、ローカルソケットやデータベーストランザクションの不適切な使用など、他の状況でも発生する可能性があります。1990年代初頭、BSD 4.3 UNIXのメールユーティリティには、^[2]関数を使用していたため、一時ファイルに対して悪用可能な競合状態がありました。 ^[3] OpenSSH の初期バージョンには、Unixドメインソケットに対して悪用可能な競合状態がありました。^{[4]これらは現代のシステムでも問題のままです。2019年現在、} DockerのTOCTOU競合状態により、ホストプラットフォームのファイルシステムへのルートアクセスが可能になります。^[5]バンクーバーで開催された2023年のPwn2Ownコンテストでは、ハッカーチームがこのバグを使用して、更新されたTeslaモデル3のゲートウェイを侵害することができました。^[6]mktemp()

Unixでは、次のCコードをsetuidプログラム内で使用すると、TOCTOU バグが発生します。

if ( access ( "file" 、W_OK ) != 0 ) {     
    終了（1 ）;
}

fd = open ( "ファイル" 、O_WRONLY );   
書き込み( fd 、バッファ、sizeof (バッファ));  

ここで、access は、プログラムを実行した実際のユーザーがsetuid通常ファイルの書き込みを許可されているかどうかを確認することを目的としています (つまり、実効ユーザー IDではなく実際のユーザー IDaccessを確認します)。

この競合状態は攻撃に対して脆弱です:

accessこの例では、攻撃者はと の間の競合状態を悪用して、被害者openを騙してシステム パスワード データベースのエントリを上書きさせることができます。TOCTOU 競合は、マシンへの管理者アクセス権を取得するため の権限昇格setuidに使用できます。

この一連のイベントには正確なタイミングが必要ですが、攻撃者がそれほど困難なくそのような条件を整えることは可能です。

つまり、アプリケーションは、オペレーティング システムによって管理される状態 (この場合はファイル システムの名前空間) がシステム コール間で変更されないことを想定できないことになります。

TOCTOU 競合状態を悪用するには、攻撃者の操作が被害者の操作と適切にインターリーブされるように正確なタイミングが必要です。上記の例では、攻撃者はシステム コールをと のsymlink間で正確に実行する必要があります。最も一般的な攻撃では、攻撃者は被害者による各操作の後に実行されるようにスケジュールされる必要があります。これは、被害者の「シングル ステップ実行」とも呼ばれます。 accessopen

^{BSD 4.3 メールユーティリティと[2]}の場合mktemp()、攻撃者は単に1つのプロセスでメールユーティリティを起動し続け、別のプロセスで一時ファイル名を推測し、シンボリックリンクを作成し続けることができます。攻撃は通常1分以内に成功します。

被害者プログラムをシングルステップ実行する手法には、ファイルシステム迷路^[7]やアルゴリズム複雑性攻撃^[8]などがある。どちらの場合も、攻撃者はOSの状態を操作して被害者のスケジュールを制御します。

ファイル システム メイズは、被害者に OS キャッシュにないディレクトリ エントリを読み取らせ、OS はディスクからディレクトリを読み取っている間、被害者をスリープ状態にします。アルゴリズムの複雑性攻撃は、被害者に、キャッシュされたファイル名のカーネルのハッシュ テーブルをトラバースする単一のシステム コール内で、スケジュール クォンタム全体を費やすことを強制します。攻撃者は、被害者が検索するファイルと同じ値にハッシュされる名前を持つファイルを大量に作成します。

概念は単純であるにもかかわらず、TOCTOU 競合状態を回避および排除することは困難です。一般的な手法の 1 つは、事前チェックの代わりにエラー処理を使用することです。これは、LBYL (「行動する前によく考えろ」) ではなく、EAFP (「許可を求めるよりも許しを求めるほうが簡単だ」) の哲学に基づいています。この場合、チェックは行われず、仮定が保持されないことはエラーが返されることで示されます。^[9]

ファイルシステムのTOCTOU競合状態という観点から見ると、基本的な課題は、2つのシステムコール間でファイルシステムを変更できないようにすることです。2004年に、UNIXaccessとopenファイルシステムコールを使用する際にTOCTOU競合状態を回避するための移植可能で決定論的な手法は存在しないという不可能性の結果が発表されました。^[10]

この不可能な結果以来、ファイル記述子を追跡し、正確性を保証するためのライブラリが研究者によって提案されてきた。^[11]

研究コミュニティで提案されている代替ソリューションは、UNIX システムでファイルシステムまたは OS カーネルにトランザクションを採用することです。トランザクションは OS に同時実行制御の抽象化を提供し、TOCTOU 競合を防ぐために使用できます。製品版の UNIX カーネルではまだトランザクションを採用していませんが、Linux 用の概念実証研究プロトタイプが開発されており、Valor ファイルシステム^[12]や TxOS カーネル^{[13]などがあります。Microsoft} Windows ではNTFSファイルシステムにトランザクションが追加されましたが^[14]、 Microsoft はトランザクションの使用を推奨しておらず、将来のバージョンの Windows では削除される可能性があることを示唆しています。^[15]

ファイル ロックは、単一ファイルの競合状態を防ぐための一般的な手法ですが、ファイル システムの名前空間やその他のメタデータには拡張されず、ネットワーク化されたファイル システムではロックが適切に機能せず、TOCTOU 競合状態を防ぐこともできません。

バイナリの場合、システムコールを使用して実効ユーザーを変更してから呼び出しを実行することsetuidが解決策として考えられます。オペレーティングシステム間の違いが問題となる可能性があります。^[16]seteuid()open()setuid()

• 線形化可能性

• ビショップ、マット、ディルガー、マイケル (1996)。「ファイル アクセスにおける競合状態のチェック」(PDF)。コンピューティング システム。pp. 131–152。

• Tsafrir, Dan; Hertz, Tomer; Wagner, David; Da Silva, Dilma (2008)。「Hardness Amplification によるファイル TOCTTOU 競合の移植可能な解決」(PDF)。第 6 回 USENIX ファイルおよびストレージ テクノロジ カンファレンス (FAST '08) の議事録、サンノゼ (カリフォルニア州)、2008 年 2 月 26 ～ 29 日。189～ 206 ページ。