アカウント名:
パスワード:
わざわざ Win32s に対応したとのこと、本当ご苦労様でございました・・・。
正直なところ「任意のDLL読み込み」ってやつが何故、脆弱性になるのかさっぱり理解できない。Windowsがそういう仕様なんだから、そういうもんだって話で終わりでしょ。
非システム管理外領域であろうと、悪意あるDLLをディスク保存された時点ですでに感染完了でアウト。kernel32.dll の偽DLLを実行DIR内に置くことで乗っ取りできるなら、それを阻止しても次は unlha なり何なりのアーカイバのDLL本体を直接置き換えられるだけでしょう。
たとえは変だけど、家の
非システム管理外領域であろうと、悪意あるDLLをディスク保存された時点ですでに感染完了でアウト。
今時のブラウザの多くは、デフォルト設定で、Webサイトにアクセスしただけでユーザーの操作無しに任意のファイルをディスク上の "%USERPROFILE%\Downloads" に自動保存可能になっています（任意の DLL 読み込み問題による被害が多発したため、DLL は危険なファイルと判断してブロックするブラウザもありますが）。
ディスクには悪意のあるファイルが保存されているのが前提条件であり、安全なファイルかどうかは ZoneID で識別して（つまりインターネットからダウンロードしたファイルは危険なファイルであるというフラグが付く）、
で、どうすりゃいいのよ。これが本当に脆弱性として取り扱われるべきならば、ことは自己解凍ファイルだけではなく「downloadフォルダで実行される可能性がある実行ファイル」全てに該当すると思うのだが。（つまりほとんどのEXE形式インストーラーと「インストール場所を選ばないアプリ」） http://micco.mars.jp/vul/2017/mhsvi20170515_01.htm [micco.mars.jp] の技術情報みても読み取れない。
>・KERNEL32.DLLの遅延ロードを行うことは出来ないつーことはdownloadフォルダにKERNEL32.DLLという名前の悪
kernel32.dllそのものは、Known DLLsに登録されているので大丈夫です（user32.dllやgdi32.dllもです）。システム以外のディレクトリから同名のDLLが読み込まれることはありません。問題は、そこに書かれているように、Known DLLsのDLLがそうでないDLLを読み込むことなのです。
使うAPIの全てを遅延ロードってとんでもなく面倒くさい。
それこそVisual C++の遅延読み込みを使えば良いと思います。ソースコードの変更は不要なので、そこまで面倒ではないでしょう。そして、次のいずれかを実施すれば良いだろうかと思います（どなたか間違っていたら教えてください）。
>Known DLLsのDLLがそうでないDLLを読み込むことえー？なんで？ふつうにwindows apiを使ってたらkernelやuserやgdiの関数を呼んでるもんだと思ってたら、全然違う場所から呼んでるってこと？
Known DLLsから呼ばれる可能性のある「そうでないDLL」の一覧とかどっかにあるのか？
>それこそVisual C++の遅延読み込みを使えば良いと思います。ソースコードの変更は不要なるほど。↓これですか。https://msdn.microsoft.com/ja-jp/library/151kt790.aspx [microsoft.com]
＃普段遣いのコンパイラはBorlandなのだが……＃一応VC++もコンパイル確認だけはしているが。＃あとmingw-JPとかlcc-win32とかWatcom C/C++とか…。
UNLHA32.DLLの例のページの記述によれば、kernel32.dllは別のDLL（本当はSystem32に存在する想定）に対するインポートを有しているということだと考えています。
そうなると起動用EXEと主たる処理のDLLに分割するのが比較的簡単ではないでしょうか。DLLでは、通常通りインポートできます。EXEのほうで対処してそのDLLを読み込む（SetDefaultDllDirectoriesまたはLoadLibraryExでLOAD_LIBRARY_SEARCH_SYSTEM32を指定するなど）という方法が可能です。このDLLに分ける処理、自己解凍書庫でこれを実装するのは一層大変そうですが。
ありがとうございます。しかし、Miccoさん、もうすこし詳しく（アマチュア向けプログラミング情報みたいな形で）今回の対策を説明してくれないかなあ…。
JVNから追加情報。http://jvn.jp/ta/JVNTA91240916/ [jvn.jp]
ありとあらゆる有名アプリに対応を迫っているのか？http://forest.watch.impress.co.jp/docs/news/1062977.html [impress.co.jp]
＃Visual C++を普段遣いとしては使いたくない理由の一つに、それこそ公開用バイナリをそれで作ったらWin32sでは動かないとかそのへんもある。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
開発者さん乙 (スコア:0)
わざわざ Win32s に対応したとのこと、本当ご苦労様でございました・・・。
正直なところ「任意のDLL読み込み」ってやつが何故、脆弱性になるのか
さっぱり理解できない。
Windowsがそういう仕様なんだから、そういうもんだって話で終わりでしょ。
非システム管理外領域であろうと、悪意あるDLLをディスク保存された時点で
すでに感染完了でアウト。
kernel32.dll の偽DLLを実行DIR内に置くことで乗っ取りできるなら、それを阻止しても
次は unlha なり何なりのアーカイバのDLL本体を直接置き換えられるだけでしょう。
たとえは変だけど、家の
多くの環境の "%USERPROFILE%\Downloads" が魔窟・ゴミ屋敷な現状を理解すべき (スコア:3)
今時のブラウザの多くは、デフォルト設定で、Webサイトにアクセスしただけでユーザーの操作無しに任意のファイルをディスク上の "%USERPROFILE%\Downloads" に自動保存可能になっています（任意の DLL 読み込み問題による被害が多発したため、DLL は危険なファイルと判断してブロックするブラウザもありますが）。
ディスクには悪意のあるファイルが保存されているのが前提条件であり、安全なファイルかどうかは ZoneID で識別して（つまりインターネットからダウンロードしたファイルは危険なファイルであるというフラグが付く）、
どうすりゃいいのよ (スコア: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++の遅延読み込みを使えば良いと思います。ソースコードの変更は不要なので、そこまで面倒ではないでしょう。そして、次のいずれかを実施すれば良いだろうかと思います（どなたか間違っていたら教えてください）。
Re:どうすりゃいいのよ (スコア:0)
>Known DLLsのDLLがそうでないDLLを読み込むこと
えー？なんで？
ふつうにwindows apiを使ってたらkernelやuserやgdiの関数を呼んでるもんだと思ってたら、全然違う場所から呼んでるってこと？
Known DLLsから呼ばれる可能性のある「そうでないDLL」の一覧とかどっかにあるのか？
>それこそVisual C++の遅延読み込みを使えば良いと思います。ソースコードの変更は不要
なるほど。↓これですか。
https://msdn.microsoft.com/ja-jp/library/151kt790.aspx [microsoft.com]
＃普段遣いのコンパイラはBorlandなのだが……
＃一応VC++もコンパイル確認だけはしているが。
＃あとmingw-JPとかlcc-win32とかWatcom C/C++とか…。
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)
ありがとうございます。
しかし、Miccoさん、もうすこし詳しく（アマチュア向けプログラミング情報みたいな形で）今回の対策を説明してくれないかなあ…。
Re: (スコア:0)
JVNから追加情報。
http://jvn.jp/ta/JVNTA91240916/ [jvn.jp]
Re: (スコア:0)
ありとあらゆる有名アプリに対応を迫っているのか？
http://forest.watch.impress.co.jp/docs/news/1062977.html [impress.co.jp]
Re: (スコア:0)
＃Visual C++を普段遣いとしては使いたくない理由の一つに、それこそ公開用バイナリをそれで作ったらWin32sでは動かないとかそのへんもある。