アカウント名:
パスワード:
elevatedなプロセスが、一般ユーザが書き込めるフォルダに実行ファイルを書き出して実行しちゃうもんだから、そのタイミングで実行ファイルを置き換えればelevateされた権限で実行できるってやつだよね。
Microsoftがすぐに修正しないのは、「UACはsecurity boundaryではない」(よって脆弱性ではない)っていういつもの立場からだろう。
原因としては、高権限プロセス用の一時フォルダが、標準で存在しないのが問題なのかなあという気がする。
#「UAC security boundary」でググったら「UAC is a security boudanry」っていうTwitterアカウントが見つかって笑った。
DLLの読み込み方法をこれからはちょっと考えるべきだな仕組みを変えようってことではなく「プラグイン」としてのDLLの在り方
根っこにあるのが、MS-DOSのPATH環境変数や、その周辺の仕様だから難しそう。
.NET FrameworkのReflectionみたいに、ピンポイントでファイル名を指定してロードさせるような仕様ならいいけど、既存の(たとえばWin32API等の)DLLは「規定の順序で探して、最初に見つかったファイル」という形式だし・・・。
指定した署名付きの物以外はロードできないようにするオプションをつけるのが手っ取り早い。
その認識はちょっと古い。OSとしては、SetDllDirectoryなどによって、DLLをロードするディレクトリというのは制御可能になっているし現状では、特に問題はない。これは単純にSkypeというアプリの問題に過ぎない・・・というといい過ぎかな。しかし、SkypeはもともとMS製じゃないアプリだから、根幹の部分で修正しきれない難しい問題があるのだろう。
SetDllDirectoryにせよ、System.Reflection.Assembly.LoadFromにせよ、今後作るアプリへの対策としては十分で、OSの制御としては特に問題ないと思いますよ。
ただ、既にあるレガシーなアプリが、上記の仕組みを組み込めるかは別問題だよねって。理論的にはSetDLLDirectoryは比較的低コストで従来のWin32アプリに組み込めるとは思うけど、それでも動作検証のコストは莫大になりそうだし。そしてMS-DOSからの使用を引きずるかぎり、そういったレガシーなアプリのDLL読み込みに「OS側が干渉して不正なDLLから保護する」方式はとれないから、後方互換を維持する限りは延々と続く問題じゃないの?これ。
# 本気でやるならSetDllDirectoryを使う前にDLLをロードしようとしたアプリを停止させるぐらいは必要だけど# それで古いアプリはこぞって動かなくなるので、それでいいの?って話だと思うの。
SetDllDirectory()で対策出来るのは実行時リンクするDLLだけでエントリポイントに達する前にロード時リンクされるDLLに対しては全く対策にならない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
なんか前にも見たような (スコア:1)
elevatedなプロセスが、一般ユーザが書き込めるフォルダに実行ファイルを書き出して実行しちゃうもんだから、
そのタイミングで実行ファイルを置き換えればelevateされた権限で実行できるってやつだよね。
Microsoftがすぐに修正しないのは、「UACはsecurity boundaryではない」(よって脆弱性ではない)っていういつもの立場からだろう。
原因としては、高権限プロセス用の一時フォルダが、標準で存在しないのが問題なのかなあという気がする。
#「UAC security boundary」でググったら「UAC is a security boudanry」っていうTwitterアカウントが見つかって笑った。
Re:南極28号 (スコア:0)
DLLの読み込み方法をこれからはちょっと考えるべきだな
仕組みを変えようってことではなく「プラグイン」としての
DLLの在り方
Re:南極28号 (スコア:1)
根っこにあるのが、MS-DOSのPATH環境変数や、その周辺の仕様だから難しそう。
.NET FrameworkのReflectionみたいに、ピンポイントでファイル名を指定してロードさせるような仕様ならいいけど、既存の(たとえばWin32API等の)DLLは「規定の順序で探して、最初に見つかったファイル」という形式だし・・・。
Re: (スコア:0)
指定した署名付きの物以外はロードできないようにするオプションをつけるのが手っ取り早い。
Re: (スコア:0)
その認識はちょっと古い。
OSとしては、SetDllDirectoryなどによって、DLLをロードするディレクトリというのは制御可能になっているし現状では、特に問題はない。
これは単純にSkypeというアプリの問題に過ぎない・・・というといい過ぎかな。
しかし、SkypeはもともとMS製じゃないアプリだから、根幹の部分で修正しきれない難しい問題があるのだろう。
Re:南極28号 (スコア:1)
SetDllDirectoryにせよ、System.Reflection.Assembly.LoadFromにせよ、今後作るアプリへの対策としては十分で、OSの制御としては特に問題ないと思いますよ。
ただ、既にあるレガシーなアプリが、上記の仕組みを組み込めるかは別問題だよねって。
理論的にはSetDLLDirectoryは比較的低コストで従来のWin32アプリに組み込めるとは思うけど、それでも動作検証のコストは莫大になりそうだし。
そしてMS-DOSからの使用を引きずるかぎり、そういったレガシーなアプリのDLL読み込みに「OS側が干渉して不正なDLLから保護する」方式はとれないから、後方互換を維持する限りは延々と続く問題じゃないの?これ。
# 本気でやるならSetDllDirectoryを使う前にDLLをロードしようとしたアプリを停止させるぐらいは必要だけど
# それで古いアプリはこぞって動かなくなるので、それでいいの?って話だと思うの。
Re: (スコア:0)
SetDllDirectory()で対策出来るのは実行時リンクするDLLだけでエントリポイントに達する前にロード時リンクされるDLLに対しては全く対策にならない