アカウント名:
パスワード:
仕様上、特定のパスからしかDLLのロードを認めないというわけにはいかないでしょ?OS標準じゃないからOSのバージョンで判定するわけにもいかないし。そもそも「別途DLLが必要」なんてもの自体流行らない(つーかこの仕様そのものがまさに脆弱性の元だし)。今さらDLL作者の呼びかけに反してまでそんなもの使い続けている老害は「必ずシステムディレクトリに置いてください。PATHの通ったところに置いても認識しません」なんて仕様にしたら猛反発するに決まってるし。「別途アーカイバが必要」さえWindows標準のZip/LZH圧縮フォルダの前には風前の灯。
LHMeltにおける安全でないライブラリーのロードによりリモートでコードが実行される脆弱性 [nifty.com]
今回の脆弱性に対応した Ver 1.65a 以降の LHMelt では， カレントディレクトリーからの DLL 等のロードが禁止される
書庫と同じディレクトリに悪意あるDLLが置かれていても問題無い様にLHMeltはカレントディレクトリからのDLLのロードをできないようにしたようです。
簡単な確認方法：適当なテキストファイルを， 例えば "UNLHA32.DLL" の名前で作成し， それを任意の書庫と同じディレクトリー上に置いておく。 その上で， 当該書庫を関連付け等で LHMelt に起動と同時に読み込ませる。 「"unlha32.dll" このDLLはロードできませんでした」といった LHMelt の警告や OS の警告が表示されれば， 当該 DLL のロードについて脆弱性が残っている。
詳細(DLLの読み込みの優先順位など)は技術情報、補足情報あたりを読むと分かるかと
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
統合アーカイバDLL使ってるアプリはどうするの? (スコア:0)
仕様上、特定のパスからしかDLLのロードを認めないというわけにはいかないでしょ?
OS標準じゃないからOSのバージョンで判定するわけにもいかないし。
そもそも「別途DLLが必要」なんてもの自体流行らない(つーかこの仕様そのものがまさに脆弱性の元だし)。今さらDLL作者の呼びかけに反してまでそんなもの使い続けている老害は「必ずシステムディレクトリに置いてください。PATHの通ったところに置いても認識しません」なんて仕様にしたら猛反発するに決まってるし。
「別途アーカイバが必要」さえWindows標準のZip/LZH圧縮フォルダの前には風前の灯。
Re:統合アーカイバDLL使ってるアプリはどうするの? (スコア:2)
LHMeltにおける安全でないライブラリーのロードによりリモートでコードが実行される脆弱性 [nifty.com]
書庫と同じディレクトリに悪意あるDLLが置かれていても問題無い様に
LHMeltはカレントディレクトリからのDLLのロードをできないようにしたようです。
詳細(DLLの読み込みの優先順位など)は
技術情報、補足情報あたりを読むと分かるかと