Windows 7のDLL読み込みに関する脆弱性、対策はWindows 10へのアップグレード 71
ストーリー by hylom
既出ではあるが 部門より
既出ではあるが 部門より
昨年5月、複数のMicrosoft製品でDLL読み込みに関する脆弱性が発見されたが、Microsoftはこれに対し「アプリケーション ディレクトリにおけるDLLの植え付けのカテゴリに該当するDLLの植え付けの問題は、多層防御の問題として扱われ、更新プログラムは将来のバージョンについてのみ検討されます」との見解を出していた（Microsoft TechNet、過去記事）。これを受けてJVNが、Windows 7 における DLL 読み込みに関する脆弱性として脆弱性レポートを公表した。
問題の脆弱性は「細工されたDLLファイルが実行ファイルと同一のディレクトリに置かれていた場合、任意のコードを実行される可能性がある」というもの（窓の杜、Security NEXT）。これに対しMicrosoftはWindows 7においてはこの問題を修正する予定はないとしている。Windows 10ではこの脆弱性を緩和する機能が導入されており、脆弱性レポートでは対策方法として「Windows 10へのアップグレード」が挙げられている。
Win10でも普通にアプリディレクトリからDLL読み込まれるんだが (スコア:1)
アプリがDLL検索パスを設定するコードに入る前にinjectionが成立してしまうのがOSの脆弱性って言ってるのなら、DLL検索パスを適切に設定していないアプリはほとんどアプリとしての脆弱性があるのでは。
それとも今のwindows10はまだ対策されてないってことなの?
Re: (スコア:0)
hylomが大事なところをカットしてしまったがシステムDLLが実行してるLoadLibraryが安全じゃないって話だからちと違うんだよな
アプリ側が実行してるLoadLibraryが全てフルパスならアプリ側は悪くないだろ？
更にWindows 7にはSetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32)を実行してもなおアプリケーションディレクトリから読み込みが試行されるなどという邪悪オブ邪悪なDLLまで存在してる
Re:Win10でも普通にアプリディレクトリからDLL読み込まれるんだが (スコア:1)
理解はちょっと違っていたようですね。
アプリ側が実行してるLoadLibraryが全てフルパスならアプリ側は悪くないのはそうですが、ほとんどのアプリはそんなことしてないはず(というか、普通のアプリは明示的にLoadLibrary使ってないし)。
いずれにしろ、OSのDLLがDLL injectionされるということにより脆弱性を持っているというのなら、DLL検索パスの設定をしないことでOSのDLLに関係なくDLL injectionされるほとんどのアプリは脆弱性を持っているのは変わらないかな。
Re:Win10でも普通にアプリディレクトリからDLL読み込まれるんだが (スコア:1)
実際そうだよ。本気で対策しようとするとこんなことになる
https://micco.mars.jp/vul/2017/mhvi20170718.htm [micco.mars.jp]
誰か教えてください (スコア:1)
＞既出ではあるが 部門より
うん、その通りなので、なんで今さらこの話題の意味がよくわからないです。もしかして、JVNが取り上げだしたから今あえて取り上げているの？
＞「細工されたDLLファイルが実行ファイルと同一のディレクトリに置かれていた場合、任意のコードを実行される可能性がある」
↑当たり前ですよね。例えとしては不適切なんでしょうけど・・・
UNIXの管理者の設定で、カレントディレクトリにパスがある。
そこにはlsというシェルスクリプトが配置されており、中身は、 rm -rf / だったら・・・
だからパスって重要で。LD_LIBRARY_PATHにないライブラリ(dso）は読み込まないとか、そういう文化とか・・・・
あー、 (スコア:0)
敢えて脆弱性を直さず、Windows10に移行をさせる流れは正しい。
Re:あー、 (スコア:1)
実際延長サポートすらきれる段階で直す義理もないしな。
でもローカルディスクに偽装DLL置かれてる状況は既に終わってるんじゃないか。
Re: (スコア:0)
無料でアップデートできるならともかく、そうではないし。
未だ延長サポート期間内であるWindows 7で脆弱性への対応を行わないのはダメだろうと思う。
Re: (スコア:0)
OSの挙動を変えないと原理的に対応できないケースもあるからなぁ。
まだWindows7を使ってる中には互換性の解決途中なユーザーも居るだろうし。
Re: (スコア:0)
まだ7のライセンスで10に出来るんじゃ？
Re: (スコア:0)
直したら直したで、「今まで動いていたアプリが動かなくなった！」と言われるんじゃない。
どちらにしろMSが悪いって言われるんだから、ご苦労な役回りだわ。。
Re: (スコア:0)
大問題が起きて大騒ぎになったらいやが応にもパッチ出さざるを得なくなるんだろうけど、これが大騒ぎになるほどの集団被害を引き起こす可能性は低いからね。
Re: (スコア:0)
10では最初から存在しない問題なのかパッチで直した問題なのか
Re: (スコア:0)
サポート期間を残してそれをやるのは邪悪な怠慢だわ
脆弱性じゃないって何度言わせるのか (スコア:0)
攻撃者がアプリの実行ファイルのあるディレクトリに書き込み権限がある状況で、OSやアプリにできることなんて何もないよ。
攻撃者が/usr/binや/usr/libに書き込み権限がある状況で、システムをexploitされたらLinuxの脆弱性だとでもいうのか。
素人なの？
Re: (スコア:0)
だって三井物産が脆弱性って言うから・・・
https://jvn.jp/jp/JVN69181574/ [jvn.jp]
Re: (スコア:0)
> 素人なの？
MSに難癖をつけるプロフェッショナルです。
Re: (スコア:0)
ブラウザのダウンロードフォルダにダウンロードされた細工されたDLLファイルで問題を起こす例が報告されています。
詳しくは調べてみてください。
Re: (スコア:0)
それって、「作業ディレクトリ」のDLLファイルを優先的にロードしてしまう脆弱性じゃないの？
「実行ファイルと同一のディレクトリ」のDLLファイルをロードする仕様とは似て非なるものだと思うのだが
Re: (スコア:0)
ブラウザのダウンロードフォルダって、基本空にしておくものでしょ？
ダウンロードしたファイルを整理していないのか？
Re:脆弱性じゃないって何度言わせるのか (スコア:1)
一般人はしないぞ
ファイルを削除するという概念がない
ソースは俺の身内全員
Re: (スコア:0)
自分はダウンロード兼作業フォルダになってる。デスクトップは空っぽ。
なので、ダウンロードフォルダは常にたくさんのファイルがある。
不要になったら、ゴミ箱に捨てるか、別のフォルダに残しておくか、だな。
Emailも受信ボックス(Inbox)は常に空にする人？
Re: (スコア:0)
ブラウザのダウンロードフォルダ自体、誤操作以外じゃ使わないなぁ。
デスクトップにダウンロードして、用が済んだら消すなりしかるべきフォルダに移動するなりしてる。
Re: (スコア:0)
今までダウンロードしたものは全部残してるけど
Re: (スコア:0)
そういえば、ストレージセンサーにダウンロードディレクトリを空にされて大騒ぎしたアホがいたなあ。
Re: (スコア:0)
こちらはDLLをダウンロードさせるだけで、どっかのEXEが落ちてきて実行されるのを待つ、って感じ？
かなり限定的なケースな気もするが、みんなダウンロードフォルダをどう運用してるんだろう。
# 自分はMacなので関係ない話。
Re: (スコア:0)
それはブラウザがDLLファイルのダウンロード時には常に保存先指定ダイアログを出してダウンロードフォルダ内が指定されたら警告メッセージを出すようにでもすれば済む話では
Re: (スコア:0)
いや、デフォルトのダウンロードフォルダを選択したら警告って、それはそれでだめなような。
Re: (スコア:0)
アプリケーションやインストーラーがDLLのハッシュ値を調べて改ざんされてないか診断する機構は付いていたほうがいいよね
もしくはアプリケーション自体が改ざんされてないかハッシュ値などで自己診断なりOS側で判断する機能が付いているとさらにいいよね
疾うの昔に仕組みはあるが、Microsoftの怠慢で機能してない。 (スコア:2)
ハッシュ値なんて Windows Update でバイナリが差し替えられたら変わっちゃうんだから確認のしようがない。使い物にならない。
少なくとも Vista の時点で既にコード署名があるんだから、そちらを確認れば済む話。
ところが、Windows はシステムのコアコンポーネントですらコード署名されてないバイナリが山のように放置されいる。
例えば、explorer.exe は Win10 は署名されてるけど、Win7 は署名がないし、cmd.exe は Win10 も 7 も署名がない。
システムコンポーネントの改竄を容易に確認する手段を用意しておきながら、まじめに運用する気がないとか、正直 Microsoft の神経はおかしいとしか言いようがない。
コード署名のないバイナリの実行をすべて禁止せよとは言わないが、Microsoft 公式のバイナリにコード署名がないのはセキュリティに対する怠慢以外の何物でもないだろう。
uxi
Re: (スコア:0)
署名カタログも知らないくせにcmd.exeに署名がないとか言ってる阿保
本当だ。びっくり。 (スコア:2)
ごめんなさい。前言撤回します。私が阿呆でした。
explorer.exe から cmd.exe のプロパティ見てもデジタル署名付いてないし、
sigverif.exe も cmd.exe を検証してくれないけど、
PowerShell から
Get-AuthenticodeSignature パス名
ってやると検証出来るんだね。
でも肝心の署名カタログの場所が分からなかったので、調べる方法知ってたら阿保な私に教えてください。
uxi
Re: (スコア:0)
調べる方法：ググる
賢くなれるチャンス！
びっくり。 (スコア:2)
この文章を読んで、調べて分からなかったから聞いているのが分からないとか相当だなと思う。
#3574472 [srad.jp] は、口は悪いが、要点となる情報をこの上なく簡潔に与えてくれている一方で、
#3574648 [srad.jp] はからは、何一つとして学ぶものがない。
人に賢くなれるチャンスとかボケたこと抜かす前にまず自分が文章の読解力を身に付けるべきだろう。
人に何ら有益な情報を提供出来ないくせに、便乗してマウントを取りたいだけの無能なクズは黙ってろと思うね。
uxi
そうじゃない (スコア:2)
署名カタログ自体は *.cat で検索すれば簡単に見つかるよ。
そこ以外にも WinSxS、System32\DriverStore、servicing\Packages、SoftwareDistribution\Download 以下から大量に見つかる。
問題はフォルダの場所ではなくて、署名カタログと検証対象のファイルの対応を見つける方法。
少なくとも私の検索能力では見つけられなかった。
sigverif.exe で検証されたファイルは、ログを見ればある程度署名カタログを絞り込めるけど、署名ファイルのファイル名が長いと表示桁数をオーバーしてしまうため特定出来ないし、任意のファイルを検証することも出来ないので検証対象になってないファイル(例えば cmd.exe)に対応する署名ファイルは見つけることが出来ない。
PowerShell の Get-AuthenticodeSignature は任意のファイルを検証出来るけど、これも署名ファイルとの対応を表示する方法がない。
Windows 本体に含まれない機能を使ってよければ、
Windows SDK 入れることで
signtool.exe verify /a /v 検証対象のファイル
とすれば検証対象のファイルに対応する署名カタログを見つけることは出来る。
しかし、この逆で署名カタログから検証対象のファイルを見つける方法は見つけられなかった。
署名カタログにはハッシュ値のみ記録されているので、
署名カタログ内のハッシュ値を一覧するコマンドさえあればスクリプトを組めそうだけど、
ハッシュ値を一覧するコマンドも見つけられなかった。
更に、よくわからないのは署名カタログのハッシュ値。
例えば、C:\Windows\System32\cmd.exe は
signtool.exe verify /a /v /hash SHA256 C:\Windows\System32\cmd.exe
とすると
File is signed in catalog: C:\WINDOWS\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Microsoft-Windows-Client-Features-Package0011~31bf3856ad364e35~amd64~~10.0.17134.1.cat
Hash of file (sha256): 9F9B267DA808B959A4CD4D5B8FEAC68C4888B932789D26BECB2D65C452273D4B
という結果が得られる。
これは、上記の署名カタログを開いてセキュリティカタログのタブを確認してみると確かにこのハッシュ値が見つかる。
ところが、
Get-FileHash -Algorithm SHA256 C:\Windows\System32\cmd.exe
の結果は
9A7C58BD98D70631AA1473F7B57B426DB367D72429A5455B433A05EE251F3236
なのでハッシュが一致しない。
ということは恐らく SALT が付いてるはずなんだけど、これに関するドキュメントも見つけられなかった。
少なくとも署名カタログについては、私は自分の無知を詫びて阿呆であることを認めたよね？
口だけならなんとでも言えるけど、無いことの証明はできないだから、是非とも有ることを示して、私の無能を証明してもらいたいのだ。
uxi
Re:びっくり。 (スコア:2)
私は基本的に質問しないんだけど、君らがマウント取ってくるから、ボコってくれって言ってるだけなんだが？
ちゃんとボコってくれたのは、最初の#3574472 [srad.jp]だけで他は情報量ゼロじゃん？
こっちは調べた上で白旗上げてるんだ。そして調べた結果は還元している。
知ったかはお呼びじゃないんだ。
ちゃんと、エビデンスでボコってくれ。
uxi
Re: (スコア:0)
アプリケーションやインストーラーがDLLのハッシュ値を調べて改ざんされてないか診断する機構は付いていたほうがいいよね
改ざんされてないか診断する機構を実装したDLLが改ざんされていないことを以下無限ループ
exeと同じディレクトリにDLL (スコア:0)
昔はDLLのバージョン違いを気にしなくて済む良い方法とされていたのに。
Re:exeと同じディレクトリにDLL (スコア:1)
EXEそれぞれが自分用のDLLを持つって
ナニその本来転倒
Re: (スコア:0)
今だってやってますよ
Microsoft OneDriveっていうソフトなんですけど
Re: (スコア:0)
今このスレには二種類の人がいる。
・なぜこれが脆弱性になるのかわからない人
・脆弱性があるとはこれだからMSはって人
Re: (スコア:0)
macOSみたいにアプリをパッケージ構造にしとけばDLL地獄とこの類の脆弱性を同時に解決出来るんだが、なんでWindowsではそっちの方向に動かなかったんだろう。
Re: (スコア:0)
windows10のストアアプリがそれかと
ストアはろくなソフト無く酷いが
パッケージ形式だけは良いのよね
Re: (スコア:0)
ユーザープロファイルごとにインストールするのやめてほしい
一時的にクリーンなプロファイルが必要でテスト用のアカウント作ってログオンすると
ガリガリガリガリインストールされて甚だ迷惑
極論するとWindowsの仕様自体が惰弱性 (スコア:0)
管理者権限の譲渡が使用者に知らされない状況で譲渡可能な仕様がある事自体が間違いだし。
Re: (スコア:0)
「だじゃく性」って流行ってんの？
何か対策してましたっけ？ (スコア:0)
MSが攻撃シナリオと対策のドキュメントを公開しただけで
修正パッチの類は無かったような
インストーラ (スコア:0)
基本的にこれの問題点はインストーラやアンインストーラが
TEMP ディレクトリやダウンロードディレクトリで実行されることが多くて、
そこに怪しい DLL を置かれるとまずいという話だと思うんですけど、違う？
Administrators 権限でプログラム実行している限り
上記以外のディレクトリでもヤバイ気がするし
regstry いじられるとどこにおいてもヤバイんだけど
やっぱり怪しいDLLを設置されてしまうという段階でNGな気がする。
Re: (スコア:0)
TEMPの中はひどいよね。各種インストーラーが適当に展開して放置した残骸でいっぱい
Wrapper Dll (スコア:0)
フックして横やり入れるDLLとかあると思うんだけど、アレの挙動もこの問題の一部って理解でいいのかな