Foundry Networks ServerIron の URI 解析コードにある脆弱性は、ルールの迂回を可能にする

［翻訳：関谷　麻美］
2002年3月16日

国際海外情報

2002年3月28日（木） 12時00分

［翻訳：関谷　麻美］
2002年3月16日

◆概要：
　インターネット・トラフィックおよびコンテンツ管理スイッチのFoundry Networks 製 ServerIron Family は、7 つのスイッチングを介して高パフォーマンスなレイヤー 2 を提供し、ネットワーク責任者がその日に発生した激動の Web トランザクション、Web アプリケーションそして電子商取引のトラフィックの流れを制御し、管理することが可能になる。
　ServerIron スイッチは、URI を正しくデコードしない。結果、URI をデコードすることで、そのルールを迂回することが可能になる。

◆詳細：
　ServerIron スイッチの主要機能は、ルールに従ってサーバグループが HTTP要求のバランスをとることだ。一般的な構成は、静的コンテンツ用サーバーグループ、そして動的ページ用の他のグループを持っていることだ。

　この機能は、ServerIron のスイッチング・ルールの"url-map" キーワードで使用可能になる。そして、その要求に応じたサーバグループの選択に対して複数の方法（特に、着信 URI に単純に適合させる"パターン"方法）が利用できる。

　以下の構成、グループ #1 により処理される PHP スクリプト、グループ #2により処理される Perl スクリプト、そしてサーバグループ #3 により処理される静的ページだ。
url-map "p1"
method pattern
default 3
match .php 1
match .pl 2

　しかし、他の Web サーバと違ってServerIron スイッチは、URI をデコードせず、生のURI にパタンが適合する。

　Web サーバの場合、以下の要求は同等であり、その同じファイルに適合している。

http://web.example.com/index.pl
http://web.example.com/index.%70%6c

　残念なことに、ServerIron スイッチの場合、".%70%6c" は ".pl" に一致してない。つまり、その要求は次のルールに一致し、間違ったサーバグループに行くだろう。

　前述の構成では、その要求は静的コンテンツ専用のサーバにより処理される。PHP と Perl スクリプトのソースコードは、想定したサーバによって処理されず、クライアントに対し送信される場合がある。

◆回避方法：
　管理者は、ServerIron パターンフィルタリングを信用してはいけない。デフォルトで全てを拒否し、想定したパターンのみを許可することで、各 Web サーバに対する ServerIron のフィルタリングルールを複製すること。

静的コンテンツ・サーバ用 Apache 構成の見本：

Order deny,allow
Deny from all
<Files ~ ".(html|shtml|jpg|png)$">
Order allow,deny
Allow from all
</Files>

◆ベンダーの対応：
　この問題は、2002年2月12日に Foundry Networks サポート、　security@foundrynet.com (メールはエラーで返送された) とsupport@foundrynet.com に報告された。

　最初の回答は、次のようなものだった。『あなたは、正規のサポートコンタクト担当者がいますか？』
　（翌日の）二度目の回答は、『これは、弊社の ServerIron がサポートしている機能ではありません。弊社の販売担当者に連絡し、機能要求を提示してください』

　最終的に、2月19日 Foundry Networks の技術担当責任者から電話があり、彼はバグを認めた。そして、 ServerIron 製品では、ファームウェア版であるなしに拘わらず、URI のデコードが全く行われないことを述べた。

　それ以降、Foundry Networks に宛てた全てのメールに対する返答はない。公的回避方法もしくは修正プログラムが現在作成されているのか否かは、不明だ。

◆追加情報：
　Frank DENIS (Jedi/Sector One) がこの情報を提供した。

［情報提供：SecuriTeam］
http://www.securiteam.com/

《ScanNetSecurity》