web-dev-qa-db-ja.com

Windows OS内のTOCTTOUの脆弱性をどのように軽減できますか？

Windowsのアクセス許可に適用される使用時間チェックの問題を緩和するいくつかの方法は何ですか？

例：

  1. エンドユーザーは、ソフトウェアやプリンターなどをインストールするためにローカルのAdministratorsグループに追加されます。
  2. ユーザーがログインしている間、ユーザーのアカウントはAdministratorsグループから削除されます。
    • 権限の変更は、ユーザーが次にログインするまで適用されません。
  3. 管理者権限がまだ適用されているユーザーは、ログオフする前にAdministratorsグループに自分自身を追加し、削除を取り消します。
  4. 次回ユーザーがログインしたときは、再び削除されるまで（引き続き滞在するまで）、引き続き管理者権限が付与されます。

単にnotを除いて、最初にエンドユーザーに管理者権限を付与する（明白な解決策）、または特定のエンドユーザーアクションを必要とする他の手段によって、上記のシナリオ（または同様の方法）は何かWindows固有のTOCTTOUの問題）を防ぐことができますか？

windows
9
Iszi

Windows（または該当する場合は独自のアプリケーション）を修正します。この例では、Windowsを修正する必要があります。 TOCTOUの脆弱性は、チェックと使用を分離しないことでのみ対処できます。私が見たアプリケーションでのはるかに一般的な例：一時ファイル（はい、人々はまだこれを間違っています）。見たときにファイルが存在しないからといって、それを使用しようとしても存在しないというわけではありません。

この例に固有：Mac OS Xの承認サービスは、ログイン時にユーザーがどのような特権を持っているかをチェックしません。それは、権利を取得できるかどうかを調べます取得時に。適切に設計されたアプリケーションでは、特権コンポーネントが適切な使用時にがあるかどうかを検査するため、TOCTOUの脆弱性のウィンドウは制限されます。それはゼロではありません-権利を取得し、その権利を取り消して、すでに取得したセキュリティコンテキストを特権コンポーネントに渡すことができますが、それには時間制限があります。

それで、あなたはなんとか自分でMicrosoftに就職し、このバグの修正を任されていたとしましょう。ユーザーがログインすると、セッションマネージャーがsecurityContext = GetUserAccountControlsContext();を実行し、中央データベースからユーザーの権限をコピーすることがわかります（引数の目的でAPIを作成していますが、これはどのように機能するかです）。セッションがそれを参照できるように、ディレクトリサービス。

後で、ユーザー権利を管理するためのコードがIsUserAuthorizedForAction(kMakeUserAdminAction, securityContext);を呼び出して、自分自身を管理者にするためのUIを有効にする必要があるかどうかを確認します。彼がボタンをクリックすると、MakeUserAdmin(user)alsoは同じセキュリティコンテキストで同じチェックを呼び出します。

修正は、コンテキストの最初の取得を削除することです。 IsUserAuthorizedForAction(action, context)のテストを変更して、GetUserAccountControlsContext()自体を呼び出します。結果はnotでキャッシュされるはずですが、呼び出しのたびに新しく検索される必要があります。これにより、2つの顕著な問題が残ります。

  1. UI対応チェックが完了すると、ユーザーは認証されませんが、後で認証されます。これを修正するには、セキュリティコンテキストの変更を監視するか、まれに発生するわずかな煩わしさとして受け入れます。
  2. UI対応チェックが完了すると、ユーザーは認証されますが、ボタンをクリックするまでに認証されません。これは、MakeUserAdmin()が（最新の）セキュリティコンテキストをテストするという事実によって処理されます。実際に必要な権限を取得できない場合は、例外をスローする必要があります。
4
user185

宣言された質問に実際に答えることなく、私はあなたの与えられた例に取り組みたいと思っています。

ユーザーに管理者権限を付与すると、それが完了すると、二度とそれらを取得できなくなります。
あなたが言うように、ユーザーは自分をAdministratorsグループに追加し直すことができます...しかし、実際には、彼が特権を保持している間に、彼が特権を保持していることを確認できる方法は他にもたくさんあります。たとえ完全かつ完全なシステム監査をオンにしたとしても、それを削除するのは難しいでしょう。

たとえば、別のユーザーを作成して、それを管理者に追加できます。
またはアドミニストレーターでパスワードをリセットし、それを有効にします。 （あなたはそれを使わないので、right ??、あなたは決して知らないでしょう...）
または別のグループを作成して非表示にし、管理者のメンバーとして追加します。
または、LOCALSYSTEMとして実行されているWindowsサービスまたはMSTaskなどをセットアップするだけです。
または、ある種のルートキットをインストールします。

もちろん、システム監査は実際には役に立ちません。管理者は一時的にそれを簡単に停止できるからです...

続行することはできますが、私のポイントがすでに証明されているといいのですが... TOC-TOUはではありませんここに問題があります。一時的な管理権限が付与されます（本当に可能です）、またはおそらく一般的に悪意のある管理者（本当に難しい問題）に対処します。

おっしゃったように、エンドユーザーに管理者権限を付与しないでください。彼らがプログラムをインストールできるようにする他のソリューションがあります。

4
AviD

これは、最小特権モデルに従っていないため、メソッドが本質的に安全でない状況の1つです。

Windowsに関する限り、ユーザーがアプリケーションをインストールできるようにするためのより良い方法があります。 Server 2003およびWindows XPでは、グループポリシーソフトウェアインストールポリシーを使用して、ユーザーがホワイトリストからソフトウェアをインストールできるようにすることができます。

0
surfasb