（削除済）ジャンクションが脅威となるケース

Win32

勘違いだったので削除しました。すみません。
ここで書いていたジャンクションを利用したケースではファイルを開けないので、論点としたかった問題は起こりません。
名無しさんありがとうございます。


以下内容。
低い権限のユーザーが作成したジャンクションを高い権限のユーザーが利用することで低いユーザーは権限を越えてファイルアクセスできる、という趣旨です。
指摘についてはコメントを参照のこと。


最近セキュアなプログラミングというものを勉強したりしなかったりしているのだけど、その中でひとつ「これはどこかで（自分含む）誰かがやってしまいそうだ〜」というのがあったので紹介。

内容としては「/tmp とリンクファイルの悪用」として知られる脆弱性のことで、以下の条件がそろった場合に、低い権限のユーザーGuestは高い権限を持つプロセスServiceを使って重要ファイルを破壊することができる。

  1. ServiceはGuestが書き込み可能なパスに書き込みを行う（ファイル生成など）。
  2. GuestはServiceが書き込み行うパスを知っている、もしくは予測できる。
  3. Serviceは書き込みの際に書き込み先に対して十分な検証を行わない。

ケーススタディ

ここでは次の状況を想定しよう。

  1. 環境はXP。
  2. GuestはGuestユーザーとしてログインしている。
  3. Serviceは常にSYSTEM権限で動くサービスプロセスとして動作している。
  4. Serviceは定期的に以下の動作を行う。
    1. "C:\Document and Settings\All Users\Application Data\Temp\" というディレクトリがなければ作る。
    2. "C:\Document and Settings\All Users\Application Data\Temp\Service<日付>.tmp" というファイルがなければ作る。
    3. "C:\Document and Settings\All Users\Application Data\Temp\Service<日付>.tmp" にデータを書き込む。


Guestは重要ファイルを破壊するために何をするか。

  1. "C:\Document and Settings\All Users\Application Data\Temp\Service<翌日とかの日付>.tmp" というジャンクションを重要ファイルにリンクする形で作成する。

たとえば、

<略>\Temp>junction Service20100201.tmp C:\Windows\system32\ntoskrnl.exe

とする。Guestは依然としてこの重要ファイルに対する書き込み権限は持っていない。
しかしServiceが "Service20100201.tmp" に対して書き込みを行うと、実際には "C:\Windows\system32\ntoskrnl.exe" へ書き込みが行われる。書き込みはServiceの権限、つまりSYSTEM権限で行われるので許可され、結果として ntoskrnl.exe は不正に書き換えられる。

何が拙いのか

冒頭の条件部分の言い換えだけど、もう少し広くとらえると以下が満たされていることが問題の原因となる。

  1. 高い権限をもつプロセスが、低い権限のユーザーが書き込み可能なディレクトリに対する書き込みや読み取りを行っている。
  2. 書き込みや読み取りを行うパスが予測可能である。
  3. 書き込みや読み取りのときに対象の検証を行っていない。

読み取りの場合、ファイルの書き換えは行われないものの、意図しないファイルを読みとらせることが可能になる。この結果、意図しないフォーマットの読み取りで高い権限のプロセスにエラーを引き起こすことができるかもしれない*1。

どうすればよいのか（on Windows）

１については、SYSTEMプロセスの場合 GetTempPath 関数を使うと、Windows ディレクトリ以下の一時フォルダを返す*2。ここは書き込みが制限されているため低い権限からジャンクションが作成されることはなく、安全になる。
２については、GetTempFileName 関数を使うと一意のファイル名を生成できる。そのため既に存在するジャンクションのパスが使われることはなく、安全になる。
３については、パスだけではなく、ファイルのデータなどを参照して検証すれば安全になる。

まとめ

ねこかわいい


補足

実際には「単純に」システムファイルを破壊することはできません。
XPの場合、システムファイルが変更されても既存のキャッシュディレクトリからコピー復元されます（キャッシュディレクトリの中身まで書き換えればこの保護を回避できますが）。Vista以降の場合は、仮にSYSTEM権限であってもシステムファイルを変更できなくなっているので、この状況では問題は起こりません。
が、保護されていない独自のファイルがあったとしたら？　それを破壊することができるかもしれませんね。

セキュリティウォリア―敵を知り己を知れば百戦危うからず

セキュリティウォリア―敵を知り己を知れば百戦危うからず


ちゃんと検証せんかい！　　orz

*1:エラーの性質によってはこのケースの方が脅威になるかもしれない。

*2:厳密に言えば、デフォルトではそうなる。