フォーラム: POPFile 全般 (スレッド #6036)

popfileがハングします (2004-09-25 01:08 by henrich #11148)

はじめまして。

あるメールを受信すると、popfileの動作が停止してしまう現象が起こっております。
当方の環境 (Windows2000 Professional SP4) では 0.22、および 0.22.1rc2 でも同様に動作が停止します。

該当のメールの文を一部編集して自分に送りつけて…というのを繰り返したところ、20行ほどで必ず停止するという状態になりました。

これが自分だけの現象かどうか、どなたか確認の協力をいただけないでしょうか?
(一歩間違うと popfile を無効化する exploit みたいになってしまいそうなんで、ちょっと怖いんですが)

RE: popfileがハングします (2004-09-25 01:42 by amatubu #11149)

ご報告ありがとうございます。非常に重大な問題ですね。

そのメールを、amatubu@users.sourceforge.jp まで送っていただけますでしょうか。
検証してみたいと思います。

停止する、というのは popfile*.exe のプロセスが終了してしまうということでしょうか?

http://popfile.sourceforge.net/cgi-bin/wiki.pl?JP_HowTos/CaptureErrors
を参考にして、エラーメッセージが取得できないでしょうか。終了してしまうという
ことですと、「コンソールにメッセージを表示させる」の部分になるかと思います。

よろしくお願いします。
#11148 への返信

RE: popfileがハングします (2004-09-25 13:33 by henrich #11153)

返信ありがとうございます。

状況としては、プロセスは停止していません。
しかし、処理自体が停止し、全く何も動作しない状態となっています。
CPU やメモリを大量に消費しているわけでもありません。本当に「停止」状態に見えます。
当然、webブラウザに対しても反応しません。

ログを取得してみました。
(1)------------------------------------------------------------------------------------
POPFile Engine v0.22.1 running
2004/9/25 13:25:49 1196: pop3: 514: Connected to mbox.xxxxxx.jp:110 timeout
60
UTF-16BE:Malformed LO surrogate dab3 at d:/POPFile/lib/Encode.pm line 184, <GEN2
> line 10.

(2)------------------------------------------------------------------------------------
UTF-16BE:Malformed LO surrogate dab3 at d:/POPFile/lib/Encode.pm line 184, <GEN8
> line 6.
------------------------------------------------------------------------------------

(1),(2)とも元は同じメッセージで、少しだけ編集を加えています(メッセージ中の行の位置を入れ替えました)。
Encode.pm周りでなんかあるのでしょうか。
とりあえず、後ほどメールを送付させていただきます。

#11148 への返信

RE: popfileがハングします (2004-09-25 14:51 by amatubu #11154)

ありがとうございます。
送っていただいたメールで問題が再現しました。

原因が判りましたので、本家にバグとして登録しました。
(私が以前作成してマージしてもらったパッチの中に存在した問題でした。すみません)
また、パッチを作成して投稿してありますので、お試しいただければと思います。
http://sourceforge.net/tracker/index.php?func=detail&aid=1034446&group_id=63137&atid=502956

もう少しいい方法があると思いますが、とりあえずバグを回避するようにしました。
#11153 への返信

POPFile 0.22.1RC4 にマージされる予定です(popfileがハングします) (2004-09-28 00:28 by amatubu #11204)

初学者フォーラムで報告いただいた別の問題のパッチとともに本家に報告しましたところ、
https://sourceforge.net/forum/message.php?msg_id=2777715
0.22.1RC4 にマージ予定との返事をいただきました。
https://sourceforge.net/forum/message.php?msg_id=2777722

0.22.1RC4 で修正されると思いますので、また確認していただけますでしょうか。

よろしくお願いします。
#11154 への返信

RE: popfileがハングします (2004-09-28 19:26 by qbin #11209)

同様の問題に私も悩まされています。
パッチでは、\x00(NUL)文字が問題であり、\xXXエンコードされた文字列が8ビットの時にデコードするようにし、問題を回避していると読みました。

しかし、エラーメッセージを読む限り、Unicodeにおけるサロゲートペアが不一致で発生する問題のように見えます。(サロゲートペアとは、Unicode(UCS4)でD800-D8FFの範囲を2文字分(4バイト)使って1文字を表現する方法です)
問題のエラーメッセージは、DAB3という不正なサロゲートペアが見つかったことを示しており、パッチを宛てた状態でも\xDA\xB3という表現はデコードされますから、残念ながら現象の解決にはならないと思われます。

また、私の環境では、Outlookで添付されたPDFファイル(Quoted-Printableエンコード)が問題を起こしているようです。

私がコードを読んだ限りでは、Encodeモジュールがエラーを無視する状態にもかかわらず、Unicodeを扱うモジュール中で処理を終了してしまうのが原因だと思いました。
本来ならばEncode::Unicodeモジュールを修正するべきですが、とりあえずconvert_encodeの中のfrom_to部分をevalで囲んでしまいエラーを捕捉するパッチを投稿しておきました。
ご査収頂き、問題なければ本家にバグ登録して頂ければと思います。
#11148 への返信

RE: popfileがハングします (2004-09-28 20:33 by qbin #11212)

修正パッチのを「バグ」ではなく、「パッチ」の方に投稿してしまいました。申し訳ありません。
また、修正パッチにもミス(条件が逆)がありましたので、再度アップロードいたしました。
お手数ですが、よろしくお願いします。
# フォーラムのスレッドもうまくつなげられていなかったらごめんなさい。
#11209 への返信

RE: popfileがハングします (2004-09-28 23:55 by amatubu #11216)

情報ありがとうございます。
確かにエラーメッセージを見るとエラーの原因は別のところにあるようですね。
パッチを作成して動作確認したところ問題が解消されたので早合点していました。

Quoted-Printable でも起こる、ということは、\xXX の形式でなく、
=XX の
形式でも同様のバイト列が並んでいればエラーになるということですね。
これはまずいですね。

教えていただいたサロゲートについてはまだよくわかっていないのですが、
Encode 2.02 のソース(Unicode.xs)
http://search.cpan.org/src/DANKOGAI/Encode-2.02/Unicode/Unicode.xs
や perlunicode - Perl における Unicode サポート
http://www.kt.rim.or.jp/~kbk/perl-5.8/perlunicode.html
を読むと、0xD800 ~ 0xDBFF からなる Hi Surrogate と、
0xDC00 ~ 0xDFFF からなる Lo Surrogate がセットになっている
という感じなのでしょうか。

エラーメッセージを見ると、LO surrogate のところでエラーになっている
ようですので、その前の HI surrogate のチェックは 0xDAB3 だから
クリア、その次をチェックすると、LO surrogate に該当しない、よって
エラー、という流れですかね。

Encode 内でエラーを回避する方法があるのかどうか、あるいは
Encode を呼ぶ前になんらかの対処ができるのかどうかというところが
気になりますが、ちょっと検証するための時間がとれません。

eval でエラーを回避するしか方法がなさそうであれば、パッチを本家に
登録してみていただけないでしょうか。
原因などを説明できるだけの知識を得て、現象を検証することができる
時間がとれるのはしばらく先になってしまいそうですので。
#11209 への返信

RE: popfileがハングします (2004-09-29 12:48 by qbin #11221)

お返事ありがとうございます。
本家にも下手な英語ですが、#1034145として登録しておきました。

あまつぶさんのパッチでは、\xXX形式のNUL文字のデコードが行われなくなるので、テキスト本文がUTF-16BEと判定される可能性が減り、一定の成果を挙げるのではないかと思います。
しかし、この問題はご推察の通りバイト列をEncode::from_toに渡すことでエラーが発生するので、PDFなどのQエンコードされたバイナリファイルには不十分だと判断した次第です。

Unicodeのサロゲートについては私も専門家でないため、詳しく理解していないですが、私もエラー原因について同様の認識をしています。

Encode内でエラーを回避する方法は、
<A HREF="http://search.cpan.org/~dankogai/Encode-2.02/Encode.pm#Handling_Malformed_Data">http://search.cpan.org/~dankogai/Encode-2.02/Encode.pm#Handling_Malformed_Data</A>
にて、解説されており、デフォルトの動作は、不正な文字を置き換えるとなっています。
しかし、Encode::Unicodeは、このCHECKの値(xs中のcheck変数)を調べておらず、不正なサロゲートペアが見つかった場合にcroakして実行を中断してしまうのが、根本的な原因と思われます。

従って、Encode::Unicode内でcroak(≒die)している問題が解決するまでは、POPFile側では回避策としてevalしてエラーを捕捉するのがよいと思いパッチを作成したものです。

現状では、エラーが起こった行は、(バイナリファイルとみなし)エンコード変換を行わないようになっていますが、UTF-16によるSPAMが流行るようであれば、POPFile内で正規化するなどの対策が必要でしょうね。
#11216 への返信

RE: popfileがハングします (2004-09-29 20:21 by amatubu #11229)

パッチの登録ありがとうございます。

私もわからないなりに少し調べてみました。
http://digit.que.ne.jp/work/index.cgi?Encode
こちらを参考にさせて頂きました。

CHECK について私も調べてみたのですが、たしかに Unicode.xs ではこれを使用して
おらず、終了してしまうようになっていますね。

もうひとつ、Encode::Guess.pm を確認してみたところ、
$Encode::Guess::NoUTFAutoGuess を 1 に設定することによって
UTF-8/16/32 と判定されることを抑制することができるようです。
自動判定ができなくなるので問題もあるかもしれませんが、ひとつの方法として
考えてみました。
ただ、これが使えるのは Encode 1.97 以降のようなので、それ以前は使えないのが
難点です。
(また、自動判定させなくても、意図的に UTF-16 でエンコードされたような
 ヘッダをつけたメールを送って POPFile をクラッシュさせることができる
 可能性が残ります)

いろいろ考えてみましたが、qbin さんが提案していただいた方法が一番よさそう
ですね。

今のところ、UTF-16 でエンコードされたメール自体見たことがないですので、
spam が UTF-16 を使うようになったとしても、UTF-16 だというだけで
spam と判定できるのではないかと思います。
(一般的に使われているメールクライアントが UTF-16 でエンコードされた
 メールをデコードできるのかどうか知りませんが)
個人的には、現時点では UTF-16 は無視してしまっても問題ないのではないかと
思います。
#11221 への返信

RE: popfileがハングします (2004-09-30 10:33 by qbin #11236)

あまつぶさんのフォローのおかげで、
RC5にマージされるようです。
ありがとうございます。

私の手元にもUnicodeのメールが届くことはほとんどなかったのですが、
最近のSPAM業者はUTF-8でメールを送ってきます。
UTF-16で送られるようになったら、もう少しまともな解決策を考えたいと思います。
#11229 への返信

RE: popfileがハングします (2004-09-30 12:58 by amatubu #11237)

パッチの作成、投稿ありがとうございました。
私も勉強になりました。

UTF-8 のメールは確かに時々届きますね。
UTF-16 で送られてきても、正しく書かれている場合には POPFile も
解釈することができるわけですから大丈夫なのではないかと思います。
不正なデータの場合は、受け取ったメールクライアントでも文字化け
などが起こると思いますし。

POPFile では、1行ごとにデコード処理を行っていますから、
途中に不正なデータが紛れ込んでいたとしても、その部分が解釈
できないだけで、それ以外の部分には影響ないと思います。
#11236 への返信