「UNLHA32.DLL」が7年ぶりにアップデート 60
ストーリー by hylom
知らない人は知らないが知っている人は知っているLHA 部門より
知らない人は知らないが知っている人は知っているLHA 部門より
あるAnonymous Coward 曰く、
LHA形式アーカイブの圧縮・展開機能を提供するライブラリ「UNLHA32.DLL」が約7年ぶりにアップデートされた。5月15日にリリースされたバージョン3.00では任意のDLL読み込みに関する脆弱性と、「UNLHA32.DLL」で作成された自己解凍書庫における任意のDLL読み込みに関する脆弱性が修正されている（窓の杜、作者のMicco氏Webサイト）。
UNLHA32.DLLについては、2010年に開発停止が宣言されLHA書庫の使用中止が呼びかけられていた（過去記事）。
脆弱性の詳細情報ページによると、この問題は約7年前に判明していたものの、修正によってWin32s環境で動作しなくなる可能性がある点や、この問題の発端がWindowsの仕様の問題にあることからスルーしていたという。
また延命しちゃった…… (スコア:0)
前の開発停止以降も使い続けようとしてた連中はこのまま使い続けるのであった
Re: (スコア:0)
一応過去に作ったファイルを解凍できればよいのであれば7以降のウィンドウズの場合なんの問題もないな。
何故か7でlhaの内容閲覧機能と伸長機能がウィンドウズに搭載されましたからね。
Re:また延命しちゃった…… (スコア:1)
Creators Updateで圧縮(LZH形式)フォルダーは廃止されちゃったから問題あるよ。
# だからWindows 10関係で何かドヤりたかったら常に最新の情報を追いかけておけとあれほど
Re: (スコア:0)
マイクロソフトの事なので一年くらいたったら復活するだろう。
Re: (スコア:0)
いちおうVista時代からUltimate Editionの追加機能に含まれてましたよ。
Re: (スコア:0)
それを言うならXPの時代からあった気が…
マイクロソフトの公式サイトからエクスプローラ拡張をダウンロードという形だったが、エディションにかかわらず使えた。
Re: (スコア:0)
おいとっくにサポートを終了したOSに対してWannaCryのパッチを出した会社の悪口はやめろ
なくてもいいんじゃ? (スコア:0)
LHAやZIPみたいに、個別に圧縮してからまとめるアーカイブ形式は、tar+gzipみたいにまとめてから圧縮する形式に比べ、たとえ圧縮アルゴリズムが同じでもどうしても圧縮率が落ちるので、jarみたいに圧縮したまま個別のコンテンツを取り出すことが必要な用途以外には、捨てちゃってもいいんじゃないかと思う。
Re:なくてもいいんじゃ? (スコア:2)
自己解凍書庫ってなくてもいいんじゃ?
Re: (スコア:0)
なくてもいいどころか害悪でしかないのでマジで滅んでほしい。秘文とかいうランサムウェアとか。
Re: (スコア:0)
何で？
Re: (スコア:0)
情報理論の初歩を勉強しろ。
Re: (スコア:0)
ファイルが一部壊れたときに、まとめてから圧縮だと全体が駄目になるけど個別圧縮だと影響は最小限で済むよね。
用途によって使い分けるべきだと思うのだけど。
Re: (スコア:0)
なりません。tar+gzipでダメになるのはGNU tarのバグです。
何で誰も直さないんだろね
Re: (スコア:0)
何で誰も直さないんだろね
「おかしい、ＯＳＳ界隈には優秀なプログラマも多数居るのに」
「なんで修正が行われないんだ」
「何かあったに違いない」
「なんで修正来ないの！！！」
って火事を見ながら野次馬が騒いでるコラができそうなやつだ。
みんな「誰かが直すに違いない」って思ってるだけで自分ではやらないやつ。
# あるいは「自分で修正したソースコードを運用してる人は多数居るが、誰もコミットしてない」とか
Re: (スコア:0)
GNU tar のバグだろうがなんだろうが、一括でまとめてから圧縮する手法には全損のリスクがありますよ。
Re: (スコア:0)
> 一括でまとめてから圧縮する手法には全損のリスクがあります
それはどっちでも一緒なのでは？
個別圧縮でもヘッダとか重要な箇所がダメになると
全損のリスクは常にあるんじゃなかろうか。
Re: (スコア:0)
RARなんかは一部修復できる場合もあるので救済率は異なる
Re: (スコア:0)
正直圧縮ファイルのフォーマットをそこまで強固にする必要があるのだろうか…
圧縮ソフトにはファイルが正常に圧縮できたかどうかを圧縮終了時に通知する機能があればいいと思う。解凍ソフトにはファイルの解凍が正常に終わったかどうか表示する機能があればいいと思う。そのために必要な情報も圧縮ファイルに埋め込むとして。
それと一括でまとめてから圧縮する形式でも圧縮したまま個別のコンテンツを取り出すことはできる。ただ個別に圧縮してから一個にまとめる形式よりも解凍に時間がかかるのでjarのように短時間でファイルを解凍する必要がある用途には向かないというだけ。
別にどうでも良いがjarは無圧縮でアーカイブするだけのほうがパフォーマンスが出るんだよね。
Re: (スコア:0)
全損の定義次第かなぁ。
例えばzipのセントラルディレクトリ壊せばそれに依存したソフトでは書庫全部が解凍できなくなるだろうけど、それで全損と言っていいかというと……
Re: (スコア:0)
用途によって使い分けるべきなのに、個別圧縮の方が不利な場合でも何も考えずにzipを使ってるのがおかしい、と言ってるだけ。
Re: (スコア:0)
そもそもzipを使う理由としてはファイルを一個にまとめるためというのが大きいので圧縮率とかはどうでもいい。
Re: (スコア:0)
ファイルを順番に舐めてくような用途なら先読み含めぜんぜん有用でしょ
あと必要なら lha(無圧縮)+lha(圧縮)で同じことできるよね
Re: (スコア:0)
>jarみたいに圧縮したまま個別のコンテンツを取り出すことが必要な用途以外には、捨てちゃってもいいんじゃないかと思う。
なんだ、必要じゃん。
Re: (スコア:0)
複数の画像データを1ファイルに纏めて高速切り替えする時に必要
Re: (スコア:0)
中のファイルを個別に取り出したくなる可能性がない用途ってどんなのだ？
ファイルの受け渡しでもバックアップでも、中のファイルをいくつか確認したいだけなのにアーカイブ全体が展開されるのを何十秒も待たされるような圧縮の仕方をする奴がいたら生かしておけないだろ
Re: (スコア:0)
アプリケーションのインストーラを作るときだろう。一個でも欠けると動かなくなるからな。
配布側としては少しでも容量を小さくしたいしインストールする側は何が入っているのかをいちいち確認しない人が多い。
Re: (スコア:0)
アプリケーションのインストーラこそ特殊な用途だけどね。
アーカイブはどちらかと言うと個別に参照したいことの方が多い。
自炊の書籍なんかだと圧縮する必要すら無いわな。
ちょっとくすっとした (スコア:0)
>修正によってWin32s環境で動作しなくなる可能性
Windowsのバイナリ互換性文化はほんとにすごいなあ。
Re: (スコア:0)
Win32sの背景から言えば、七年前（2010年？）でそこに固執する方がおかしいけどね。
元々Win3.1向けだから。
16ビットに居続けるならまだ分かる。
互換性を大切にしてこその人生なのです (スコア:2)
作者の「ホームページ」Micco's HomePage [micco.mars.jp] も、IE4 などの20年前の化石ブラウザとの前方互換性が今も保たれています。
Re:ちょっとくすっとした (スコア:1)
懐かしいな、Win32s。
Win32s環境って今どれぐらい生き延びているんだろう…
Re: (スコア:0)
普段遣いではありませんが、テスト環境として維持してます。
Windows3.1のデバッグカーネルが使えるので、APIのパラメータ間違いとか資源の解放忘れとか把握できて便利。
＃95以降のデバッグ環境は持ってない。出たかどうかも知らない。
Re: (スコア:0)
規模が全然違うので、総合的にどっちが楽かって言われると困りますけど、リモートデバッグの環境が3.1の時代より格段に良くなってるので、快適ではあります。
Re: (スコア:0)
でも、お高いんでしょ？
＃値段調べてないけど。
＃3.1SDKはマニュアルレスのやつがかなり安かった記憶がある。
Re: (スコア:0)
LHA が生きてるのは Win32s あたりとの互換性が必要な世界ですから
開発者さん乙 (スコア:0)
わざわざ Win32s に対応したとのこと、本当ご苦労様でございました・・・。
正直なところ「任意のDLL読み込み」ってやつが何故、脆弱性になるのか
さっぱり理解できない。
Windowsがそういう仕様なんだから、そういうもんだって話で終わりでしょ。
非システム管理外領域であろうと、悪意あるDLLをディスク保存された時点で
すでに感染完了でアウト。
kernel32.dll の偽DLLを実行DIR内に置くことで乗っ取りできるなら、それを阻止しても
次は unlha なり何なりのアーカイバのDLL本体を直接置き換えられるだけでしょう。
たとえは変だけど、家のなかに侵入されて放火が怖いから枕を難燃性に変えました。
その費用が100万円です・・・って言ってるようなもの。
変えるなら家のなかにあるもの全部変えないといけないし（何億もかかるだろうけど）
まず侵入を防がないことには、どんな対策しようと
室内放火以外の別の被害を生むだけだよって話じゃん。
わけわかんないクレーム付けて貴重なフリーソフト作者のリソースを
無駄に消費させてるだけにしか見えんよ・・・
多くの環境の "%USERPROFILE%\Downloads" が魔窟・ゴミ屋敷な現状を理解すべき (スコア:3)
今時のブラウザの多くは、デフォルト設定で、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 未対応のアーカイバーを使い続けるのは危険です。
"%USERPROFILE%\Downloads" 内にある自己解凍書庫(exe)を解凍(つまり実行)しただけで、"%USERPROFILE%\Downloads" 内にある dll が読み込まれてしまうことが問題なのです。
と現実的な危険があり、既に悪用されて被害が続出しています。
Re: (スコア:0)
＞どっかのサイトから同人画像とかエロ画像を zip にしたものをダウンロードする。このzipファイルには実は悪意のある dll も仕込まれている。
＞"%USERPROFILE%\Downloads" に自動的に保存される。
＞解凍ソフトで解凍して、画像を楽しむ。
その場合、悪意ある"hoge.dll"のパスは
%USERPROFILE%\Downloads\hoge.dll
ではなく
%USERPROFILE%\Downloads\エロ画像\hoge.dll
になるんじゃないか？（すくなくともwindows標準のzip解凍機能をデフォルトで使った場合）
そうすると自己解凍書庫 (exe) の実行では読み込まれないような気がするが。
にしても
＞今時の
Re:多くの環境の "%USERPROFILE%\Downloads" が魔窟・ゴミ屋敷な現状を理解 (スコア:2)
「windows標準のzip解凍機能をデフォルトで使った場合」には、そうなりますね。Microsoft の設計は安全に配慮しているようです。
しかし、世の中にはカレントフォルダに書庫ファイルの中身をそのままぶちまけるアーカイバーが多数存在しています。
# 皆が Windows 標準のアーカイバーを使っていたら、UNLHA32.DLL も 自己解凍書庫も必要ない。
Re:多くの環境の "%USERPROFILE%\Downloads" が魔窟・ゴミ屋敷な現状を理解 (スコア:1)
>こっちは知らなかったなあ。つーかexeをそれでダウンロード？そっちのほうがよっぽど脆弱なのでは？なんでそんな機能つけたの？なんで世の中に受け入れられているの？
だね。んでも、自分の「ダウンロード」には desktop.ini しかないなぁ。
ダウンロードは別のディレクトリに保存、EXEは新規ディレクトリを作って
そこにコピーしてから実行、ってのはいつもやってる。
kernel32.dllとか置き換えて、一部の関数の動作を弄るとかそういう工夫というか
ハックは脆弱性と言っても、プログラマ的には許容範囲内な気が。それでやられる
ってのも、ま、やられると痛いけど、自己責任というか。
どうすりゃいいのよ (スコア:0)
で、どうすりゃいいのよ。
これが本当に脆弱性として取り扱われるべきならば、ことは自己解凍ファイルだけではなく
「downloadフォルダで実行される可能性がある実行ファイル」全てに該当すると思うのだが。
（つまりほとんどのEXE形式インストーラーと「インストール場所を選ばないアプリ」）
http://micco.mars.jp/vul/2017/mhsvi20170515_01.htm [micco.mars.jp]
の技術情報みても読み取れない。
>・KERNEL32.DLLの遅延ロードを行うことは出来ない
つーことはdownloadフォルダにKERNEL32.DLLという名前の悪
Re:どうすりゃいいのよ (スコア:1)
kernel32.dllそのものは、Known DLLsに登録されているので大丈夫です（user32.dllやgdi32.dllもです）。システム以外のディレクトリから同名のDLLが読み込まれることはありません。問題は、そこに書かれているように、Known DLLsのDLLがそうでないDLLを読み込むことなのです。
使うAPIの全てを遅延ロードってとんでもなく面倒くさい。
それこそVisual C++の遅延読み込みを使えば良いと思います。ソースコードの変更は不要なので、そこまで面倒ではないでしょう。そして、次のいずれかを実施すれば良いだろうかと思います（どなたか間違っていたら教えてください）。
ただ、いずれの方法でも、そのURLの記事に書かれているWindows 7でのSSPICLI.DLLやWindows VistaのAPPHELP.DLLの場合まで対処するものではありませんので、その対策が別途必要です。
その他 SSPICLI.DLLとかBCRYPT.DLLとか聞いたことのないようなDLL名が上がっているが，具体的にどうやったのか。どうやるべきなのか。
これはProcess Monitorか何かで、実際に読み込まれるDLLを確認していったのではないかと思います。もちろん、各バージョンのWindowsごとに。ただ、そのURLの記事に書かれているIMEやウイルス対策ソフトなどが勝手にDLLを読み込んでくる問題を見落としがちという問題がありますが、どうしようもありません。
Re: (スコア:0)
>Known DLLsのDLLがそうでないDLLを読み込むこと
えー？なんで？
ふつうにwindows apiを使ってたらkernelやuserやgdiの関数を呼んでるもんだと思ってたら、全然違う場所から呼んでるってこと？
Known DLLsから呼ばれる可能性のある「そうでないDLL」の一覧とかどっかにあるのか？
>それこそVisual C++の遅延読み込みを使えば良いと思います。ソースコードの変更は不要
なるほど。↓これですか。
https://msdn.micro [microsoft.com]
Re:どうすりゃいいのよ (スコア:1)
>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に分ける処理、自己解凍書庫でこれを実装するのは一層大変そうですが。
Re: (スコア:0)
＃Visual C++を普段遣いとしては使いたくない理由の一つに、それこそ公開用バイナリをそれで作ったらWin32sでは動かないとかそのへんもある。
アンチウイルス製品の脆弱性であり圧縮アーカイバや圧縮形式の脆弱性ではない (スコア:0)
010-09-01時点のメモ
(Micco氏ではなく)JVNの資料をもとにまとめると
・発見者(誰かは不明)が調査を行いCERT-FIに報告したのが ZIP, CAB, GZIP,
7Z および RARであり、JVNではこれに加えてLZH や ACE など、他の圧縮形式
でも同じ問題が発生する可能性があるとしているのでJVN#545953ではこの７
種類に関して触れていると解釈してよいと思う。
(ただし補足情報は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]
lhaはタイムスタンプが重宝 (スコア:0)
展開(lhaの用語では解凍)は 7z があれば問題ない。
ただ lha32 x *.lzh で展開/解凍したとき lhaはタイムスタンプをみて
書庫内と存在するファイルの新しいほうを残してくれるのが便利
(-c で強制上書き)
zip/7zだとその動作がないのが不便
unlha32.dllが本家みたいな扱いになってるけど、本来のオリジナルで
なんとかしてくれないかなあ。
どうせ zipとlzhはアルゴリズム的には似ているのだし、7zに上記の
動作がつくのでもいいけど無理そう。
久々にcaldixを起動させた (スコア:0)
W1n.10で動くとは思っていなかった。
CLWinの方はもうお役御免だろうけど。
Re: (スコア:0)
なんか根拠あるの？
あるなら教えて欲しい。