カーネルモードでZwCreateKeyを呼び出すのがWindowsセキュリティを迂回するように見えるのはなぜですか？私が一緒に仕事

Question

チームは最近、仮想化ソフトウェアのサードパーティ製のpeiceと当社のソフトウェアは、互換性のある作りの課題に直面してきました。このソフトウェアは、カーネルドライバを使用してWindowsネイティブレジストリAPI（ZwCreateKeyなど）のフックを実行します。 Ntdllで呼び出しをフックすることによって動作します。私たちのソフトウェアもかなり低いレベルであり、状況によっては、実際のレジストリにアクセスする必要があります。

我々は彼らのフックを回避する当社に代わって、ZwCreateKey、などを呼び出すために私たち自身のカーネルドライバを使用しての可能性を模索しています。これは基本的に、NT Legacyドライバと独自のネイティブレジストリ機能を提供するユーザーモードライブラリを作成することを意味していました。ライブラリとドライバは、我々は単にそれから、我々はコールのカーネルバージョンを呼び出し、結果を返す私たちの運転手にZwCreateKeyのすべてのパラメータなどを渡すためにIOCTLを使用し、非常に単純です。

アプローチがうまく機能している、と私たちは今、仮想化されたときに、実際のレジストリへの書き込み/読み取りのシステムを持っているように見えます。唯一の問題は、新しいシステムがWindowsのセキュリティをレジストリオブジェクトに引き継いでいるように見えることです。

ZwCreateKeyはそうのようなアクセスマスクを取ります

NTSTATUS ZwCreateKey(
    __out  PHANDLE KeyHandle, 
    __in  ACCESS_MASK DesiredAccess, 
    __in  POBJECT_ATTRIBUTES ObjectAttributes, 
    __reserved ULONG TitleIndex, 
    __in_opt PUNICODE_STRING Class, 
    __in  ULONG CreateOptions, 
    __out_opt PULONG Disposition 
); 

私の理解では、我々は今、カーネルモードで実行されていたが、我々はまだユーザーのトークンのコンテキストを持っていたということでした。これは、カーネルバージョンZwCreateKeyが、アクセスマスクテストが失敗した場合にユーザが持つように失敗することを意味するはずです。実際に何が起こっていることは、当社のドライバが呼び出されたときに限られたユーザーが起動したときにも、限られたトークンを使用して、それが制限された部品HKLMのキーを作成することができるということです。何がありますか？ ACLを実行して自分自身をチェックする必要がありますか？カーネルモードで自分の特権を制限するために何かする必要がありますか？どんな助けでも大歓迎です。説明のための

Answer 1

チェックthis。基本的には、ユーザーモード（Ntdll）のNt/Zwは同じことです。まず、実際にアクションを実行する前に広範なチェックを実行します。カーネルモードからZw関数を呼び出すとき（デバイスドライバの場合のように）は、カーネルモードのコンポーネント（ドライバなど）からの情報がデフォルトで信頼されると仮定されているため、これらのチェックは省略される。