[freewnn:00683] Re: security bug report

[aono@XXXX (Tomoki AONO)]

青野と申します。こんにちは。
＃あくまで個人的な意見です。

In article <20010814074746T.hiroo@oikumene.gcd.org>
hiroo@oikumene.gcd.org writes:

>> その1: とりあえずの回答案

その方向でよいと思います。

>> その2: bugtraq への報告について
>> ・patch ができるまで待ってとお願いしますか?
>> ・こちらの動きも鈍いので、それを待たずにさっさと開示してといってしまい
>>   ますか?

できれば前者が理想ですが、どちらでも構いません。（もし青野
の推測が当たっていれば）対策が大変そうな気がするので、オム
ロンソフト(Wnn6/7)の動きも知りたいような気がします。

>> その3: 問題のバグについて
>> ・こいつはきっと buffer over flow で、もらったデータを buffer に入れて
>>   いるところに boundary check をきちんといれれば OK という考えはあって
>>   いそうですか?

違うみたいです。(buffer overflowについては昨年gets_cur()の
修正で、すでに対策済みの模様です。www.freewnn.orgに載って
いるやつですね。) 報告者のサンプルコードの抜粋から推測する
と、（抜粋が前後します）

>> 田畑 = yusuke@kmc.kyoto-u.ac.jp wrote:

>> 田畑>    #!/usr/bin/perl
>> 田畑>    (略)
>> 田畑>     print S "\x00\x00\x00\x66\x00\x00\x00\x00".
>> 田畑>      "/tmp/hoge\x00".
>> 田畑>      "\x00\x00\x00\x00\x00\x00\x00\x03";

まっとうな JS_DIC_FILE_CREATE (Wnn/manual/7.Protocol/KKTP 
より)を実行しているように思えます。jserverが無批判にクライ
アントから指定されたファイルを作るのが問題だと思われます。
（ファイルを作ったところで、そこから何かできるかは不明です
が。）JS_HINDO_FILE_CREATE、JS_MKDIRなども同様の傾向がある
ように思えます。
＃JS_FILE_REMOVEは大丈夫そうに思えます。

クライアントから与えられたファイル名をそのまま信用できた時
代に作られたプロトコルだけに、/tmp などに作られることは想
定していなかったのではないでしょうか（、と言い切ってしまう
と少し悲しい気がしますが…）。

サーバ側に作れるファイル・ディレクトリは(jserverrcで指定さ
れた)jserver_dir 以下のディレクトリに限定するようにする
（パス名のチェックを付加する。./ とか ../ とかに要注意?）、
と言うのがすぐ思い浮かびました。しかしこの制限により、普通
にWnn を使っている人にも影響が出る可能性がありますので、こ
の辺りはもっとWnnに詳しい方のご意見をお聞きしたいのですが…。

＃もっと踏み込めば、接続時に渡されるユーザ名だけ認識して、
＃新規ユーザなら適当にサーバ側でファイルを作ってしまう（ク
＃ライアント側からのCREATE系リクエストは一切無視する）、…と
＃いうのも可能なのでしょうか?

>> ・対策が効いていることを調べるために、攻撃用のプログラムつくって
>>   FreeWnn ML で配ってしまった方がよいですかね。

それも一つの手だと思います。

>> % こういう時にどう動くかも、今はあやふやで「Project の公式回答」ってど
>> % う決まるんだろ??? という状態ですかねえ。

activeに動ける方が何人かいらっしゃればいいのですが…。
＃青野は、…Wnnがよく分かっていないのでその任にあらず、と
＃思っています。

以下、愚痴です。（暴言だと思うので、読み飛ばして下さい）

uumのBuffer overflowについてのBUGTRAQ-JPでの報告の時にも思っ
たのですが、ソースも公開されているソフトなのですから、なぜ
報告者はもう少し調べていただいて根本的な解消策の案を示さな
いのでしょうか。WorkaroundとしてのTCP 接続を無効にすること
ではなく、対策の大まかな指針でも示していただければ（対策パッ
チを作成すればなおベター）みんなが幸せになると思うのです
が…。
＃BUGTRAQの文化が分かってないので、もしお気を悪くされたら
＃ごめんなさい。
----
青野智樹	(aono@cc.osaka-kyoiku.ac.jp)