[stalk:00409] Re: IIS CGI Filename Decode Error Vulnerability

[Shin <shin@xxxxxxxxx>]

　　　 「辞書買うのもったいないし、いちいち辞書めくるの面倒だな〜」　　　 

　　　　　　　　　　　　そんな時はインフォシーク！　　　　　　　　　　　　
　　　　「英和辞典」「和英辞典」「国語辞典」サービスはじめました。　　　　
　　　　　　　　  http://jiten.infoseek.co.jp/?svx=971128 　　　　　　　　
------------------------------------------------------------------------


In article <B728813C.4BFB%shikap@xxxxxxxxxxxx>
Shikap wrote:
>> WebServer自体がCGI実行直前部分にフックを組み込んでおいてくれて、
>> 最終的な実行ファイルをユーザがチェックして弾く処理を組み込むこと
>> が出来るようになっていればいいのですが…。
>
>つーか、そもそもなんで２回もDecodeせにゃいかんのでしょう、ってのが
>問題ではないかと。
>＃そこがいまいち納得できないんですよね。
>＃大抵のバグは「あぁ、そういうコーディングしちゃうかも」と同情する
>＃パターンなのですが。
>＃いまいち想像がつかないです、なぜこのようなコードになっているか。

これはありそうな話だと思っています。フレームワークから渡されたり、
ライブラリから返されたものが、エンコード/デコード済みである事を気
付かずに、アプリケーションが再びエンコード/デコードを行ってしまう
というバグですね。
デコード済みのものに対してデコードを行ってしまっても、通常の文字列
では変化がない場合が多いため、気付かないままになってしまうというの
も割とあるのではないかと思います。

# マークアップ言語の実体参照化を多重にやっちゃうなんてしょっちゅう
# ですから^^。
# ブラウザにユーザ入力の'<'を表示しようとして、"&amp;lt;"を返送し
# てしまって、画面が"&lt;"になってしまったり。
# これはすぐに気付けるからいいですけど逆は気付きにくいと思います。
# (実体参照の展開処理を二回やっても変化がないから)
# "&lt;" -> "<" -> "<"
# このバグに"&amp;lt;"を与えると"<"になるというのと同じケースです。


>どっちにしろ、パッチは当てましょう。ハニーポッドとして運用するなら
>ともかく。
>
>あと、IDSで検知するのは不可能じゃないですが、面倒です。
>だれかプリプロセッサ作ってくれませんか？(^^)

snort等でのパターン検出は、パッチが提供されるまでのしのぎ程度なの
でしょうか…。根っこを抑えるツールなら即座に(あるいは事前に)対策が
できるのにぃと素人ながらよく思うのです。

-- 
木下 信＠ひらつか
http://www.sk-jp.com/
ほんとにセキュリティ関連は素人です(サーバ運用経験なし)。
--
- このメイリングリストに関する質問・問い合せ等は
- <security-talk@xxxxxxxxxx>までお知らせください
--
------------------------------------------------------------------------
　　　　　　　　　　　ふとした疑問ありますか？　　　　　　　　　　　
　　 http://www.infoseek.co.jp/GHome?pg=gn_top.html&svx=971122