アカウント名:
パスワード:
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 等の拡張ヘッダーについては， 512 文字を超えた名前が記録されていた場合には， 破損ヘッダー (Exploit LHA) として扱われます。 * メンバー名の改竄や隠蔽を意図したと思われるヘッダーサイズとデーターサイズの不整合については， 破損ヘッダー (Exploit LHA) として扱われます。
まぁ十分とは限らんが、無対策と責められるほどではない。
問題は対策が十分か不十分か判定できないことにあるのではないですか？対策が十分ならLZH書庫の使用中止を呼びかけずに、UNLHA32.DLL等の使用を呼びかけるほか、他のLZH書庫解凍ソフトに対して注意喚起すれば良いはずです。
そもそも問題の本質はLZH書庫の定義の曖昧性にあるのだから、脆弱性があると指摘して騒ぎ立てるだけでなくて、どのような定義を採用するべきなのか提言がなされなければ、この問題は解決しません。そのような真の対策を取らずに、ただLZH書庫の使用中止を呼びかけているのが現状ということですね。
対策が十分ならLZH書庫の使用中止を呼びかけずに、UNLHA32.DLL等の使用を呼びかけるほか、 他のLZH書庫解凍ソフトに対して注意喚起すれば良いはずです。
「良いはずです」と言われても……。 Micco さんとしては、この「すり抜け」の問題は本来ウイルス対策ソフト側が対処するべきであるところ、 UNLHA32.DLL 側で何とか問題を軽減しただけなわけです。「自分のできる範囲で手は打ったけれど、根本的な対処が期待できないから、早いところ LZH アーカイブの使用をやめた方が良いよ」と呼びかけるのは整合的だと思いますよ。
人ではないですがUNLHA32.DLLの命を、育て親が（一部を）捨ててしまう選択肢というのは、人情としていたたまれない気持ちです。
現状、その他の選択肢も思いつかないですが・・・
本質的にはウィルスチェックソフト側が対応しないと十分な対策とはなりません。LZH書庫解凍ソフト側が可能な対処は、ウィルスチェック側ですり抜ける可能性がある書庫についてエラー扱いするという所詮後ろ向きな暫定対処でしかありません。このような状況では特定のソフトを使えばOKなどと主張するのは無理です。
> 問題の本質はLZH書庫の定義の曖昧性にあるのだから
いいえ、定義自体は明確です。LHAオリジナルのソースがヘッダを固定長で処理をするという脆弱性を持っており、その作りを引きずっているソフトが他にも存在するというだけの話です。
DOSの時代ならいざ知らず、Win32以降は事実上Miccoさんと統合アーカイバプロジェクト [madobe.net]がLZH書庫の規格を管理してきたようなものなのに、両者を事実上無視したソフトや孫引き、曾孫引き、玄孫引きのソフトが多くなって、互換性の維持すら困難な状況になっていますので、そんな青臭い理想を現実化しただけでどうにかなるような現状ではないですよ。
実際問題、三年半近く前に見つけたこの脆弱性に対し、今までにどれだけの(半端なものを含めて)互換ソフトがどれだけ対応したかを考えれば解るかと。
互換性維持云々にかんして言えばUNLHA32.DLLがソース公開してないのも原因のひとつじゃないか、という気がしなくもないですが。ソース公開してたんなら脆弱性対策版出したからこっち使えで、3年半もあればかなり対策すすんだんじゃないかと思います。
身から出た錆なので問題が対処困難である理由を互換性維持云々にもとめるのはどうかと思う、という話で、いまさらUNLHA32.DLLのソース公開しろという気はありません。
本家を無視した孫引き、曾孫引き、玄孫引きのソフトに関しては、本家がソースを公開していてもそこへ辿ってきて読むとは思えないですが…。それともソースさえあればコピペするためにやって来るものなのでしょうか？
本家＝オリジナルのLHAのソースを使いまわしていると思われる、ヘッダが4KB以上だと期待通りに処理できないソフト（アンチウィルスソフトも含む）に関しては、UNLHA32.DLLの初期段階からソース公開しておけばある程度は効果があったと思いますが。
ぶっちゃけ本家の脆弱性まで律儀に受け継いでいるから困っているわけで、今回の脆弱性に関して言えば本家を無視してくれないと困るというか。
現行版と連続性のある脆弱性対策済み版のソースが公開された方が脆弱性対策されやすいよねという話が、なんで脆弱性が長期間指摘されなかったという話に摩り替わってるんだろう。
#1776397はgzipの事例から前者は必ずしも真ではなない、って話。UNLHA32.DLLの開発初期っていったら10年以上も前なんだから、勝手に後者に限定して話をされても困るんだがな。
そもそも今回の騒動が未知の脆弱性によるものだったのであれば#1776397 [srad.jp]の指摘にも価値があると思いますが、今回の騒動は既知の脆弱性に対する認識不足で対処が徹底していなかったのが原因なのですから#1776397 [srad.jp]は完全に筋違いだ、としか評しようがないような。
勝手に後者に限定しているのではなく
DLL不要のアーカイバがシェアを伸ばす↓そのアーカイバが不正な圧縮ファイルを作成するバグを出す↓苦情がなぜかMiccoさんのところに殺到する↓Miccoさん大激怒↓アーカイバサイト閉鎖、のちにこっそりと復活
という事もありましたね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
検疫を回避してしまう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 等の拡張ヘッダーについては， 512 文字を超えた名前が記録されていた場合には， 破損ヘッダー (Exploit LHA) として扱われます。
* メンバー名の改竄や隠蔽を意図したと思われるヘッダーサイズとデーターサイズの不整合については， 破損ヘッダー (Exploit LHA) として扱われます。
まぁ十分とは限らんが、無対策と責められるほどではない。
UNLHA32.DLLを使っていれば安心なんですか？ (スコア:0)
問題は対策が十分か不十分か判定できないことにあるのではないですか？
対策が十分ならLZH書庫の使用中止を呼びかけずに、UNLHA32.DLL等の使用を呼びかけるほか、
他のLZH書庫解凍ソフトに対して注意喚起すれば良いはずです。
そもそも問題の本質はLZH書庫の定義の曖昧性にあるのだから、脆弱性があると指摘して騒ぎ立てるだけでなくて、
どのような定義を採用するべきなのか提言がなされなければ、この問題は解決しません。
そのような真の対策を取らずに、ただLZH書庫の使用中止を呼びかけているのが現状ということですね。
Re:UNLHA32.DLLを使っていれば安心なんですか？ (スコア:2)
「良いはずです」と言われても……。 Micco さんとしては、この「すり抜け」の問題は本来ウイルス対策ソフト側が対処するべきであるところ、 UNLHA32.DLL 側で何とか問題を軽減しただけなわけです。「自分のできる範囲で手は打ったけれど、根本的な対処が期待できないから、早いところ LZH アーカイブの使用をやめた方が良いよ」と呼びかけるのは整合的だと思いますよ。
Re:UNLHA32.DLLを使っていれば安心なんですか？ (スコア:1)
人ではないですがUNLHA32.DLLの命を、育て親が（一部を）捨ててしまう選択肢というのは、人情としていたたまれない気持ちです。
現状、その他の選択肢も思いつかないですが・・・
＃壮大なストーリ。空転するアイディア。
Re: (スコア:0)
本質的にはウィルスチェックソフト側が対応しないと十分な対策とはなりません。
LZH書庫解凍ソフト側が可能な対処は、ウィルスチェック側ですり抜ける可能性がある書庫についてエラー扱いするという所詮後ろ向きな暫定対処でしかありません。
このような状況では特定のソフトを使えばOKなどと主張するのは無理です。
> 問題の本質はLZH書庫の定義の曖昧性にあるのだから
いいえ、定義自体は明確です。
LHAオリジナルのソースがヘッダを固定長で処理をするという脆弱性を持っており、その作りを引きずっているソフトが他にも存在するというだけの話です。
Re: (スコア:0)
DOSの時代ならいざ知らず、Win32以降は事実上Miccoさんと統合アーカイバプロジェクト [madobe.net]がLZH書庫の規格を管理してきたようなものなのに、両者を事実上無視したソフトや孫引き、曾孫引き、玄孫引きのソフトが多くなって、互換性の維持すら困難な状況になっていますので、そんな青臭い理想を現実化しただけでどうにかなるような現状ではないですよ。
実際問題、三年半近く前に見つけたこの脆弱性に対し、今までにどれだけの(半端なものを含めて)互換ソフトがどれだけ対応したかを考えれば解るかと。
Re: (スコア:0)
互換性維持云々にかんして言えばUNLHA32.DLLがソース公開してないのも原因のひとつじゃないか、という気がしなくもないですが。ソース公開してたんなら脆弱性対策版出したからこっち使えで、3年半もあればかなり対策すすんだんじゃないかと思います。
身から出た錆なので問題が対処困難である理由を互換性維持云々にもとめるのはどうかと思う、という話で、いまさらUNLHA32.DLLのソース公開しろという気はありません。
Re: (スコア:0)
本家を無視した孫引き、曾孫引き、玄孫引きのソフトに関しては、本家がソースを公開していてもそこへ辿ってきて読むとは思えないですが…。
それともソースさえあればコピペするためにやって来るものなのでしょうか？
Re: (スコア:0)
本家＝オリジナルのLHAのソースを使いまわしていると思われる、ヘッダが4KB以上だと期待通りに処理できないソフト（アンチウィルスソフトも含む）に関しては、UNLHA32.DLLの初期段階からソース公開しておけばある程度は効果があったと思いますが。
ぶっちゃけ本家の脆弱性まで律儀に受け継いでいるから困っているわけで、今回の脆弱性に関して言えば本家を無視してくれないと困るというか。
期待薄 (スコア:0)
Re: (スコア:0)
現行版と連続性のある脆弱性対策済み版のソースが公開された方が脆弱性対策されやすいよねという話が、なんで脆弱性が長期間指摘されなかったという話に摩り替わってるんだろう。
Re: (スコア:0)
#1776397はgzipの事例から前者は必ずしも真ではなない、って話。UNLHA32.DLLの開発初期っていったら10年以上も前なんだから、勝手に後者に限定して話をされても困るんだがな。
Re: (スコア:0)
そもそも今回の騒動が未知の脆弱性によるものだったのであれば#1776397 [srad.jp]の指摘にも価値があると思いますが、今回の騒動は既知の脆弱性に対する認識不足で対処が徹底していなかったのが原因なのですから#1776397 [srad.jp]は完全に筋違いだ、としか評しようがないような。
勝手に後者に限定しているのではなく
Re: (スコア:0)
DLL不要のアーカイバがシェアを伸ばす
↓
そのアーカイバが不正な圧縮ファイルを作成するバグを出す
↓
苦情がなぜかMiccoさんのところに殺到する
↓
Miccoさん大激怒
↓
アーカイバサイト閉鎖、のちにこっそりと復活
という事もありましたね。