[freewnn:00761] Re: security bug report

[aono@XXXX (Tomoki AONO)]

青野と申します。
＃最近よくここで口を出してますが、以下は全て個人的意見です。
＃対応についてはメンバーの方々で考えられているかもしれません。

<4185.1002001398@ideon.st.ryukoku.ac.jp>の記事において
kjm@rins.ryukoku.ac.jpさんは書きました。

>>   セキュリティ・スタジアム 2001 実行委員の小島です。

いつもセキュリティホールmemoを読んで参考にしています。

>> <http://www.st.ryukoku.ac.jp/~kjm/security/sec-stadium/>
>> 
>>   セキュリティ・スタジアム 2001 において、春山さんが本脆弱性を用い
>>   た攻撃を実施しました (のだと理解しています)。
>> 
>> <http://www.st.ryukoku.ac.jp/~kjm/security/sec-stadium/ml-archive/sec-stadium/msg00603.html>

具体的にファイルを作成した以上の攻撃をされた、ということで
しょうか。それならば興味があるので教えていただきたく思いま
す。
＃上記URLからは読みとれなかったので。

また、どの位「古い」Wnn6だと問題が生じるのかも読み取れませ
んでした。手元にあるSolaris8についているWnn6 (OSのPatchを
当てたかどうかは覚えていません。stringsで調べるとR2.34らし
いです) で元々報告された方(以下「報告者」)の作成したスクリ
プト(cf. [freewnn:00688]。ただし個人的に改変してます)を使
用して作成できないのは確認しました。
＃Wnn7 は購入しましたが試していません(インストールしていま
＃せん)。

上記URLやセキュリティホールmemo(2001.10.02の項)で例示され
ているのは'../'を使用したものですが、Wnn4.2 / パッチなし
FreeWnn / --enable-unsafe-path付き FreeWnn-currentでは絶対
パスを使えば辞書を作成できます(ファイルシステムでの所有者・
パーミッション以上の制限はなし。パスやファイル名のチェック
はしていない)。

報告者によるexploitスクリプトでは絶対パスで指定されていま
したが、どこで'../'が追加されたのか（こうすると辞書作成で
きるWnnが増える?）個人的には気になります。ちなみに
[freewnn:00699]の うかい@Debian氏によるパッチ(多分Debianパッ
ケージに入っているものと同等のもの。以下「Debianパッチ」) 
では'../' は取り除かれます。

そのほか気になったのは「コマンドを認証なしに受け取ってしま
う」という表現ですが、そもそも(Wnn7も含めて)Wnnのプロトコ
ルに認証という概念はないと青野は理解しています。辞書ファイ
ルごとのパスワード設定(ただしパスワードは他のファイルから
読み込むようになっています)や、(Wnn6以降では)ホスト名・ユー
ザ名(自称でもOK)によるアクセス制限(JS_OPENコマンド受信時?) 
はありますが、telnetのような接続時のユーザ認証はありません。
＃青野が[freewnn:00683]で書いたのは、
＃>> jserverが無批判にクライ
＃>> アントから指定されたファイルを作るのが問題だと思われます。
＃だったのですが。

>>   セキュリティ・スタジアム 2001 としては本件について情報を公開すべ
>>   く準備中なのですが、正式な情報/fix が登場していない (ように見え
>>   る) のが私としては気がかりです。

動ける人（特にセキュリティ関係の得意な人）がいないので、ず
るずると延びているように見受けられます。このままだと、（私
見ですが）現在activeな方々だけでは早期に検証・発表できない
可能性があります。
＃どなたか手伝える方いませんか > ALL?

ご存知の通り、dsl.gr.jpのCVSツリーにはDebianパッチが取り込
まれていますので、次のリリース/alpha(いつ出るかは分かりま
せんが)には必ず含まれるでしょう。1.10については…Debianパッ
チだけ抜き出してbackport作ってみましょうか。青野としては、
1.1.1を出してもらって1.10をObsoleteにしてもらった方が(古す
ぎるので)うれしいです。

小野氏から報告者には公表について判断を任せる旨返事している
はずです(cf. [freewnn:00686])。しかし私も公式声明を出した
方がよいと思います。
＃すでにセキュリティホールmemoで公表されていますし…。

>> 題名: [freewnn:00701] Re: security bug report
>> (<20010817091847Q.hiroo@oikumene.gcd.org>) において
>> Hiroo ONO さんがおっしゃるには:

>> | home directory の下に自分用の辞書をおいたりする場合もあるので
>> | (permission の問題でうまく動かなかったりするので、これも現状通りはちょっ
>> | と問題があると思っていますが)、個人的には他の策がないかなと思っています。
>> 
>>   どこに書くにせよ、辞書ファイルがどのディレクトリにあるはずかとい
>>   う情報は jserver が握っているはずですから、そのディレクトリ以下
>>   には書き込めない、という動作がいいのかなあと思うのですが、どうで
>>   しょう。jserver_dir のかわりに (jserver_dir と共に?)、そのディレ
>>   クトリを使えばいいのですよね?

（話がそれますが）[freewnn:00701]が出された時に、Wnn-FAQ
(http://www.tomo.gr.jp/wnn/wnn-faq.html)にある「!」を使っ
たクライアント側のホームディレクトリに(ユーザのパーミッショ
ンで)頻度ファイルなどを置く方法を考えたのですが、Wnn6-SDK 
を利用したクライアント(kinput2, Mule, emcws)では自分でWnn6
用の頻度ファイルを作るのでWnn4ベースのjserverではファイル
形式が違うというエラーになってしまいました。ファイルの形式
が分かればサーバ側で何とかできそうな気はしますが、未対策で
す。
＃ソースを見る限り、tamagoやwnn7-egg(omronsoft.co.jpをみた
＃ら、ダウンロードできるようになってますね。)は一旦サーバ
＃側に作らせたあとそれをクライアント側に転送・使用する方法
＃をとっているのでこの問題は起きません(多分)。

>>   セキュリティ・スタジアム 2001 の ML には次のように書いたのですが、
>>   このような状況認識で合っているでしょうか?
>> 
>> <http://www.st.ryukoku.ac.jp/~kjm/security/sec-stadium/ml-archive/sec-stadium/msg00612.html>

(今のところは)Debianパッチで当面しのげると考えて、結論が出
ていないと思われる事項については今後の課題扱いになっている
のではないかと思います。

>> * 特定ディレクトリの下にしか書けない
>>   home に置く場合は、たとえば ~/.wnndic/ 下のみとか

認証手段のない(unix domain socketなら可能?)現時点で安易に
ホームディレクトリにおくのは結構危険な予感がします。また、
通常jserverはユーザwnnで動作するので、最悪の場合world
writableにする必要があるのがいまいちなところです。
＃危険なのはjserver_dirの下でも同じですが…。

…以上長々と書いてみたのですが、いかがでしょうか > Project
メンバーの皆様
----
青野智樹	(aono@cc.osaka-kyoiku.ac.jp)