LZH書庫のヘッダー処理における脆弱性について

●LZH 書庫のヘッダー処理における脆弱性について

　LZH 書庫のヘッダー処理における脆弱性については， LHA for UNIX 1.14 における CVE-2004-0234 を始めとして，多くのソフトについて同様の情報が公開され修正が行われているところです。この脆弱性は， ID 0x01 (ファイル名) や 0x02 (パス名) の拡張ヘッダーに比較的長い名前が格納されていると，スタックやヒープ領域のバッファーオーバーフローが発生してしまうというものです。

　実は， LZH 書庫のヘッダー処理については，ソフトによってはヘッダー読込用バッファーのオーバーフローという同様の古典的で大きな問題が存在します。

　LZH 書庫のヘッダーは，「基本ヘッダー + 拡張ヘッダー」という構造になっています。このようなヘッダーに対しての読込処理には，大きく分けて次の 2 つのタイプが存在します：

比較的最近のソフトに多いもので，それぞれのヘッダーのサイズを事前にチェックした上で，それが収まるサイズのバッファーを動的に確保して読込処理を行う。
オリジナルのソースを利用したものなど古いソフトに多いもので，一定のサイズのバッファーを用意しておいて，そのバッファーにヘッダー全体 (基本ヘッダー + 拡張ヘッダー) を一括して読み込む。

　ここで問題となるのは後者のタイプです。少し考えれば解りますが，このタイプの処理を行う場合，用意されているバッファーに収まるサイズのヘッダーであるかどうかの確認が必要となります。ところが，そのチェックを行っていないソフトが意外と多いのです。それらのソフトでは CVE-2004-0234 と同様の問題が容易に発生してしまい，たとえ CVE-2004-0234 に対応していたとしても，実質意味を成していないことになってしまいます。実際， CVE-2004-0234 への対応を謳っているソフトの中にも，そのようなものが存在します。 (Lhaz 等。)

　さらに，この問題に対応していたとしても，後者の処理を採用しているソフトでは，それが新たな問題を発生させる場合があります。問題が発生するのは「ウイルス対策ソフト」等の場合です。

　多くの対応ソフトでは，バッファーが溢れてしまう大きなサイズのヘッダーが存在した場合，そこで書庫全体に対する処理を打ち切るか，当該メンバーを無視して次のメンバーの処理に移ります。通常のソフトであれば，これは別段問題のない無難な処理と言えます。

　ところが，ウイルス対策ソフト等の場合では，この点が大きな問題となります。 Norton AntiVirus 2006 等が該当するのですが，ウイルス対策ソフトが同様の処理を行った場合，無視されるようなメンバーについては，どのようなファイルが格納されていたとしても検疫等が一切行われないことになります。もちろん，展開等を行ってファイルとして作成された時点で検疫・削除等が行われるわけですが，プリビュー等，メモリー上に展開イメージが作成されるような処理の場合には，そのまま当該メンバーが扱われてしまいます。つまり検疫をすり抜けてしまうわけです。

　困ったことに， 7-Zip や WinRAR 等，海外起源の比較的メジャーなものを始めとした一部のソフトは，ヘッダー読込については前者の方法を採っているため，サイズにかかわらず正常にヘッダーの読込が可能となっています。さらに，書庫への対応が限定的となっていることから，特に h2 形式ヘッダーについて，サイズ情報と実際に読み込んだヘッダー全体のサイズとの整合性，ヘッダーの CRC，といった改竄等に関する重要なチェック処理が行われません。なぜか，この 2 つの傾向のセットで存在するソフトが多いのですが，このようなソフトは，ウイルス対策ソフト等でのチェックが行われない場合には，非常に危険な状況に陥ってしまいます。

　また， (ヘッダー読込に対して) 前者の処理を行っている場合でも，ウイルス対策ソフトの場合は，ヘッダー全体のサイズについてのチェックを行ってほしいところなのですが，実際には行われないことが多いようです。例えば， McAfee の VirusScan Enterprise 8.0i 等では， CVE-2004-0234 系の脆弱性利用が疑われるヘッダーが存在した場合には， Exploit-LHA に類する書庫として検疫・削除を行いますが， ID 0x01， 0x02 の拡張ヘッダーに対してのチェックしか行っていないため，比較的小さなサイズの拡張ヘッダーを多数用意したような書庫が検疫をすり抜けてしまいます。 CVE-2004-0234 系のものを検疫対象とするのであれば，このような書庫についても同様のものとして扱ってほしいところです。

　上記の例を組み合わせるだけでも，「少なくとも McAfee， Symantec 双方の多くの対策ソフトの検疫をすり抜ける，バッファーオーバーフローと格納ファイルによる二通りの攻略方法を施した書庫」が出来上がってしまいます。 LZH 書庫を扱う場合については，名前だけではなく，大きなサイズのヘッダーを無条件に拒否するようにしたほうが良いのかもしれません。

　Symantec には報告を行ってあるのですが，今のところ回答がありません。本国へ LZH 書庫についての詳細を説明したとしても「？」となりそう (以前に別のベンダーで経験あり。) だったので，国内へ報告したのが敗因だったのかしら…？

[Oct.23,2006：追記]

　「CVE-2004-0234 に対応していたとしても，実質意味を成していない」の部分について何件か問い合わせがあったのですが，もちろん「ある程度長いファイル名」による被害は防ぐことが出来ています。が，「(ID 0x01， 0x02 の拡張ヘッダーを利用する) 全く同じ手法を使い，単に (ヘッダー用バッファーが溢れるように) サイズを調整するだけ」で同様の結果 (リターンアドレス改竄) が得られてしまうのです。要は，「700 文字程度は大丈夫でも 5000 文字だとダメ。 (注：長さは一例。)」という結果が得られるわけで，そういった意味で「実質意味を成していない」と書いています。

　あと，「Trend Micro は？」といった声が聞こえてきましたが，試してみたウイルスバスター 2007 では「格納ファイルについてのチェック数」が報告されないので，検疫の有無は判りません。書庫が 1 つなら 1 としか報告されませんので。

[Oct.26,2006：追記]

　ウイルスバスター 2007 も検疫が行われませんでした。 @nifty でのメール送受信時も同様 (Trend Micro を採用。) でしたので， Trend Micro 製品も広範囲に該当するものと思われます。 Symantec を採用していることから， BIGLOBE によるウイルスチェックも同様 (検疫なし。) でした。それに対して， McAfee を採用している @nsk (この Web ページのプロバイダー。) では検疫が行われましたので，どうやらベンダーによる色分けが概ね可能のようです。

[Oct.27,2006：追記]

　とある ML で「NOD32 は？」といった声が上がったので試してみたのですが，このソフトでも検疫が行われませんでした。ここまでくると，「検疫できないソフトのほうが多い…どころか大多数を占める」恐れが…。

　それはともかく， NOD32 は NAV 2006 や VB 2007 とは異なった挙動を示し，どうやら， VirusScan Enterprise 8.0i を含めて，ヘッダーの処理方法に起因する検疫すり抜けパターンが存在するようなので，一覧しておきます：

すり抜けパターン	該当 (代表) ソフト	説　　　　明
7-Zip 型	該当なし	このタイプでは，基本，拡張，それぞれのヘッダー毎に必要な大きさのバッファーを動的確保した上で読込が行われます。従って，基本的にサイズによる制限が存在しないことから，格納ファイルが検疫をすり抜けてしまうこともありません。このタイプであれば安全と言えます。　余談ながら，このタイプの場合，自身に制限が存在しない分「ヘッダー全体のサイズに疎い」という弊害の出てしまう場合があります。　例えば， VirusScan Enterprise 8.0i では，上で書いたように CVE-2004-0234 に類するヘッダーが見つかった場合に Exploit-LHA として検疫・削除を行いますが，「比較的小さめのヘッダーを多数用意して全体として巨大なヘッダーを構築」したようなヘッダーは検疫対象とはなりません。　しかし，ヘッダー処理でのバッファーオーバーフローの脆弱性をもつソフトに対しては，このような書庫でも CVE-2004-0234 を利用した場合と殆ど同じ手法で攻撃が可能となりますので，一部抜けがあることになります。　ただ，これは「CVE-2004-0234 型のヘッダーを検疫対象とするのであれば，もう一方のタイプも検疫対象とすべきなのでは？」といった程度の問題でしかありません。他のソフトは，そもそも検疫対象とはしていませんので。反対に， Enterprize 8.0i が検疫対象としているのは，自身に CVE-2004-0234 方面の脆弱性が存在した経緯が影響しているのでしょう。(^^;)
LHA for UNIX 型	NOD32 V2.5， F-Secure Anti-Virus 5.72， F-Secure Anti-Virus 7.00	ここで言う LHA for UNIX は autoconf 版を指します。　このタイプでは，基本ヘッダーと拡張ヘッダーそれぞれに 4KB の固定バッファーが用意されていて，ヘッダー毎に，そこへ読込を行います。 4KB を超えるような拡張ヘッダーが存在した場合は，当該メンバーについての処理を打ち切ります。基本ヘッダーが 4KB を超えることはありません。　従って， 4KB を超える拡張ヘッダーの付加された格納ファイルが，検疫をすり抜けてしまうことになります。
オリジナル型	Norton AntiVirus 2006， Norton AntiVirus 2007，ウイルスバスター 2007， Virus Security 9.1.0046， avast! 4.7 Home Edition	「オリジナル」とは LHA.EXE を指します。　このタイプでは， 4KB の単一固定バッファーが用意されていて，そこへヘッダー全体を一括して読み込みます。その後，処理を行う中でヘッダーが 4KB を超えていると判断できた時点で，当該メンバーの処理を打ち切ります。　従って，ヘッダーの構造にかかわらず，全体が 4KB を超えるヘッダーの付加された格納ファイルが，検疫をすり抜けてしまうことになります。
例外型	VirusScan Enterprise 8.0i， McAfee VirusScan 11.0.213， CA Anti-Virus 8.1.0.203， AVG Anti-Virus 7.5.430	CA Anti-Virus は 7-Zip 型です。しかし，冗談のような話ですが， h2 形式に対応していませんので，昨今の LZH 書庫には無力です。(泣) McAfee VirusScan Enterprise 及び VirusScan (internet security suite)…というか， McAfee 製品全般については， 7-Zip 型なのですが，ご丁寧にヘッダー CRC のチェックを行い，合わないものについては書庫として扱わず，検疫が行われません。攻撃書庫は CRC の合っていないことが多いことから，半分無力となってしまっています。なにしろ，ここで取り上げた Lhaz， Lhaplus， 7-Zip， WinRAR の全てが CRC のチェックを行わないのですから…。 AVG Anti-Virus は LZH 書庫自体に対応していません。

[Oct.27,2006：追記 2]

　上の表に登場した対策ソフトについては，さすがにバッファーオーバーフローは発生しません，念のため。

　それと，昨日書いたメールによるテストについてですが，本物のウイルスを使うようなことはありませんので，お間違えの無いように。(笑) 　動作確認用として各ベンダーで共通して使用され，また Web 上でも公開されている EICAR を使用しています。

[Oct.28,2006：追記]

　上記の一覧について少々誤解されている方があるようなのですが，一覧されている対策ソフトが，振り分けられているタイプの処理を行っているとは限りません。あくまでも「そのタイプの処理を行った場合と同様の挙動を示している」に過ぎません。例えば， LHA for UNIX 型の処理を行っていたとしても，十分なサイズのバッファー (ヘッダー単体であれば上限値が存在します。) が確保されていれば，挙動は 7-Zip 型と同じになります。

[Oct.28,2006：追記 2]

　VMware のゲスト PC に導入している NIS 2007 について，上の一覧に追加しておきます。今後も人知れず追加されると思います。(笑)

[Oct.29,2006：追記]

　上で「人知れず追加」と書きましたが， 3 つほど追加したところで先が見えましたので，これ以上の調査は止めました。結論は大多数の対策ソフトですり抜けが発生するということになってしまうようです。(泣)

[Oct.29,2006：追記 2]

　「IPA に報告していないの？」といったような声も聞こえてきたのですが，「それにより当該対策ソフトに対して攻撃が可能」といった状況でもないと受け付けてもらえません。そうと知った上で敢えて (複数のベンダーが該当すると判明した) 26 日に打診してみましたが，当然のごとく却下されました。「それは対策ソフトの機能・性能の問題。ただし，それを利用して別の脅威が考えられる場合には，届出対象となる可能性あり」という見解だったのですが，後者にも当たらないという判断のようですね。要は「攻撃対象となったソフトの脆弱性であり，今回の件とは別問題」ということなのでしょう。すでに「別問題」として片付けられるような規模でなくなりつつあるような気もしますけれど…。(^^;)

　あと，上で書いた「本国へ直接報告したものの理解してもらえなかった」の部分について「そりゃ，あんたの英語が下手だったからでしょ？」という突っ込みがあったのですが，いえ，最初だけは確かに下手な英語でしたけれど，あとは現地の日本人スタッフと日本語でのやりとりでしたから。(笑)

●ARJ 書庫のヘッダー処理における脆弱性について　<Oct.21,2006>

　実は LZH 書庫の場合と同様の問題が ARJ 書庫にも存在します。むしろ，ヘッダーのサイズに限って言えば形式に限らない問題なのかもしれません。それはともかく， ARJ 書庫ではファイル名等の情報が基本ヘッダーに SZ 形式で記録されていることから，こと名前に関しては，こちらのほうが深刻と言えます。

　まず，ヘッダー読込に関してですが， LZH 書庫と異なり， ARJ 書庫の場合は動的バッファーを採用した場合でもバッファーオーバーフローの危険があります。というのも，上述したように，ファイル名などの名前やコメント情報が SZ 形式で記録されているからです。もしヘッダーの CRC を確認しなかった場合，名前を扱おうとした段階で容易にバッファーオーバーフローが発生してしまいます。幸い， LZH 書庫に対して CRC チェックを全く行っていなかった 7-Zip や WinRAR でも ARJ 書庫に対してはチェックを行うようになっていますので，問題は発生しません。

　次に，名前に関してですが， (拡張ヘッダーの) サイズ情報と SZ 形式という違いはあれども CVE-2004-0234 と同様の問題が発生する可能性があり，実際この部分でバッファーオーバーフローの発生してしまうソフトが存在します。 (Lhaplus 等。) 　もっとも， Lhaplus の場合は CRC のチェックを行っていないので，ヘッダーサイズのほうで問題が発生しているのかもしれませんけれど…。

　さらに，ここでも Norton AntiVirus 2006 等は検疫を行ってくれません。恐らく，書庫に限らず同様の問題が発生するのでしょう。「扱えないものは処理を打ち切ってしまえばよい」という方法で済む類のソフトではありませんので， Symantec には動的バッファーによる方法を採用してもらいたいところです。

[Oct.30,2006：追記]

　ARJ 書庫の場合でも，各ソフトのバッファーサイズの違いにより， LZH 書庫と同様の問題が発生しますので，一覧しておきます。総じて小さめのヘッダーしか扱えないことから，テストデーター自体がオリジナルの限界サイズとの差が小さい点に注意してください：

すり抜けパターン	該当 (代表) ソフト	説　　　　明
動的確保型	NOD32 V2.5， CA Anti-Virus 8.1.0.203， avast! 4.7 Home Edition	LZH 書庫の場合と同様，動的にバッファーを確保して読込を行っていると考えられますが，テストデーター自体が比較的小さなヘッダー (それでもメジャーどころのアーカイバー等が全滅する程度の大きさ。) となってしまっているため，大きめのバッファーを採用しているソフトが，ここに該当してしまっている恐れがあります。　ここに該当するソフトは，他に比べて，より安全と言えます。
7-Zip 型	VirusScan Enterprise 8.0i， McAfee VirusScan 11.0.213，ウイルスバスター 2007， F-Secure Anti-Virus 5.72， F-Secure Anti-Virus 7.00	このタイプでは，オリジナルより僅かに大きい 2.5KB 超の固定バッファーが用意されていて，そこへ基本ヘッダーを読み込みます。拡張ヘッダーについては，バッファーへの読込を行わず単純にスキップしていると思われますが， Win 環境で作成された書庫には拡張ヘッダーが存在しないため，詳細は判りません。　従って，基本ヘッダーが約 2.5KB を超えるヘッダーの付加された格納ファイルが，検疫をすり抜けてしまうことになりますが，多くのソフトと同等のバッファーであることから，比較的安全と言えるかもしれません。
オリジナル型	Norton AntiVirus 2006， Norton AntiVirus 2007， AVG Anti-Virus 7.5.430	「オリジナル」とは UNARJ.EXE を指します。　このタイプでは， 2.3KB 弱の固定バッファーが用意されていて，そこへ基本ヘッダーを読み込みます。拡張ヘッダーについては，バッファーへの読込を行わず単純にスキップします。　従って，基本ヘッダーが 2.3KB を超えるヘッダーの付加された格納ファイルが，検疫をすり抜けてしまうことになります。 7-Zip 型と僅かな違いではありますが，その差による影響は大きいと思われます。
例外型	Virus Security 9.1.0046	Virus Security 9.1.0046 は ARJ 書庫に対応していませんので， ARJ 書庫には無力です。(泣)

●ZIP 書庫のヘッダー処理における脆弱性について　<Oct.31,2006>

　ZIP 書庫においても，ファイル名等の名前が 64KB まで記録できる仕様となっていますので， LZH や ARJ 書庫と同様，問題の発生が考えられます。こちらについても 64KB の名前が記録されたものを使用して，興味本位でテストを行ってみたのですが，予想外の結果 (全勝と予想。) となりました：

すり抜けパターン	該当 (代表) ソフト	説　　　　明
直接取得型	Norton AntiVirus 2006， Norton AntiVirus 2007， VirusScan Enterprise 8.0i， McAfee VirusScan 11.0.213，ウイルスバスター 2007， F-Secure Anti-Virus 5.72， F-Secure Anti-Virus 7.00， CA Anti-Virus 8.1.0.203， AVG Anti-Virus 7.5.430	このタイプでは， (単一) ヘッダー全体ではなく，ヘッダー内の項目毎にバッファーへ読み込むか，直接情報を取得します。バッファーは動的，若しくは仕様上最大となる 64KB (+ α) 固定のものが使用されることから，基本的にサイズの制限が存在しませんので，格納ファイルが検疫をすり抜けてしまうこともありません。このタイプであれば安全と言えます。
固定項目長型	NOD32 V2.5， Virus Security 9.1.0046， avast! 4.7 Home Edition	このタイプでは，バッファー等については動的確保を行っているなど，すり抜けに繋がる処理とはなっていませんが，当該ソフトの既定値を超えた長さの名前が記録されているなどの場合に，処理を打ち切ってしまいます。そういった意味では，「ヘッダーのサイズ」ではなく「項目のサイズ」に制限のあるタイプといえます。　従って，メンバー名の偽装を行ったものなど (ヘッダーの CRC が存在しませんので容易に行えます。)，簡単に格納ファイルの検疫すり抜けが発生してしまいます。 Virus Security と avast! が 4KB 程度のものまでは検疫できたのに対して， NOD32 は 1KB のものが，すでに検疫できませんでした。

●UNLHA32.DLL

　巨大なヘッダーによるバッファーオーバーフロー発生の脆弱性については，比較的最近の Ver 1.98b で対応が行われています。サイズチェック自体は行っていたものの， h0/h1 形式での拡張ヘッダー読み込み時における全体サイズのチェックが抜けてしまっていたのが，その理由です。開発用 PC にソースが残っていて即時の参照が可能だった 6 年前の Ver 1.51 以降については，次のような処理を行います：

4KB を超えるヘッダーを扱えない (当該メンバーを無視する) ウイルス対策ソフトが存在したことから， Ver 2.53 以降では，構造に関わりなく全体が 4KB を超えるヘッダーについては，破損ヘッダー (Exploit LHA) として扱われます。ちなみに， 4KB というのはオリジナルの LHA が用意していたバッファーのサイズで，比較的多くのソフトが，このサイズを，そのまま採用しています。
Ver 1.98b 以降では，全体が 8KB を超えるヘッダーについて (通常の) 破損ヘッダーとして扱われます。
Ver 1.98b より前の版では h2 形式のみ 8KB を超えるヘッダーについて (通常の) 破損ヘッダーとして扱われます。 h0/h1 形式については，バッファーのサイズから推測して， Ver 1.55c 以降では概ね 512KB，それより前の版では概ね 64KB を超えると脆弱性が表面化し， 8KB～512KB (64KB) のものについてはオーバーフローは発生しているものの， (サイズ (8KB) を超えた領域が展開処理等の段階まで使用されないことから) 表面化しないものと思われます。
CVE-2004-0234 等， ID 0x01， 0x02 の拡張ヘッダーに関する脆弱性は， Ver 1.51 の時点で対応が行われています。 Ver 2.53 以降では， 512 文字を超えた名前が記録されていた場合には，破損ヘッダー (Exploit LHA) として扱われます。
メンバー名の改竄や隠蔽を意図したと思われるヘッダーサイズとデーターサイズの不整合については， Ver 2.53 以降では破損ヘッダー (Exploit LHA) として扱われます。
Ver 1.55c 以降では，ヘッダーサイズとデーターサイズの不整合について警告ログが出力されます。

●UNARJ32.DLL　<Oct.21,2006>

　巨大なヘッダーによるバッファーオーバーフロー発生の脆弱性については，元々 UNARJ.EXE が既定のバッファーサイズを超えるものをヘッダーとして扱わないようになっていることから，基本的には対応済みといえます。開発用 PC にソースが残っていて即時の参照が可能だった 6 年前の Ver 0.43 以降については，次のような処理を行います：

既定のサイズ (3KB 弱) を超えるヘッダーについては，ヘッダーとして扱われません。
CVE-2004-0234 と同様の名前情報に関する脆弱性は， Ver 0.43 の時点で対応が行われています。
LZH 書庫と異なり，特にメンバー名の改竄や隠蔽を想定した特殊なチェック処理は行っていません。 UNARJ32.DLL は該当しませんが， CRC チェックを行わないようなソフトの場合は，この方面の危険性が存在すると思われます。

●LHMelt (LMLzh32.DLL)

　巨大なヘッダーによるバッファーオーバーフロー発生の脆弱性については， h0/h1 形式での拡張ヘッダー読み込み時における全体サイズのチェックが抜けてしまっているため，現行の Ver 0.09 (LHMelt Ver 1.52c に付属。) でも未対応部分が残ってしまっています。次のような処理を行います：

4KB を超えるヘッダーを扱えない (当該メンバーを無視する) ウイルス対策ソフトが存在したことから， Ver 0.10 以降では，構造に関わりなく全体が 4KB を超えるヘッダーについては，破損ヘッダー (Exploit LHA) として扱われます。
Ver 0.10 より前の版では h2 形式のみ 8KB を超えるヘッダーについて (通常の) 破損ヘッダーとして扱われます。 h0/h1 形式については，バッファーのサイズから推測して，概ね 512KB を超えると脆弱性が表面化し， 8KB～512KB のものについてはオーバーフローは発生しているものの， (サイズ (8KB) を超えた領域が展開処理等の段階まで使用されないことから) 表面化しないものと思われます。
CVE-2004-0234 等， ID 0x01， 0x02 の拡張ヘッダーに関する脆弱性は，全ての版で対応が行われています。 Ver 0.10 以降では， 512 文字を超えた名前が記録されていた場合には，破損ヘッダー (Exploit LHA) として扱われます。
メンバー名の改竄や隠蔽を意図したと思われるヘッダーサイズとデーターサイズの不整合については， Ver 0.10 以降では破損ヘッダー (Exploit LHA) として扱われます。
ヘッダーサイズとデーターサイズの不整合について警告ログが出力されます。

MHVI#20061019： LZH 書庫のヘッダー処理における脆弱性について