[English | Japanese]
最新版はおそらく安全だとは思いますが、確実とは言えません。 Namazu は完全に無保証です。すべてあなたの責任のもとに運用し てください。ただし、セキュリティの問題にはできる限り対応する つもりです。まずい点を見つけたら連絡してください。
クロスサイトスクリプティング (cross-site scripting)
は、外部からの入力をそのまま HTML として解釈させて
しまうことによって、任意の HTML タグを埋めこんだり、script を実行
させることができてしまう問題を意味します。
サーバ側に直接なんらかの問題は発生しませんが、クライアント側に
(時によっては多大な)影響を与えることがあります。特に、cookie を
利用しているようなサイトでは、その値が第三者に漏洩する可能性があり、
cookie の用途によっては非常に危険です。
クロスサイトスクリプティングに関しては以下の情報が参考になります。
2.0.13 以前までの namazu.cgi はタブ(%09)から始まる検索文字列を指定すると、
検索文字列がサニタイズされなくなり、クロスサイトスクリプティング脆弱性が発生します。
2.0.14 以降では先頭のタブを削除することで、この問題に対処しました。
JVN#904429FE
1. namazu.cgi及び.namazurcをwebから参照できない位置に移動する。以下の
説明では/usr/local/libに移動したものと仮定して説明している。
2. 本来のnamazu.cgiに変えて以下のスクリプトを作成し、適切な実行権限を
与える。
2.1. sh を使った方法
#!/bin/sh
QUERY_STRING=`echo "$QUERY_STRING" | sed -e 's/y=%09/y=%20/g'`
export QUERY_STRING
/usr/local/lib/namazu.cgi
#!/usr/bin/perl
$ENV{QUERY_STRING}=~s/y=%09/y=%20/g;
system("/usr/local/lib/namazu.cgi");
2.0.10 以前までの namazu.cgi は警告などを標準エラー出力に出力して いましたが、一部の web server の実装は標準エラー出力と標準出力を同一に 扱うものがあり、その結果クロスサイトスクリプティング問題を引き起こす ことがありました。具体的には Microsoft の Internet Information Server 4.0, 5.0 が該当します。
この問題を解決するために、2.0.11以降では NMZ.warnlog というファイルに 警告を出力するよう変更して対処しました。
CGI の仕様には、 標準エラー出力の扱いについては言及されていません。おそらくは web server 側の問題だとは思われますが、こういった問題のある実装がある以上、 CGI 作成者はこの点に注意する必要があると思われます。
Namazu は正規表現による検索をサポートしています。複雑な正規表現を 与えることによって、CPU に負荷をかけることが可能な場合があります。
利用するサーバリソースを制限することで、CGIの過剰稼働でサーバが 他の処理に悪影響を与えるのを防ぐことができます。
Apache 2.0では、RLimitCPU／RLimitMEM／RLimitNPROCディレクティブを 利用することでサーバリソースを制限できます。
[UNIX限定]
標準では namazu.cgi は 60 秒で処理を打ち切るようになっています。
2.0.13 よりこの値を設定で変更可能にしました(SUICIDE_TIME directive)。
[UNIX/Windows共通]
正規表現検索そのものも無効にすることもできます(REGEX_SEARCH directive)。
外部に公開するサーバで Namazu を利用する場合は、状況に応じてこれらの値を 設定するようにして下さい。
Windows 版の Namazu で OLE コントロールフィルタを使用した場合に、
マクロウィルスを含む Office 文書ファイル(Word, Excel, Powerpoint,
一太郎文書他)を処理した場合に、ウィルスに感染する可能性を完全には
否定できません。
マクロウィルスを含む Office 文書ファイルを Office アプリケーション
(Word, Excel, PowerPoint, Visio, 一太郎他)で開くのと同程度の危険性
です。
Microsoft Office の古いバージョンやセキュリティ設定を変更している場合
はマクロが実行される可能性があります。
念のため、mknmz で処理する文書は予めアンチウィルスソフトでウィルスの
除去を行うようにしてください。
また、ウィルス対策 API に対応したウィルス対策ソフトがインストール されている場合は、OLE コントロールフィルタが Office 文書ファイルを 開いたときに、ウィルスチェックが働きます。この機能を併用すること をお勧めします。
例) Norton AntiVirus 2005
Namazu Project が提供する OLE コントロールフィルタは、現在のところ
olemsword.pl, oleexcel.pl, olepowerpoint.pl, oletaro.pl, olertf.pl,
olevisio.pl です。
この他に第三者が作成した OLE コントロールフィルタもあります。
Namazu 2.0.15 の mknmz に追加されるオプション --decode-base64 は、
電子メール/ネットニュースに添付されたBase64エンコード部分をデコード
して取り出り出します。
マクロウィルスを含む Office 文書ファイルが電子メール/ネットニュースに
添付されている場合、--decode-base64 で取り出して OLE コントロール
フィルタで処理を行うと、「OLE コントロールフィルタに関する注意」と
同様にウィルスに感染する可能性があります。
念のため、mknmz で処理する電子メール/ネットニュースは予めアンチウィルス
ソフトでウィルスの除去を行うようにしてください。
マクロウィルスを含む Office 文書ファイルがアーカイブファイルに含まれて
いる場合、OLE コントロールフィルタで処理を行うと、「OLE コントロール
フィルタに関する注意」と同様にウィルスに感染する可能性があります。
念のため、mknmz で処理するアーカイブファイルは予めアンチウィルスソフト
でウィルスの除去を行うようにしてください。
Namazuでは、複数の言語の切替えにテンプレートファイルを用いています。 言語の指定は環境変数LANG、もしくはCGIパラメータのlangによって 行われます。 特定の状況下で、LANGパラメータに相対パス表現をあたえることで リモートユーザーがサーバ上にある任意のファイルにアクセス できてしまします。 これは ディレクトリトラバーサル(directory traversal)と呼ばれる問題です。
この問題は以下の手順によって発生します。
同様の問題が、resultパラメータにもあります。
特にWindows環境下では、相対パスに存在しないディレクトリを含んでいても ファイルにアクセスすることができます。以下はその実例です。
C:\Documents and Settings\Administrator>type ..\..\foo\..\boot.ini [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS (略)上記の例では、C:\fooというディレクトリは存在していません。 Linuxシステム上では、存在しないディレクトリを含むパスへの アクセスはできませんが、他のUnix系システム全てがどうかについては 確認できていません。
この問題はNamazu 2.0.16で修正されました。特にWindowsを 使っているユーザはアップグレードすることを強く推奨します。
pnamazu にもresultパラメータで同様の問題があります。もしpnamazuを使っている場合は 最新版にアップグレードすることを推奨します。
Namazu 2.0.17 以前の namazu.cgi は、デフォルトではレスポンスヘッダの
ContentType に charset を出力しません。
このため、Web ブラウザは namazu.cgi の出力結果からエンコードを自動認識して表示しています。
UTF-7 エンコーディングされた文字列を検索式に指定した場合、namazu.cgi の 出力に UTF-7 エンコーディングされた文字列がほぼそのまま含まれてしまいます。 この時、Web ブラウザのエンコード自動認識により UTF-7 と誤認することがあります。(主に英語サイトの場合)
このため、検索式に UTF-7 エンコーディングされたスクリプトを指定すると、
ユーザのブラウザ上で任意のスクリプトを実行される可能性があります。
(クロスサイトスクリプティング脆弱性)
この対策のため、Namazu 2.0.18 ではレスポンスヘッダの ContentType に 必ず charset を出力するように修正しました。
Namazu 2.0.18 にバージョンアップすることで、この問題を回避することができます。
また、Namazu は 2.0.6 以降、レスポンスヘッダの ContentType を .namazurc で直接指定する機能を有しています。
このため、.namazurc の ContentType に charset を含めて指定することで、
Namazu 2.0.17 以前のバージョンでもこの問題を回避することができます。
例1) 日本語の場合(UNIX) ContentType "text/html; charset=EUC-JP" 例2) 日本語の場合(Windows) ContentType "text/html; charset=Shift_JIS" 例3) 英語の場合 ContentType "text/html; charset=ISO-8859-1"
Namazu 2.0.18 以降では、ContentType に charset が含まれない場合は、 言語に対応する charset を自動的に追加します。 Namazu がデフォルトでサポートしていない言語の場合は、Charset ディレクティブで言語に対応する charset を指定することができます。
例) eo(エスペラント語)を ISO-8859-3 に対応付ける Charset "eo" "ISO-8859-3"
バッファオーバーランとは、プログラムの不具合によりデータ領域外のメモリを書き換えることで誤動作を起こす代表的なセキュリティホールです。 バッファオーバーランを悪用した不正アクセスが行なわれる可能性があります。
Namazu 2.0.19 以前では、NMZ.field.* に空行がある場合で、そのフィールド値を NMZ.result.* で表示する場合にバッファオーバーランを起こします。
この問題は Namazu 2.0.20 で修正されました。
バージョンアップすることを強く推奨します。
この文書の必要性を気づかせてくれた荒木靖宏氏に感謝します。
Namazu に存在していたクロスサイトスクリプティング脆弱性は、 高木浩光氏(独立行政法人産業技術総合研究所)及び 花井亮氏(NECフィールディング.東日本CSD)によって発見されました。 両氏よりのご報告に感謝します。
リソースの消費に関する問題は、sheepman / TAMURA Takashi 氏に指摘を 受けました。同氏のご報告に感謝します。
タブ(%09) から始まる検索文字列による問題は、発見者によって 情報処理推進機構(略称: IPA)に届出られたもので、 JPCERTコーディネーションセンター（略称: JPCERT/CC）の協力の下、 脆弱性関連情報を提供していただきました。ご報告に感謝します。
CGIパラメータlangによるディレクトリトラバーサル問題は、 Jeff Porter氏によって発見されました。御報告に感謝します。
「Web ブラウザのエンコード自動認識の誤認による UTF-7 エンコーディング された検索式の脆弱性」に関する問題は、 「はせがわようすけ」氏に指摘を受けました。同氏のご報告に感謝します。