• LHMelt における任意の DLL 読み込みに関する脆弱性
• LMLzh32.DLL における任意の DLL 読み込みに関する脆弱性
• LHMelt における安全でないライブラリーのロードによりリモートでコードが実行される脆弱性
• LZH 書庫のヘッダー処理における脆弱性について (2010 年版)
• LHMelt におけるヒープオーバーフローの脆弱性
• LMLzh32.DLL におけるヒープオーバーフローの脆弱性
• gzip における脆弱性の影響について
• 『指定外の場所へファイルが展開されてしまう脆弱性』の問題について
• ソフト脆弱性情報

　現行の UNRAR32.DLL は「Windows アプリケーションにおける DLL 読み込みに関する脆弱性」に対応していません。 そのため， LHMelt が行っている当該脆弱性への対策が影響し， システムディレクトリー以外に UNRAR.DLL がインストールされていると， UNRAR32.DLL が UNRAR.DLL のロードに失敗してしまいます。

UNRAR.DLL のロードに失敗した場合 UNRAR32.DLL がバージョン情報として 0.00 を返すことから， 上述のエラーが表示されます。 UNRAR32.DLL 及び UNRAR.DLL については， システムディレクトリーへインストールするようにしてください。

　64 ビット版 Windows 10 Pro April 2018 Update (1803) においては， 64 ビット版ソフトにシステムから返される情報が「Pro」なのに対して， 32 ビット版ソフトへは何故か「Enterprise」を返します。 仕様なのかバグなのか判らないことから， LHMelt 側での読み替えなどは行っていません。

　jpeg 形式の画像など， 一部のファイルは「それ自体すでに圧縮されている」ファイルです。 LHMelt (というか， 各 DLL。) がファイルを圧縮する機能をもっていたとしても， すでに圧縮されているものを， それ以上圧縮することはできません。

　LZH 書庫を扱うツールの中には， 一部不正なヘッダーを作成してしまうものがあります。

　これまでの UNLHA32.DLL では， 致命的なものでない限りは， そのような書庫についても扱うようになっていましたが， そのような書庫を扱えない対応アプリが存在し， 結果として書庫やファイルを失ってしまう…という事故が意外と多く発生していました。 このため， 最近の UNLHA32.DLL については， 安全性を考慮して， そのような書庫については扱わないようになっています。

　特に多いのが「必要なエンドマークが存在しない」書庫で， 結果として， これによるエラーを比較的多く目にすることになってしまっています。

　これらは， 「破損ヘッダー」と見なせるものなので， "-jc" スイッチを使用することで， 処理を継続させることができます。 「エンドマークが存在しない」のエラーの場合は， 実際にはすべての格納ファイルの処理が終了しているので， メッセージ等が表示される以外の (展開できないファイルが発生する等の) 被害を伴いません。 拙作の LHMelt では「破損ヘッダーを読み飛ばす」を有効にすることで， この不具合を回避することが可能です。

　UNLHA32.DLL が通常作成する書庫では， タイムスタンプは， すべて協定世界時 (UTC) で扱われます。 Win3.1 や MS-DOS 用のプログラムでは， 環境変数の設定に基づいて UTC→地方時間 (例えば日本標準時間。) への変換が行われるようになっており， たとえ WinXP 等の環境であっても， コマンドプロンプト画面 (DOS 窓) 等で実行する場合には， この環境変数が設定されていないとタイムスタンプがずれてしまいます。

　日本国内で使用する場合には， 次の環境変数を設定してください。

　LHMelt は， 通常 ZIP 書庫の圧縮等の際には ZIP32J.DLL を使用します。 ZIP32J.DLL は内部で Info-ZIP の DLL 版である ZIP32.DLL を呼び出しますが， この ZIP32.DLL にはバグが存在していて， 日本語等マルチバイト文字が混在する名前のファイルを正常に扱えません。 通常は問題なく扱われるのですが， "Test[ア].TXT" といった ZIP32.DLL の正規表現指定に使われる文字 (この場合は '[' が該当し， 多くのソフトでは "Test[[]ア].TXT" のように正規表現を使った指定となる。) が含まれたファイルを指定すると， 本来合致しないはずの "Test[ω].TXT" まで格納されてしまいます。 同様に "ア*.TXT" のようなワイルドカード (正規表現) 指定を行った場合， "アマゾン.TXT" と一緒に "Ολυμποσ.TXT" (欧文フォントで表示されていますが， 全角のギリシア文字です。 Unicode なら "Όλυμπος" とするところです。) までもが格納されてしまいます。

　ソースを確認していないので推測ですが， このバグは「ある文字の 1 文字前」を参照する必要があった場合に， 当該文字がマルチバイト文字かどうかを確認せずにシングルバイトで照合を行ってしまっているためだと思われます。 (CharPrev() API を使用している等， 当該文字への移動は正常に行われている。) 　上記の例では "ア" (0x8341)， "Ο" (0x83AD)， "ω" (0x83D6) が全て 0x83 で始まっているため同一と見なされてしまっているわけで， "ァ" (0x8340) から "ω" (0x83D6) までの 130 字超が同じ文字として扱われてしまう結果となります。
　ちなみに， 「ある文字の 1 文字後」といった通常の方向の場合には大丈夫なので， 「*ン.TXT」といったような指定を行った場合は， 期待どおり "アマゾン.TXT" のみが格納されます。

　このバグは Ver 2.3x に共通していることから， ZIP32.DLL を使用する場合， '[' のような文字を使用しないようにする必要があります。 使用する場合は 7-ZIP32.DLL を使用して ZIP 書庫を扱う必要が出てきます。
　なお， このバグは Ver 2.2 には存在しませんので， LHMelt では (7-ZIP32.DLL が使えない場合等を考慮して) 要求版を 2.2 まで引き下げてありますが， 9 年近く前の版であることから， Ver 2.2 の使用は， お勧めしません。

　SCFunc.dll は StarSoftcomm の StarCenter に含まれるモジュールです。 当該ソフトがどういったソフト (システム) なのかは不明ですが， Web で得られる情報によると常駐した上で他のプロセスを監視しているようです。

当該ソフトが「安全でないライブラリのロードにより、リモートでコードが実行される (マイクロソフト セキュリティ アドバイザリ 2269637)」の肝に当たる「カレントディレクトリーからの DLL ロード」に依存しているため， それを禁止している Ver 1.65a 以降の LHMelt への接触が上手く行えなくなっているのが原因です。 他のプロセスに接触しようとするソフト側の不具合ですので， LHMelt に限らず同様の問題が発生しますが， Adobe Air のインストーラー方面で発生する頻度が高いようです。

　言わずもがなですが， StarCenter に限らず， 「○○が見つからなかったため～」が表示された場合は， その当該 DLL を使用しているソフトに上述の脆弱性が存在することになります。 特に今回のような他のプロセスを監視する類では影響が甚大 (ソフトの性格からしてシステム・管理者権限を容易に取得できる環境で動作しているでしょうから， 真の意味で「何でもあり。」) ですので， 可能であれば， 当該ソフトの更新や乗り換えを検討したほうが良いかもしれません。