練習帳@blog

これからは写真中心で行きたい

EMAIL_FLAW_MIME_TAG_OVERFLOW

システム管理 セキュリティ

ふう。とりあえず大体分かったのでメモ。

「EMAIL_FLAW_MIME_TAG_OVERFLOW」の概要についてはトレンドマイクロのサイトを見てくれ。


「EMAIL_FLAW_MIME_TAG_OVERFLOW」っていうのは簡単に言えば、トレンドマイクロのInterScan VirusWallというソフトが出す警告メッセージ。この「Virus Alert」は、添付ファイルの名前がちょっと長いというだけで、「Have detected a virus (EMail_Flaw_MIME_Tag_Overflow) in your mail traffic」などという心臓に悪いメッセージをご丁寧に2通送信者ではなくて相手先に送りつけてしまう(という設定もできる)のでちょっとたちが悪い。

何でたちが悪いかというと、たとえば客先に出したメールがこれに引っかかると、

  • ウイルスつきメールを送りつけるような会社が、「システムのご提案」ですか(冷笑)
  • 徹夜で作った資料を期限前に送ったのに届かず。しかも警告メールが客先の「迷惑メールフィルタ」に引っかかってロストしたため送ったことさえ疑われる始末

なんてことが起こりかねないからだ。



で、調べたことは2点

  1. 「ちょっと長い添付ファイル名」とは具体的に何文字か
  2. このチェックを2007年にもなって有効にしていることは妥当か

「ちょっと長い添付ファイル名」とは具体的に何文字か

冒頭に上げたトレンドマイクロのサイトには以下のように書いてある

なお、ファイル名に日本語を使用している場合はメールデータ中にはそれをエンコードしたデータが入ります。
この場合でも文字数の比較はエンコードされたデータを対象に行うため、ファイル名に日本語を使用した場合は、ファイル名の文字数が設定した文字数よりも少なく見える場合でも制限に掛かることがあります。
例えばデフォルト設定の200文字となっている場合は、全角30文字程度でも制限に掛かることがありますのでご注意ください。

仕事で使っている以上「制限に掛かることがあります」では済まないので、調べてみた。諸般の事情で直接システムの設定を確認できないので、いろいろ試行錯誤*1。

「添付ファイル名のエンコード形式」というのはどうやらメールソフトによって違っているみたいなので、AL-Mailに限定*2。

AL-Mailでメールを作成すると、添付ファイル名はBエンコードされたencoded-wordになっている模様。

        name="=?ISO-2022-JP?B?GyRCJDgkZSQyJGAkOCRlJDIkYCQ0JDMkJiROJDkkaiQtGyhK?=
 =?ISO-2022-JP?B?GyRCJGwkKyQkJDgkYyRqJDkkJCQuJGckTiQ5JCQkLiRnGyhK?=
 =?ISO-2022-JP?B?GyRCJGwkKyQkJDgkYyRqJDkkJCQuJGckThsoQi50eHQ=?="

こんな感じ。で、トレンドマイクロのInterScan VirusWallは、このnameの""で囲まれた内部のバイト数によってチェックしている模様。たとえば、「EMAIL_FLAW_MIME_TAG_OVERFLOW」の検出を半角200文字以上とした場合、この""で囲まれた部分が200バイト以内なら大丈夫。

これがちょうど200バイトになるエンコード前の文字列の長さを計算すればOKなはず*3。


少し本筋とはずれるけど、Perlメモによれば、

RFC 2047 には本来 encoded-word に変換する必要のないもの，つまり，ASCII だけから 成る単語まで変換するのは推奨できないと 書かれています

とされているのだが、上記エンコード結果を見る限り、AL-Mailの添付ファイル名のエンコードはその辺一切気にせず拡張子も含めてエンコードしているようである。


まず、Bエンコードされたencoded-wordのうち、正味のエンコードデータのバイト数を計算する。デコード時に付加されるのは以下の部分。

  1. 1行ごとに先頭に「=?ISO-2022-JP?B?」、終端に「?=」がつく(合計18バイト/行)
  2. さらに各行ごとにJISのエスケープシーケンスが入る(JISのエスケープシーケンスはBase64エンコードにより4バイトとなるので、4*2バイト/行)

AL-Mailで実際に試したところ、200バイトの長さのファイル名は3行に分割してエンコードされるらしい。だから、エンコードされたデータ部分のバイト数は

  • 200-(18+4*2)*3(行)=122(バイト)

次にこのバイト数をデコードしたら何バイトの文字列になるかを計算する。

  1. 上の結果から正味のBase64の部分は最大122バイトだが、Base64ではトータルのバイト数は4倍数でなければならないので、実際の最大長は120バイトとなる。
  2. 120バイトぴったりエンコードされているとすれば、エンコードデータ1バイトは元データの6ビットに相当するので、元の文字列長は120*6=720ビット=90バイト
  3. AL-Mailは拡張子ごとエンコードしやがるので、拡張子部分を別にカウントするとすれば、実際のファイル名の部分は86バイト、全角43文字分に相当することになる。

と思って実際に以下のような「全角42文字+拡張子」のファイルを作って実験してみたがチェックに引っかかってしまった*4。

じゅげむじゅげむごこうのすりきれかいじゃりすいぎょのすいぎょうまつうんらいまつふうら.txt

実は添付ファイル名の""で囲まれた部分には、行頭スペース(2行目と3行目)や行末の改行(1行目と2行目)があり、この分も「ファイル名のバイト数」に含まれていたのだ。確かに""の内側ではあるんだが、まさかエンコード時に無視するスペースや改行まで200バイトに含まれると思いもせず半日くらい悩んでしまった。

で、気を取り直して、先の「エンコードされたデータ部分」として計算した122バイトから改行(1バイト*2箇所)とスペース(1バイト*2箇所)の分をを引いて計算しなおし。

  1. 上の結果から正味のBase64の部分は最大118バイトだが、Base64ではトータルのバイト数は4倍数でなければならないので、実際の最大長は116バイトとなる。
  2. 116バイトぴったりエンコードされているとすれば、エンコードデータ1バイトは元データの6ビットに相当するので、元の文字列長は116*6=696ビット=87バイト
  3. AL-Mailは拡張子ごとエンコードしやがるので、拡張子部分を別にカウントするとすれば、実際のファイル名の部分は83バイト、全角42.5文字分に相当することになる。つまりこんな感じ。

じゅげむじゅげむごこうのすりきれかいじゃりすいぎょのすいぎょうまつうんらいまつふうa.txt

エンコードの結果は、こんな感じ。

	name="=?ISO-2022-JP?B?GyRCJDgkZSQyJGAkOCRlJDIkYCQ0JDMkJiROJDkkaiQtGyhK?=
 =?ISO-2022-JP?B?GyRCJGwkKyQkJDgkYyRqJDkkJCQuJGckTiQ5JCQkLiRnGyhK?=
 =?ISO-2022-JP?B?GyRCJCYkXiREJCYkcyRpJCQkXiREJFUkJhsoQmEuZ2lm?="

この添付ファイルは無事InterScan VirusWallを通り抜けた。バイト数は193バイト。これ以上は多分無理。

  • 余談1
    • この添付ファイル名のエンコードはメールソフトによってばらばらだ。たとえばBecky!だと、同系統の「MIME」を選択すると、より短く改行するので30文字でも通らない。だから、一般向け文書としてはトレンドマイクロのサイトにある表現にならざるを得ないのだろう。
  • 余談2
    • Becky!ついでで、もう一点。添付ファイルの名前は、正式にはRFC2231に基づいてメールに埋め込むことになっている。Becky!にはこの設定で送信できるオプションがあるが、このオプションを使った場合、添付できる最大長(250バイト?)を超えた添付ファイル名を使ってもウイルス警告には引っかからない。これがどうしてなのかは調べていないが。


というわけで、AL-Mailで全角文字を含むファイル名の添付ファイルを送るときは、拡張子以外の部分が83バイトに収まるように名前をつければ、「EMAIL_FLAW_MIME_TAG_OVERFLOW」のチェックに引っかからずにすむということになる。


このチェックを2007年にもなって有効にしていることは妥当か

ついでにこちらも検討してみる。
このチェックはもともと以下のページに示されている「メールクライアントのセキュリティホール」に対応するための設定である。

当時は「開いただけで感染するウイルスメールがついに出現した」といった感じで結構話題になったような記憶がある。

が、この話は9年も前のこと。PCの世界で9年といえば3世代くらい昔の話だ。じつは冒頭のトレンドマイクロのサイトには以下のようなことが書いてある。

製品Q&A

該当するセキュリティホールはメールクライアントの開発会社各社から既に修正パッチが提供されており、最新のバージョンではほとんどが問題はなくなっているようです。
また、実際にこのセキュリティホールを利用してウイルスに感染したというような事例もこれまではありません。

バージョン3.51Jおよび、バージョン3.53Jではデフォルトが無効に変更されています。

一番びっくりなのが、真ん中の部分。

また、実際にこのセキュリティホールを利用してウイルスに感染したというような事例もこれまではありません。

がーーーん。発見から9年を経て一度も攻撃されていないセキュリティホールを守るために、会社の信用を犠牲にしてまで努力してきた俺たちって・・・・


さらに最終バージョンではデフォルトで無効となっている上、トレンドマイクロの最近の製品や他社製品ではこのセキュリティホールをチェックしていないっぽい。

そして、常識的に考えて「添付ファイル名によるBuffer Overrun」程度のセキュリティホールが対策されていないようなPCが9年間も無事なはずも無く、もし無事だったとすれば今後も影響を受けないような使用環境にあると思われるので、もしうちの会社に該当するPCがあってもまったく影響が無いような気がする。


というわけで、「会社の信頼」とか「業務上の手戻り」などの「EMAIL_FLAW_MIME_TAG_OVERFLOW」チェックによる損害とチェックしなかったことによるリスクを天秤にかけるまでもなく、速やかにこのチェックを無効化すべきだと思う。



こういうことばっかりしているから「社内のIT部門は頼りない」とか言われちゃうんだよなぁ。

*1:馬鹿馬鹿しいのだが仕方がない

*2:制式メールクライアントなのです・・・。

*3:JISコード、Bエンコードおよびencoded-wordの仕組みは、「日本語と文字コード」「第２３５章 base64の基礎」「Perlメモ　Base64エンコード・デコードする」などを参考にした

*4:長い名前といえばこれ