パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

UNLHA32.DLLの開発停止、作者がLHA書庫の使用中止を呼びかける」記事へのコメント

  • 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書庫の使用中止を呼びかけているのが現状ということですね。

        • by Anonymous Coward

           DOSの時代ならいざ知らず、Win32以降は事実上Miccoさんと統合アーカイバプロジェクト [madobe.net]がLZH書庫の規格を管理してきたようなものなのに、両者を事実上無視したソフトや孫引き、曾孫引き、玄孫引きのソフトが多くなって、互換性の維持すら困難な状況になっていますので、そんな青臭い理想を現実化しただけでどうにかなるような現状ではないですよ。

           実際問題、三年半近く前に見つけたこの脆弱性に対し、今までにどれだけの(半端なものを含めて)互換ソフトがどれだけ対応したかを考えれば解るかと。

          • by Anonymous Coward

            互換性維持云々にかんして言えばUNLHA32.DLLがソース公開してないのも原因のひとつじゃないか、という気がしなくもないですが。ソース公開してたんなら脆弱性対策版出したからこっち使えで、3年半もあればかなり対策すすんだんじゃないかと思います。

            身から出た錆なので問題が対処困難である理由を互換性維持云々にもとめるのはどうかと思う、という話で、いまさらUNLHA32.DLLのソース公開しろという気はありません。

            • by Anonymous Coward

              本家を無視した孫引き、曾孫引き、玄孫引きのソフトに関しては、本家がソースを公開していてもそこへ辿ってきて読むとは思えないですが…。
              それともソースさえあればコピペするためにやって来るものなのでしょうか?

              • by Anonymous Coward

                本家=オリジナルのLHAのソースを使いまわしていると思われる、ヘッダが4KB以上だと期待通りに処理できないソフト(アンチウィルスソフトも含む)に関しては、UNLHA32.DLLの初期段階からソース公開しておけばある程度は効果があったと思いますが。

                ぶっちゃけ本家の脆弱性まで律儀に受け継いでいるから困っているわけで、今回の脆弱性に関して言えば本家を無視してくれないと困るというか。

              • by Anonymous Coward
                パブリックドメインのソースが起源の脆弱性 [srad.jp]が15年以上経ってから指摘されたりするんだぜ?
              • by Anonymous Coward

                現行版と連続性のある脆弱性対策済み版のソースが公開された方が脆弱性対策されやすいよねという話が、なんで脆弱性が長期間指摘されなかったという話に摩り替わってるんだろう。

              • by Anonymous Coward on 2010年06月08日 12時26分 (#1776534)
                「初期段階」ってのはUNLHA32.DLLの開発初期の話だろ。
                • 開発初期からソース公開されていれば、この手の脆弱性は早期に解消されていたはず。
                • 開発初期からソースが公開され続けていれば、脆弱性の対処前後のソースを比較することにより、他の実装でも対処が容易になる。

                #1776397はgzipの事例から前者は必ずしも真ではなない、って話。UNLHA32.DLLの開発初期っていったら10年以上も前なんだから、勝手に後者に限定して話をされても困るんだがな。

                親コメント
              • by Anonymous Coward

                そもそも今回の騒動が未知の脆弱性によるものだったのであれば#1776397 [srad.jp]の指摘にも価値があると思いますが、今回の騒動は既知の脆弱性に対する認識不足で対処が徹底していなかったのが原因なのですから#1776397 [srad.jp]は完全に筋違いだ、としか評しようがないような。

                勝手に後者に限定しているのではなく

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」

処理中...