アカウント名:
パスワード:
わざわざ Win32s に対応したとのこと、本当ご苦労様でございました・・・。
正直なところ「任意のDLL読み込み」ってやつが何故、脆弱性になるのかさっぱり理解できない。Windowsがそういう仕様なんだから、そういうもんだって話で終わりでしょ。
非システム管理外領域であろうと、悪意あるDLLをディスク保存された時点ですでに感染完了でアウト。kernel32.dll の偽DLLを実行DIR内に置くことで乗っ取りできるなら、それを阻止しても次は unlha なり何なりのアーカイバのDLL本体を直接置き換えられるだけでしょう。
たとえは変だけど、家の
非システム管理外領域であろうと、悪意ある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 が読み込まれてしまうことが問題なのです。
と現実的な危険があり、既に悪用されて被害が続出しています。
>どっかのサイトから同人画像とかエロ画像を 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という名前の悪
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を読み込んでくる問題を見落としがちという問題がありますが、どうしようもありません。
>Known DLLsのDLLがそうでないDLLを読み込むことえー?なんで?ふつうにwindows apiを使ってたらkernelやuserやgdiの関数を呼んでるもんだと思ってたら、全然違う場所から呼んでるってこと?
Known DLLsから呼ばれる可能性のある「そうでないDLL」の一覧とかどっかにあるのか?
>それこそVisual C++の遅延読み込みを使えば良いと思います。ソースコードの変更は不要なるほど。↓これですか。 https://msdn.micro [microsoft.com]
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に分ける処理、自己解凍書庫でこれを実装するのは一層大変そうですが。
ありがとうございます。しかし、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)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
開発者さん乙 (スコア:0)
わざわざ Win32s に対応したとのこと、本当ご苦労様でございました・・・。
正直なところ「任意のDLL読み込み」ってやつが何故、脆弱性になるのか
さっぱり理解できない。
Windowsがそういう仕様なんだから、そういうもんだって話で終わりでしょ。
非システム管理外領域であろうと、悪意あるDLLをディスク保存された時点で
すでに感染完了でアウト。
kernel32.dll の偽DLLを実行DIR内に置くことで乗っ取りできるなら、それを阻止しても
次は unlha なり何なりのアーカイバのDLL本体を直接置き換えられるだけでしょう。
たとえは変だけど、家の
多くの環境の "%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)
ありがとうございます。
しかし、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では動かないとかそのへんもある。