アカウント名:
パスワード:
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は「規定の順序で探して、最初に見つかったファイル」という形式だし・・・。
指定した署名付きの物以外はロードできないようにするオプションをつけるのが手っ取り早い。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
なんか前にも見たような (スコア:1)
elevatedなプロセスが、一般ユーザが書き込めるフォルダに実行ファイルを書き出して実行しちゃうもんだから、
そのタイミングで実行ファイルを置き換えればelevateされた権限で実行できるってやつだよね。
Microsoftがすぐに修正しないのは、「UACはsecurity boundaryではない」(よって脆弱性ではない)っていういつもの立場からだろう。
原因としては、高権限プロセス用の一時フォルダが、標準で存在しないのが問題なのかなあという気がする。
#「UAC security boundary」でググったら「UAC is a security boudanry」っていうTwitterアカウントが見つかって笑った。
Re:南極28号 (スコア:0)
DLLの読み込み方法をこれからはちょっと考えるべきだな
仕組みを変えようってことではなく「プラグイン」としての
DLLの在り方
Re: (スコア:1)
根っこにあるのが、MS-DOSのPATH環境変数や、その周辺の仕様だから難しそう。
.NET FrameworkのReflectionみたいに、ピンポイントでファイル名を指定してロードさせるような仕様ならいいけど、既存の(たとえばWin32API等の)DLLは「規定の順序で探して、最初に見つかったファイル」という形式だし・・・。
Re:南極28号 (スコア:0)
指定した署名付きの物以外はロードできないようにするオプションをつけるのが手っ取り早い。