[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
find
やxargs
を,所有者ではない,または他の人の制御下にある
ファイルの検索や処理で使用している場合,セキュリティを考慮することは重
要です.locate
でも,他人に見られたくないファイルがある場合,関係
するセキュリティの考慮が適用されます.
一般的に,find
と関連プログラムに影響する最も厳しいセキュリティの
問題の形態は,第三者がそれらのプログラムによって,通常は実行できない何
かを実行することが可能になる状況になりうることです.これは,特権
の昇格(privilege elevation)と呼ばれています.これは,通常は削除不可能
なファイルの削除も含まれます.システムが定期的に,ごみ掃除の目的で
find
を呼び出すのも一般的です.このようなfind
の呼び出しは,
スーパーユーザから呼び出され,ファイルシステムの全階層を検索するので,
セキュリティの観点からは特に問題になります.関連する問題の重大さは,
find
の出力を元にシステムが実施することに依存します.
8.1 リスクのレベル | What is your level of exposure to security problems? | |
8.2 find のセキュリティの考慮 | Security problems with find | |
8.3 xargs のセキュリティの検討 | Security problems with xargs | |
8.4 locate のセキュリティの検討 | Security problems with locate | |
8.5 概要 | That was all very complex, what does it boil down to? |
[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
find
,xargs
,そして(程度は小さい)locate
の使用にお
いて,もともとセキュリティのリスクがあります.リスクの重大さは,使用し
ているシステムの種類に依存します.
他のユーザを制御(または信用)できない,他のユーザが操作可能なファイルシ
ステムの領域(例えば,‘/home’や‘/tmp’以下)を含めてfind
を実行するマルチユーザシステム.
他のユーザのアクションで任意のファイル名を作成することが可能で,
find
の実行中アクセスできないシステム.このアクセスには,放置され
たプログラムの実行(例えば,バックグラウンドのジョブ,at
や
cron
のタスク)が含まれます.この種のシステムでは,注意して書かれ
たコマンド(例えば,‘-print’の使用を避ける)は,高度な危険にならない
でしょう.ほとんどのシステムはこのカテゴリに分類されます.
信用できない連中がアクセスしない,自分で選んだファイル名を(リモートで も)作成できない,信用できない第三者のアクセスを増加させるようなセキュリ ティの欠陥が無いシステム.ほとんどのシステムでは,外部の人がシステムに 作成するファイルの名前に影響する方法がたくさんあるので,このカテゴリに 分類されません.例えば,これを書いているシステム自動的にソフトウェアを インターネットからダウンロードし,ソフトウェアを更新します.これらの更 新されるファイルには名前は,第三者が選択したものが存在しています (2).
上記の“リスク”とは,find
,xargs
,locate
,または,
それらのプログラムから制御される,他のプログラムで,期待しないことが実
行され得ることを意味します.提案したリスクのレベルは,事態の重大さを考
慮したものではありません.つまり,“低リスク”のシステムで処理をしてい
ても,セキュリティの問題の重大さは悲惨なものとなり,ここで議論されてい
ないものもたくさんありますが,すべての可能性のあるセキュリティの問題を
真面目に考えるべきです – マニュアルのこのセクションの目的は情報提供で
すが,総合的でも徹底的でもありません.
セキュリティの問題が非常に重要なシステムでの操作に責任がある場合,二つ のことを行うべきです.
[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
find
のセキュリティの考慮find
のアクションには,直接影響するものがあります.これには
-exec
と-delete
が含まれます.しかし,-print
の明示的
または暗黙の使用も一般的で,find
は間違ったファイル名のリストを生
成し,セキュリティの問題になり得ます.例えば,ファイルを削除するために
find
が生成したファイルのリストを考えてみてください.
我々は通常,find
のコマンドラインはファイルの選択の基準と,ユーザ
が考えているアクションを表現していると仮定します – つまり,コマンドラ
インは“信用できる”データだということです.
セキュリティの分析の観点から,find
の外部は正しくありません.つま
り,出力にはユーザがコマンドラインで指定した基準にマッチしたファイルの
名前だけが含まれているべきです.これを,-exec
と-delete
ア
クションに適用します.これらも出力の一部だと考える人もいます.
一方,ファイルシステムの内容は他の人も操作可能なので,我々はこれを“信
用できない”データだとみなします.つまり,find
コマンドラインは,
信用できないファイルシステムの内容を,出力ファイルの正しいリストに変換
するフィルタであることを暗示しています.
ファイルシステムは,一般的に,find
の検索中に変更されます.実際に,
find
がセキュリティの問題となる可能性のほとんどは,この問題にある
程度関連します.
競合状態は,(例えば) find
に渡されるアクションの順番に関連するセ
キュリティの問題に分類され,それ以外が重要です(3).
一般的に,普通は影響するはずがないファイルに対して,攻撃者が期待するア
クションでファイルやディレクトリの移動や削除を行います.また,このよう
なの攻撃は,find
に,普通は検索されない(例えば,-prune
アク
ションで抑止)ファイルシステムの一部を検索するようにしむけます.
8.2.1 現在の作業ディレクトリの変更 | ||
8.2.2 -execでの競合状態 | ||
8.2.3 -printと-print0の競合状態 |
[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
find
がファイルシステムを検索するとき,サブディレクトリを探し,
作業ディレクトリを変更しながら検索します.最初に,find
はサブディ
レクトリに注目します.サブディレクトリが検索する基準にあっている場合,
それが決定されます.つまり,‘-xdev’や‘-prune’式は考慮されます.
find
プログラムは,作業ディレクトリを変更し,ディレクトリの検索を
進めていきます.
競合状態の攻撃とは,‘-xdev’と‘-prune’に関連して一度調査された 後,攻撃者は考えられるディレクトリの名前を変更し,その場所を別の場所を 示しているシンボリックリンクを配置するといった形態になります.
この攻撃のは以後にある考えとは,find
が間違ったディレクトリに行っ
てしまう程度に愚かであるということです.これは,攻撃者が選択した作業ディ
レクトリでfind
を続け,‘-xdev’と‘-prune’で明示的に提供
された保護機能と,find
コマンドラインにリストアップされた特定のディ
レクトリ以外を利用できなくすることで提供される保護機能をバイパス
するということです.この形態の攻撃は,攻撃者がfind
コマンドを実行
するときが予測可能な場合,例えばcron
のタスク等で,特に問題になり
ます.
GNU find
には,この一般に分類される問題を避けるための,固有のセー
フガードがあります.これらのセーフガードの正確な形態は,システムの特性
に依存します.
8.2.1.1 O_NOFOLLOW | Safely changing directory using fchdir(). | |
8.2.1.2 O_NOFOLLOWが無いシステム | Checking for symbolic links after chdir(). | |
8.2.1.3 オートマウントでの作業 | These can look like race condition exploits | |
8.2.1.4 NFSサーバが落ちている問題 | If you don’t have O_NOFOLLOW, this is a problem. |
[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
システムがopen(2)
システムコールのO_NOFOLLOWフラグをサポートする
場合(4),find
は安全にディレク
トリを変更するとき使用します.目的となるディレクトリは最初にオープンさ
れ,find
はfchdir()
システムコールで作業ディレクトリを変更
します.これで,シンボリックリンクは確実にたどられなくなり,シンボリッ
クリンクの作成を使用する競合状態の攻撃の類は避けられます.
なんらかの理由でこの手法が動作しない場合,find
はO_NOFOLLOWがサポー
トされていない状況で一般的に使用される手法に戻ります.
以下を実行することで,システムがO_NOFOLLOWをサポートしてかどうか分かり ます.
find --version |
これで,バージョン番号と利用可能な機能が表示されます.例えば,私のシス テムでは以下のようになります.
GNU find version 4.2.18-CVS Features enabled: D_TYPE O_NOFOLLOW(enabled) |
ここで,実行しているfind
のバージョンがfindutils-4.2.18の前の
リリースの開発(CVS)コードからビルドされたことと,D_TYPEとO_NOFOLLOWの機
能が存在することが分かります.O_NOFOLLOWは“enabled”であると分かります.
これは,現在のシステムでO_NOFOLLOWをサポートしているらしいことを,簡単
に示しています.システムでビルドされたfind
がO_NOFOLLOWを定義
していて,O_NOFOLLOWフラグを無視するシステムで実行されている可能性があ
るので,この調査は必要です.我々は,開始時にオペレーティングシステムと
バージョン番号を調査することで,そのような状況の検出を試みます.このよ
うな状況では,“O_NOFOLLOW(disabled)”を代わりに見ることになります.
[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
O_NOFOLLOWフラグのサポートがが無いシステムで,この形式の問題を避ける戦
略はより複雑です.find
がディレクトリを変更するたびに,移動先のディ
レクトリを調査し,chdir()
システムコールを発行し,期待されている
サブディレクトリまで調査します.それ以外の場合,エラーメッセージを出力
し,find
はただちに終了します.この手法は,find
に意図しな
いファイルシステムの部分を検索させる,ファイルシステム操作の攻撃を妨げ
ます.しかし,“automount”のマウントポイントで問題となる無駄な断定を行
わないよう,特殊なステップが必要になります.
[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
オートマウントを使用中は,chdir()
システムコールの使用で,マウン
トポイントにマウントされた新しいファイルシステムに移動することが可能に
なる状況です.O_NOFOLLOWをサポートしていないシステムでは,find
の
セキュリティ調査に失敗します.
しかし,通常はセキュリティの問題にはなりません(通常はシステム管理者がオー
トマウントの構成を設定しているためです).そのため,chdir()
の正統
性の調査が失敗する場合,find
は新しいファイルシステムが現在のディ
レクトリにマウントされているかどうかを調査します.その場合,
find
は警告メッセージを出力し,動作を続けます.
この解決法を動作させるため,find
はマウントされているファイルシス
テムのリストを,開始時と,正統性の調査に失敗したときに読み込みます.マ
ウントされたときからディレクトリが移動されているかどうかを調べるため,
二つのリストを比較します.
[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
システムのマウントポイントごとに調査することは,非常に悪い方向です.一
般的に,find
は,ファイルシステムの一部だけを検索します.しかし,
find
はすべてのマウントポイントを調査します.システムに,信用でき
ないNFSサーバをマウントしたファイルシステムがある場合,find
はハ
ングアップし,NFSサーバが応答するまで待ち続けます.更に悪いことに,マウ
ントポイントが,find
が検索しないディレクトリツリーにあっても影響
します.
これは非常に不幸です.しかし,この問題は,O_NOFOLLOWをサポートしていな
いシステムだけに影響します.私が知る限り,そのようなシステムで,これら
三つのすべての問題を(競合状態,オートマウントの間違った警告,NFSサーバ
がダウンしていた場合のハングアップ)一度に修正することは不可能です.
find
で可能なより良いアイデアがあれば,メーリングリスト
bug-findutils@gnu.orgに電子メールを送って下さい.
[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
‘-exec’アクションでは別のプログラムを実行します.その時にファイル 名を渡します.そしてプログラムを呼び出します -通常- ファイルになんらか のアクションを実施します.ここでも,利用可能な競合状態があります.我々 は,コマンド例を以下のように指定します.
find /tmp -path /tmp/umsp/passwd -exec /bin/rm |
この見本例では,我々は削除する一つのファイルを識別し,削除するために
/bin/rm
を呼び出しています.find
が‘-exec’アクションを
処理する必要があることを決定する時点と,/bin/rm
コマンドが実際に
unlink()
システムコールを実施する時点に時間差があるので,問題が存
在します.このとき,攻撃者は‘/tmp/umsp’ディレクトリの名前を変更し,
‘/etc’へのシンボリックリンクに置換することが可能です.find
が想定しているのと同じファイルで,/bin/rm
を実施していることを調
査する方法はありません.一度シンボリックリンクが配置されると,実際に呼
び出したコマンドが意図している効果ではなく,攻撃者はfind
に
‘/etc/passwd’ファイルを削除させるようだますこともあります.
この形態の攻撃から守る一つの可能性として,‘-exec’の動作を
/bin/rm
コマンドを‘./passwd’引数で,適切なワーキングディレク
トリで実行するようにする方法です.これは,この形式の攻撃から守るために
find
が実行する,通常の健全性の調査でも可能です.残念ながら,この
戦略はPOSIX標準で指定されている物では利用不可能で,そこでは
‘-exec’でコマンドが呼び出されたカレントワーキングディレクトリと,
find
が呼び出されたカレントワーキングディレクトリは同じにする必要
があります.つまり,‘-exec’アクションは本質的にセキュリティが低く,
修正不可能だということを意味します.
GNU find
では,‘-exec’アクション等よりセキュリティが高い
‘-execdir’を実装しています.‘-execdir’アクションは,ターゲッ
トファイルを処理するため,サブディレクトリを参照しないようにする必要が
なくなるようにします.プログラムの呼び出しで使用されるカレントディレク
トリが,処理するファイルが存在するディレクトリと同じ(例では
‘/tmp/umsp’)になっていて,処理するファイルのベース名が呼び出しコマ
ンドに渡され,それには‘./’が(例では‘./passwd’)前置されます.
‘-execdir’アクションは,カレントディレクトリが$PATH環境変数 に含まれている場合,すべての動作を拒否します.これは,‘-execdir’が ファイルが見つかったディレクトリと同じディレクトリのプログラムを実行す るので必要になります – 一般的に,そのようなディレクトリは信用できない ユーザは書き込みません.同じような理由で,‘-execdir’は実行するコマ ンド名の‘{}’を許可しません.
[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
‘-print’と‘-print0’アクションは,幾つかの条件にマッチしたファ
イルリストを生成するために利用することが可能で,そのリストは他のコマン
ド,おそらくxargs
で使用することが可能です.残念ながら,これには,
find
が条件に合致した一つ以上のファイルを見つけたときと,関連する
コマンドが実行されるときの,やむおえない時間差が存在することを意味しま
す.このため,‘-print’と‘-print0’のアクションは,
‘-exec’同様にセキュリティが高くありません.
実際に,以下を考えてみます.
find .... -print | xargs .... |
これは,改行やその他の“空白”がファイル名にある場合,正しく対処できま せんし,引用符を含むファイル名への対応もいまいちですし,‘-print’ア クションは,‘-print0’ほどセキュリティが高くありません.
[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
xargs
のセキュリティの検討find
の‘-print’による競合状態の影響の記述は,find
の開
始後かつxargs
がすべてのアクションを完了する前に攻撃者がファイル
システムを変更する可能性がある場合,xargs
でセキュリティを高くす
ることが不可能なことを示しています.
しかし,攻撃者がリアルタイムでファイルシステムにアクセスできない場合で
さえも,セキュリティの問題が他にも存在しています.第一に,攻撃者がファ
イルシステム上に,自分が選んだ名前でファイルを作成可能な場合,
xargs
は‘-0’オプションを使用しない限りセキュリティが低くなり
ます.‘/home/someuser/foo/bar\n/etc/passwd’というファイル名が存在
する場合(‘\n’が改行文字を意味すると仮定します),find ...
-print
では,間違って三行に分割した行を出力するはずです.
/home/someuser/foo/bar /etc/passwd |
入力に改行がある場合,xargs
はそれを無視します.このため,このファ
イルリストを元に実施されるアクションには,これがfind
を実行し
ている人が期待していない‘/etc/passwd’ファイルが含まれます.攻撃者
がこの優位性を使用可能な状況も存在します.同じ状況は,ファイル名に改行
ではなく普通の空行が存在する場合も存在し,もちろん,ファイル名のリスト
には“余分な”改行は含まれていません.
この問題は,xargs
コマンドのデフォルトの動作,つまりPOSIX標準で指
定された動作の結果から回避することができません.この問題を避ける方法は,
xargs
の使用を避け,より好ましい‘find -exec’や(利用可能であ
れば)‘find -execdir’を使用したり,xargs
にファイル名が空白で
はなくASCIIのNUL文字で分離していると理解させる‘-0’オプションを使用
することだけです.しかし,このオプションは役に立ちますが,POSIXの標準で
は必須とされていません.
[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
locate
のセキュリティの検討locate
の出力を他のコマンドに渡すことは滅多にありません.しかし,
そうする場合は‘find ... -print’の使用と同じようなセキュリティの問
題が生じるでしょう.しかし,ファイル名の空白に依存する問題は,
locate
の‘-0’オプションで解決することが可能ですが,これでも
‘find ... -print0’に関連する競合状態の問題は残ります.
locate
では,これらの問題を避ける方法がありません.
[ < ] | [ > ] | [ << ] | [上] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
信用できない第三者が,システム上にファイルを作成できたり,作成したファ
イル名に化如することができる場合,find
,locate
,そして
xargs
の使用時には,以下以外のセキュリティの問題を知っておいてく
ださい.
プログラムが前もって準備されているファイル名のリストを使用し,それ以上 のアクションを実施しないように使用する.
指定した条件に合致したファイルを削除する‘-delete’アクションを使用 する.
PATH
環境変数が,信用されたプログラムだけが含まれているディレクト
リとなっている状況で,‘-execdir’アクションを使用する.
[ << ] | [ >> ] | [冒頭] | [目次] | [見出し] | [ ? ] |
この文書は新堂 安孝によって2009年9月22日にtexi2html 1.82を用いて生成されました。