パスワードを忘れた? アカウント作成
13283612 story
ソフトウェア

「UNLHA32.DLL」が7年ぶりにアップデート 59

ストーリー by hylom
知らない人は知らないが知っている人は知っているLHA 部門より
あるAnonymous Coward 曰く、

LHA形式アーカイブの圧縮・展開機能を提供するライブラリ「UNLHA32.DLL」が約7年ぶりにアップデートされた。5月15日にリリースされたバージョン3.00では任意のDLL読み込みに関する脆弱性と、「UNLHA32.DLL」で作成された自己解凍書庫における任意のDLL読み込みに関する脆弱性が修正されている(窓の杜作者のMicco氏Webサイト)。

UNLHA32.DLLについては、2010年に開発停止が宣言されLHA書庫の使用中止が呼びかけられていた(過去記事)。

脆弱性の詳細情報ページによると、この問題は約7年前に判明していたものの、修正によってWin32s環境で動作しなくなる可能性がある点や、この問題の発端がWindowsの仕様の問題にあることからスルーしていたという。

  • by Anonymous Coward on 2017年05月17日 15時05分 (#3212246)

    前の開発停止以降も使い続けようとしてた連中はこのまま使い続けるのであった

    ここに返信
    • by Anonymous Coward

      一応過去に作ったファイルを解凍できればよいのであれば7以降のウィンドウズの場合なんの問題もないな。
      何故か7でlhaの内容閲覧機能と伸長機能がウィンドウズに搭載されましたからね。

      • by Anonymous Coward on 2017年05月17日 21時53分 (#3212514)

        Creators Updateで圧縮(LZH形式)フォルダーは廃止されちゃったから問題あるよ。

        # だからWindows 10関係で何かドヤりたかったら常に最新の情報を追いかけておけとあれほど

        • by Anonymous Coward

          マイクロソフトの事なので一年くらいたったら復活するだろう。

      • by Anonymous Coward

        いちおうVista時代からUltimate Editionの追加機能に含まれてましたよ。

        • by Anonymous Coward

          それを言うならXPの時代からあった気が…
          マイクロソフトの公式サイトからエクスプローラ拡張をダウンロードという形だったが、エディションにかかわらず使えた。

    • by Anonymous Coward

      おいとっくにサポートを終了したOSに対してWannaCryのパッチを出した会社の悪口はやめろ

  • by Anonymous Coward on 2017年05月17日 15時36分 (#3212274)

    LHAやZIPみたいに、個別に圧縮してからまとめるアーカイブ形式は、tar+gzipみたいにまとめてから圧縮する形式に比べ、たとえ圧縮アルゴリズムが同じでもどうしても圧縮率が落ちるので、jarみたいに圧縮したまま個別のコンテンツを取り出すことが必要な用途以外には、捨てちゃってもいいんじゃないかと思う。

    ここに返信
    • 自己解凍書庫ってなくてもいいんじゃ?

      • by Anonymous Coward

        なくてもいいどころか害悪でしかないのでマジで滅んでほしい。秘文とかいうランサムウェアとか。

    • by Anonymous Coward

      何で?

      • by Anonymous Coward

        情報理論の初歩を勉強しろ。

    • by Anonymous Coward

      ファイルが一部壊れたときに、まとめてから圧縮だと全体が駄目になるけど個別圧縮だと影響は最小限で済むよね。
      用途によって使い分けるべきだと思うのだけど。

      • by Anonymous Coward
        >全体が駄目になる
        なりません。tar+gzipでダメになるのはGNU tarのバグです。
        何で誰も直さないんだろね
        • by Anonymous Coward

          何で誰も直さないんだろね

          「おかしい、OSS界隈には優秀なプログラマも多数居るのに」
          「なんで修正が行われないんだ」
          「何かあったに違いない」
          「なんで修正来ないの!!!」

          って火事を見ながら野次馬が騒いでるコラができそうなやつだ。
          みんな「誰かが直すに違いない」って思ってるだけで自分ではやらないやつ。

          # あるいは「自分で修正したソースコードを運用してる人は多数居るが、誰もコミットしてない」とか

        • by Anonymous Coward
          なんで「なりません」とか言えるんだか。
          GNU tar のバグだろうがなんだろうが、一括でまとめてから圧縮する手法には全損のリスクがありますよ。
          • by Anonymous Coward

            > 一括でまとめてから圧縮する手法には全損のリスクがあります
            それはどっちでも一緒なのでは?

            個別圧縮でもヘッダとか重要な箇所がダメになると
            全損のリスクは常にあるんじゃなかろうか。

            • by Anonymous Coward

              RARなんかは一部修復できる場合もあるので救済率は異なる

            • by Anonymous Coward

              正直圧縮ファイルのフォーマットをそこまで強固にする必要があるのだろうか…
              圧縮ソフトにはファイルが正常に圧縮できたかどうかを圧縮終了時に通知する機能があればいいと思う。解凍ソフトにはファイルの解凍が正常に終わったかどうか表示する機能があればいいと思う。そのために必要な情報も圧縮ファイルに埋め込むとして。
              それと一括でまとめてから圧縮する形式でも圧縮したまま個別のコンテンツを取り出すことはできる。ただ個別に圧縮してから一個にまとめる形式よりも解凍に時間がかかるのでjarのように短時間でファイルを解凍する必要がある用途には向かないというだけ。
              別にどうでも良いがjarは無圧縮でアーカイブするだけのほうがパフォーマンスが出るんだよね。

            • by Anonymous Coward

              全損の定義次第かなぁ。
              例えばzipのセントラルディレクトリ壊せばそれに依存したソフトでは書庫全部が解凍できなくなるだろうけど、それで全損と言っていいかというと……

      • by Anonymous Coward

        用途によって使い分けるべきなのに、個別圧縮の方が不利な場合でも何も考えずにzipを使ってるのがおかしい、と言ってるだけ。

        • by Anonymous Coward

          そもそもzipを使う理由としてはファイルを一個にまとめるためというのが大きいので圧縮率とかはどうでもいい。

    • by Anonymous Coward

      ファイルを順番に舐めてくような用途なら先読み含めぜんぜん有用でしょ
      あと必要なら lha(無圧縮)+lha(圧縮)で同じことできるよね

    • by Anonymous Coward

      >jarみたいに圧縮したまま個別のコンテンツを取り出すことが必要な用途以外には、捨てちゃってもいいんじゃないかと思う。
      なんだ、必要じゃん。

    • by Anonymous Coward

      複数の画像データを1ファイルに纏めて高速切り替えする時に必要

    • by Anonymous Coward

      中のファイルを個別に取り出したくなる可能性がない用途ってどんなのだ?
      ファイルの受け渡しでもバックアップでも、中のファイルをいくつか確認したいだけなのにアーカイブ全体が展開されるのを何十秒も待たされるような圧縮の仕方をする奴がいたら生かしておけないだろ

      • by Anonymous Coward

        アプリケーションのインストーラを作るときだろう。一個でも欠けると動かなくなるからな。
        配布側としては少しでも容量を小さくしたいしインストールする側は何が入っているのかをいちいち確認しない人が多い。

        • by Anonymous Coward

          アプリケーションのインストーラこそ特殊な用途だけどね。

          アーカイブはどちらかと言うと個別に参照したいことの方が多い。
          自炊の書籍なんかだと圧縮する必要すら無いわな。

  • by Anonymous Coward on 2017年05月17日 16時40分 (#3212323)

    >修正によってWin32s環境で動作しなくなる可能性

    Windowsのバイナリ互換性文化はほんとにすごいなあ。

    ここに返信
    • by Anonymous Coward

      Win32sの背景から言えば、七年前(2010年?)でそこに固執する方がおかしいけどね。
      元々Win3.1向けだから。
      16ビットに居続けるならまだ分かる。

      • 作者の「ホームページ」Micco's HomePage [micco.mars.jp] も、IE4 などの20年前の化石ブラウザとの前方互換性が今も保たれています。

        Welcome to Micco's page!!
        Sorry, but this web page is written in Japanese.

        IE 4.0 / Netscape 4.7 / Mozilla 1.5 (TLD 10 付属) 対策で,一部の
        タグでは直接 style 属性を指定。CSS での指定も,そのまま残してある。
        要は, その style 属性がないと IE 4.0 / Netscape 4.7 / Mozilla 5.0
        では不具合が出るということ。(^^;)

        IE4 対策で div の入れ子になっている

        /* padding: 0px; */
        /* ↑を指定すると Netscape 7.1 でリストマーカーが消えてしまう */

      • 懐かしいな、Win32s。
        Win32s環境って今どれぐらい生き延びているんだろう…

        • by Anonymous Coward

          普段遣いではありませんが、テスト環境として維持してます。
          Windows3.1のデバッグカーネルが使えるので、APIのパラメータ間違いとか資源の解放忘れとか把握できて便利。
          #95以降のデバッグ環境は持ってない。出たかどうかも知らない。

          • by Anonymous Coward
            95 以降でも NT 系(10でも)でも同様にデバッグカーネル使えますよ。
            規模が全然違うので、総合的にどっちが楽かって言われると困りますけど、リモートデバッグの環境が3.1の時代より格段に良くなってるので、快適ではあります。
            • by Anonymous Coward

              でも、お高いんでしょ?
              #値段調べてないけど。
              #3.1SDKはマニュアルレスのやつがかなり安かった記憶がある。

    • by Anonymous Coward
      Windows 7 とか Vista あたりでは、国内でも ZIP が普通で、LHA は古参の人しか知らない状態なので、むしろ新しい環境で動く必要はない。
      LHA が生きてるのは Win32s あたりとの互換性が必要な世界ですから
  • by Anonymous Coward on 2017年05月17日 17時03分 (#3212343)

    わざわざ Win32s に対応したとのこと、本当ご苦労様でございました・・・。

    正直なところ「任意のDLL読み込み」ってやつが何故、脆弱性になるのか
    さっぱり理解できない。
    Windowsがそういう仕様なんだから、そういうもんだって話で終わりでしょ。

    非システム管理外領域であろうと、悪意あるDLLをディスク保存された時点で
    すでに感染完了でアウト。
    kernel32.dll の偽DLLを実行DIR内に置くことで乗っ取りできるなら、それを阻止しても
    次は unlha なり何なりのアーカイバのDLL本体を直接置き換えられるだけでしょう。

    たとえは変だけど、家のなかに侵入されて放火が怖いから枕を難燃性に変えました。
    その費用が100万円です・・・って言ってるようなもの。
    変えるなら家のなかにあるもの全部変えないといけないし(何億もかかるだろうけど)
    まず侵入を防がないことには、どんな対策しようと
    室内放火以外の別の被害を生むだけだよって話じゃん。

    わけわかんないクレーム付けて貴重なフリーソフト作者のリソースを
    無駄に消費させてるだけにしか見えんよ・・・

    ここに返信
    • 非システム管理外領域であろうと、悪意あるDLLをディスク保存された時点ですでに感染完了でアウト。

      今時のブラウザの多くは、デフォルト設定で、Webサイトにアクセスしただけでユーザーの操作無しに任意のファイルをディスク上の "%USERPROFILE%\Downloads" に自動保存可能になっています(任意の DLL 読み込み問題による被害が多発したため、DLL は危険なファイルと判断してブロックするブラウザもありますが)。

      ディスクには悪意のあるファイルが保存されているのが前提条件であり、安全なファイルかどうかは ZoneID で識別して(つまりインターネットからダウンロードしたファイルは危険なファイルであるというフラグが付く)、実行前に警告・確認などを表示するというのが今の考え方です。

      例えば、Google Chrome の最新版で Firefox のダウンロードページ [mozilla.org] にアクセスしただけで、ゼロクリックで "%USERPROFILE%\Downloads" に "Firefox Setup Stub 53.0.2.exe" が保存されます。

      # Google Chrome の場合は、「ダウンロード前に各ファイルの保存場所を確認する」にチェックを入れることで自動ダウンロードを無効にできます。

      ディスクには悪意のあるファイルが保存されていることを前提に考える必要があります。

      ついでにいうと、Windows SmartScreen によるチェックが行われるのも ZoneID が付加されている場合のみなので、ZoneID のインターネットから取得したフラグが付いているファイルを展開した際には、展開したファイルにも ZoneID が継承される仕様であるべきです。その意味でも ZoneID 未対応のアーカイバーを使い続けるのは危険です。

      kernel32.dll の偽DLLを実行DIR内に置くことで乗っ取りできるなら、それを阻止しても 次は unlha なり何なりのアーカイバのDLL本体を直接置き換えられるだけでしょう。

      "%USERPROFILE%\Downloads" 内にある自己解凍書庫(exe)を解凍(つまり実行)しただけで、"%USERPROFILE%\Downloads" 内にある dll が読み込まれてしまうことが問題なのです。

      1. どっかのサイトから同人画像とかエロ画像を zip にしたものをダウンロードする。このzipファイルには実は悪意のある dll も仕込まれている。
      2. "%USERPROFILE%\Downloads" に自動的に保存される。
      3. 解凍ソフトで解凍して、画像を楽しむ。
      4. "%USERPROFILE%\Downloads" にお目当ての画像 "hoge1.png" "hoge2.png" と一緒に "hoge.dll" が展開されてしまう。"%USERPROFILE%\Downloads" はゴミ屋敷になっているのが普通なので一般ユーザーはそれに気が付かない。その他、属性情報を格納できるアーカイブ形式では隠しファイルにして見えなくするという方法もあり。
      5. 信頼できるWebサイトから、安全な自己解凍書庫 (exe) を「実行」する。ブラウザはデフォルト設定では "%USERPROFILE%\Downloads" に自動ダウンロードするので、同じディレクトリに悪意のある dll が存在する。
      6. 安全な自己解凍書庫を実行したはずなのに、危険な "hoge.dll" が読み込まれてしまい、任意のコードが実行されてしまう。

      と現実的な危険があり、既に悪用されて被害が続出しています。

      • by Anonymous Coward

        >どっかのサイトから同人画像とかエロ画像を zip にしたものをダウンロードする。このzipファイルには実は悪意のある dll も仕込まれている。
        >"%USERPROFILE%\Downloads" に自動的に保存される。
        >解凍ソフトで解凍して、画像を楽しむ。

        その場合、悪意ある"hoge.dll"のパスは
        %USERPROFILE%\Downloads\hoge.dll
        ではなく
        %USERPROFILE%\Downloads\エロ画像\hoge.dll
        になるんじゃないか?(すくなくともwindows標準のzip解凍機能をデフォルトで使った場合)
        そうすると自己解凍書庫 (exe) の実行では読み込まれないような気がするが。

        にしても
        >今時の

        • その場合、悪意ある"hoge.dll"のパスは
          %USERPROFILE%\Downloads\hoge.dll
          ではなく
          %USERPROFILE%\Downloads\エロ画像\hoge.dll
          になるんじゃないか?(すくなくともwindows標準のzip解凍機能をデフォルトで使った場合)

          「windows標準のzip解凍機能をデフォルトで使った場合」には、そうなりますね。Microsoft の設計は安全に配慮しているようです。

          しかし、世の中にはカレントフォルダに書庫ファイルの中身をそのままぶちまけるアーカイバーが多数存在しています。

          # 皆が Windows 標準のアーカイバーを使っていたら、UNLHA32.DLL も 自己解凍書庫も必要ない。

        • >こっちは知らなかったなあ。つーかexeをそれでダウンロード?そっちのほうがよっぽど脆弱なのでは?なんでそんな機能つけたの?なんで世の中に受け入れられているの?

          だね。んでも、自分の「ダウンロード」には desktop.ini しかないなぁ。

          ダウンロードは別のディレクトリに保存、EXEは新規ディレクトリを作って
          そこにコピーしてから実行、ってのはいつもやってる。

          kernel32.dllとか置き換えて、一部の関数の動作を弄るとかそういう工夫というか
          ハックは脆弱性と言っても、プログラマ的には許容範囲内な気が。それでやられる
          ってのも、ま、やられると痛いけど、自己責任というか。

      • で、どうすりゃいいのよ。
        これが本当に脆弱性として取り扱われるべきならば、ことは自己解凍ファイルだけではなく
        「downloadフォルダで実行される可能性がある実行ファイル」全てに該当すると思うのだが。
        (つまりほとんどのEXE形式インストーラーと「インストール場所を選ばないアプリ」)
        http://micco.mars.jp/vul/2017/mhsvi20170515_01.htm [micco.mars.jp]
        の技術情報みても読み取れない。

        >・KERNEL32.DLLの遅延ロードを行うことは出来ない
        つーことはdownloadフォルダにKERNEL32.DLLという名前の悪

        • by Egtra (38265) on 2017年05月17日 22時32分 (#3212535)

          kernel32.dllそのものは、Known DLLsに登録されているので大丈夫です(user32.dllやgdi32.dllもです)。システム以外のディレクトリから同名のDLLが読み込まれることはありません。問題は、そこに書かれているように、Known DLLsのDLLがそうでないDLLを読み込むことなのです。

          使うAPIの全てを遅延ロードってとんでもなく面倒くさい。

          それこそVisual C++の遅延読み込みを使えば良いと思います。ソースコードの変更は不要なので、そこまで面倒ではないでしょう。そして、次のいずれかを実施すれば良いだろうかと思います(どなたか間違っていたら教えてください)。

          • プロセス起動後すぐにSetDefaultDllDirectriesを呼び出す。
          • 通知フック [microsoft.com]のdliNotePreLoadLibraryを使い、自分でDLLを読み込む(適切な実引数を指定してLoadLiraryExを実行する)
          • Windows 8以降であれば、プロセス起動後すぐにSetProcessMitigationPolicy [microsoft.com]でProcessImageLoadPolicyのPreferSystem32Images [microsoft.com]フラグを指定する。

          ただ、いずれの方法でも、そのURLの記事に書かれているWindows 7でのSSPICLI.DLLやWindows VistaのAPPHELP.DLLの場合まで対処するものではありませんので、その対策が別途必要です。

          その他 SSPICLI.DLLとかBCRYPT.DLLとか聞いたことのないようなDLL名が上がっているが,具体的にどうやったのか。どうやるべきなのか。

          これはProcess Monitorか何かで、実際に読み込まれるDLLを確認していったのではないかと思います。もちろん、各バージョンのWindowsごとに。ただ、そのURLの記事に書かれているIMEやウイルス対策ソフトなどが勝手にDLLを読み込んでくる問題を見落としがちという問題がありますが、どうしようもありません。

          • by Anonymous Coward

            >Known DLLsのDLLがそうでないDLLを読み込むこと
            えー?なんで?
            ふつうにwindows apiを使ってたらkernelやuserやgdiの関数を呼んでるもんだと思ってたら、全然違う場所から呼んでるってこと?

            Known DLLsから呼ばれる可能性のある「そうでないDLL」の一覧とかどっかにあるのか?

            >それこそVisual C++の遅延読み込みを使えば良いと思います。ソースコードの変更は不要
            なるほど。↓これですか。
            https://msdn.micro [microsoft.com]

            • by Egtra (38265) on 2017年05月19日 7時53分 (#3213297)

              >Known DLLsのDLLがそうでないDLLを読み込むこと
              えー?なんで?
              ふつうにwindows apiを使ってたらkernelやuserやgdiの関数を呼んでるもんだと思ってたら、全然違う場所から呼んでるってこと?

              UNLHA32.DLLの例のページの記述によれば、kernel32.dllは別のDLL(本当はSystem32に存在する想定)に対するインポートを有しているということだと考えています。

              #普段遣いのコンパイラはBorlandなのだが……
              #一応VC++もコンパイル確認だけはしているが。
              #あとmingw-JPとかlcc-win32とかWatcom C/C++とか…。

              そうなると起動用EXEと主たる処理のDLLに分割するのが比較的簡単ではないでしょうか。DLLでは、通常通りインポートできます。EXEのほうで対処してそのDLLを読み込む(SetDefaultDllDirectoriesまたはLoadLibraryExでLOAD_LIBRARY_SEARCH_SYSTEM32を指定するなど)という方法が可能です。このDLLに分ける処理、自己解凍書庫でこれを実装するのは一層大変そうですが。

            • by Anonymous Coward

              #Visual C++を普段遣いとしては使いたくない理由の一つに、それこそ公開用バイナリをそれで作ったらWin32sでは動かないとかそのへんもある。

  • 010-09-01時点のメモ

    (Micco氏ではなく)JVNの資料をもとにまとめると

    ・発見者(誰かは不明)が調査を行いCERT-FIに報告したのが ZIP, CAB, GZIP,
        7Z および RARであり、JVNではこれに加えてLZH や ACE など、他の圧縮形式
        でも同じ問題が発生する可能性があるとしているのでJVN#545953ではこの7
        種類に関して触れていると解釈してよいと思う。
        (ただし補足情報は4月ではなく2010/06/24の日付なのであとから補足したもの
        かも知れない)
    ・またアンチウイルス製品の脆弱性であり、圧縮アーカイバ製品や圧縮形式の
        脆弱性ではないと明記してある。

    > JPCERT/CCからの補足情報
    > 本件は、アンチウイルス製品の脆弱性であり、圧縮アーカイバ製品や圧縮形
    > 式の脆弱性ではありません。
    > なお、 CERT-FI のアドバイザリには、発見者が本脆弱性を発見した際に調査
    > を行った圧縮形式として、ZIP, CAB, GZIP, 7Z および RAR が記載されてい
    > ますが、これら 5形式のみならず LZH や ACE など、他の圧縮形式でも同じ
    > 問題が発生する可能性があります。

    [JVN] 複数のアンチウィルス製品に脆弱性
    http://jvn.jp/cert/JVNVU545953/index.html [jvn.jp]

    ここに返信
  • by Anonymous Coward on 2017年05月18日 11時47分 (#3212778)

    展開(lhaの用語では解凍)は 7z があれば問題ない。

    ただ lha32 x *.lzh で展開/解凍したとき lhaはタイムスタンプをみて
    書庫内と存在するファイルの新しいほうを残してくれるのが便利
    (-c で強制上書き)

    zip/7zだとその動作がないのが不便

    unlha32.dllが本家みたいな扱いになってるけど、本来のオリジナルで
    なんとかしてくれないかなあ。

    どうせ zipとlzhはアルゴリズム的には似ているのだし、7zに上記の
    動作がつくのでもいいけど無理そう。

    ここに返信
  • by Anonymous Coward on 2017年05月18日 12時12分 (#3212784)

    W1n.10で動くとは思っていなかった。
    CLWinの方はもうお役御免だろうけど。

    ここに返信
typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...