アカウント名:
パスワード:
IPAやウイルス対策ソフト側での協力が得られないのであれば、検疫を回避してしている可能性のあるアーカイブが展開されないように、UNLHA32.DLL側で対応し、ユーザの被害を軽減するのが筋というものではないでしょうか。どうしても展開したいユーザ向けにはオプションを残しておけば良い。
もちろん無保証のソフトウェアなので、どう対応するかは作者の判断ですが、この問題に対してUNLHA32.DLL側でも被害を軽減できる対応策があるのに、IPAやウイルス対策ソフトのせいにしてLZH書庫の使用中止を呼びかけるだけで対応策を取っていないと言うことはできると思います。
http://www2.nsknet.or.jp/~micco/vul/2010/mhvi20100425.htm [nsknet.or.jp] の下の方、
●UNLHA32.DLL 巨大なヘッダーによるバッファーオーバーフロー発生の脆弱性については対応が行われており, 次のような処理を行います:
* 4KB を超えるヘッダーを扱えない (当該メンバーを無視する) ウイルス対策ソフトが存在したことから, 構造に関わりなく全体が 4KB を超えるヘッダーについては, 破損ヘッダー (Exploit LHA) として扱われます。 ちなみに, 4KB というのはオリジナルの LHA が用意していたバッファーのサイズで, 比較的多くのソフトが, このサイズを, そのまま採用しています。 * ID 0x01, 0x02 等の拡張ヘッダー
問題は対策が十分か不十分か判定できないことにあるのではないですか?対策が十分ならLZH書庫の使用中止を呼びかけずに、UNLHA32.DLL等の使用を呼びかけるほか、他のLZH書庫解凍ソフトに対して注意喚起すれば良いはずです。
そもそも問題の本質はLZH書庫の定義の曖昧性にあるのだから、脆弱性があると指摘して騒ぎ立てるだけでなくて、どのような定義を採用するべきなのか提言がなされなければ、この問題は解決しません。そのような真の対策を取らずに、ただLZH書庫の使用中止を呼びかけているのが現状ということですね。
本質的にはウィルスチェックソフト側が対応しないと十分な対策とはなりません。LZH書庫解凍ソフト側が可能な対処は、ウィルスチェック側ですり抜ける可能性がある書庫についてエラー扱いするという所詮後ろ向きな暫定対処でしかありません。このような状況では特定のソフトを使えばOKなどと主張するのは無理です。
> 問題の本質はLZH書庫の定義の曖昧性にあるのだから
いいえ、定義自体は明確です。LHAオリジナルのソースがヘッダを固定長で処理をするという脆弱性を持っており、その作りを引きずっているソフトが他にも存在するというだけの話です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
検疫を回避してしまうLZH書庫を展開できないようにするべき (スコア:0)
IPAやウイルス対策ソフト側での協力が得られないのであれば、
検疫を回避してしている可能性のあるアーカイブが展開されないように、
UNLHA32.DLL側で対応し、ユーザの被害を軽減するのが筋というものではないでしょうか。
どうしても展開したいユーザ向けにはオプションを残しておけば良い。
もちろん無保証のソフトウェアなので、どう対応するかは作者の判断ですが、
この問題に対してUNLHA32.DLL側でも被害を軽減できる対応策があるのに、
IPAやウイルス対策ソフトのせいにしてLZH書庫の使用中止を呼びかけるだけで
対応策を取っていないと言うことはできると思います。
リンク先ぐらい読もうや (スコア:2, 参考になる)
http://www2.nsknet.or.jp/~micco/vul/2010/mhvi20100425.htm [nsknet.or.jp]
の下の方、
●UNLHA32.DLL
巨大なヘッダーによるバッファーオーバーフロー発生の脆弱性については対応が行われており, 次のような処理を行います:
* 4KB を超えるヘッダーを扱えない (当該メンバーを無視する) ウイルス対策ソフトが存在したことから, 構造に関わりなく全体が 4KB を超えるヘッダーについては, 破損ヘッダー (Exploit LHA) として扱われます。 ちなみに, 4KB というのはオリジナルの LHA が用意していたバッファーのサイズで, 比較的多くのソフトが, このサイズを, そのまま採用しています。
* ID 0x01, 0x02 等の拡張ヘッダー
UNLHA32.DLLを使っていれば安心なんですか? (スコア:0)
問題は対策が十分か不十分か判定できないことにあるのではないですか?
対策が十分ならLZH書庫の使用中止を呼びかけずに、UNLHA32.DLL等の使用を呼びかけるほか、
他のLZH書庫解凍ソフトに対して注意喚起すれば良いはずです。
そもそも問題の本質はLZH書庫の定義の曖昧性にあるのだから、脆弱性があると指摘して騒ぎ立てるだけでなくて、
どのような定義を採用するべきなのか提言がなされなければ、この問題は解決しません。
そのような真の対策を取らずに、ただLZH書庫の使用中止を呼びかけているのが現状ということですね。
Re:UNLHA32.DLLを使っていれば安心なんですか? (スコア:0)
本質的にはウィルスチェックソフト側が対応しないと十分な対策とはなりません。
LZH書庫解凍ソフト側が可能な対処は、ウィルスチェック側ですり抜ける可能性がある書庫についてエラー扱いするという所詮後ろ向きな暫定対処でしかありません。
このような状況では特定のソフトを使えばOKなどと主張するのは無理です。
> 問題の本質はLZH書庫の定義の曖昧性にあるのだから
いいえ、定義自体は明確です。
LHAオリジナルのソースがヘッダを固定長で処理をするという脆弱性を持っており、その作りを引きずっているソフトが他にも存在するというだけの話です。