これは、Set-user-ID および set-group-ID アプリケーションのみのセキュリティ上の問題です。ユーザー自体として実行されているアプリケーションの場合、問題の操作はいずれにせよオペレーティング システムによって拒否されるため、脅威はありません。
次のシナリオを考えてみましょう: UNIX プログラムがroot
set-user-id 経由で実行されているとします。プログラムは を使用access
して別のユーザーのファイル権限をチェックし、ファイルを として実行しますがroot
、権限チェックが成功した場合のみです。プログラムが と呼ばれsecurerun
、次のように実行するとします。
securerun myfile
攻撃者は、次のアルゴリズムを使用して、このセキュリティ ホールを悪用するプログラムを実行することができます。
xyz
ユーザーが実行権限を持つファイルを書き込む
- 2 つのスレッドを開始
A
し、B
- スレッド
A
は数ミリ秒待機し、実行cp norunning xyz
して、攻撃者が実行したいファイルに置き換えxyz
ますが、そのための実行権限はありません。
- スレッド
B
呼び出しsecurerun xyz
攻撃者がタイミングを合わせて運が良ければ、securerun
古い の実行権限を確認できますが、ハッカーが実行するはずのないxyz
新しいxyz
のコピーが実行されます。norunning
チェックと実行の間には短い時間枠があるため、攻撃者がループ内で何度も戦略を試みると、ある時点で幸運に恵まれることになります。