スターアライメントガイド：カーネルプールスプレーとVMware CVE-2013-2406

Windowsのカーネルモードの脆弱性を混乱させる場合、遅かれ早かれ、カーネルプールスプレーなどの手法に対処する必要があります（「アトミックヒープアトマイゼーション」と呼ばないでください）。 カーネルメモリプールの動作を制御する機能は、エクスプロイト開発者にとって役立つと思います。



この手法を習得するには、少なくともカーネルプールデバイスの大まかな概念が必要です。 この記事では、プールスプレー技術のコンテキストで重要な実装の詳細のみを説明しようとします。 カーネルプールのデバイスは十分に研究されているため、さらに詳細な知識が必要な場合は、検索サービスまたは記事の最後にあるリンクに問い合わせてください。

カーネルプール構造の概要

カーネルメモリプール-オペレーティングシステムのカーネル内でメモリの割り当てを要求できる単一の場所。 カーネルモードのスタックは小さく、配列ではないいくつかの変数の格納にのみ適しています。 ドライバーは、大きなデータ構造または文字列を作成する必要がある場合、さまざまなインターフェイスを使用してメモリを割り当てることができますが、最終的にはプールからメモリにアクセスします。



プールにはいくつかの種類がありますが、それらはすべて同じ構造を持っています（ドライバー検証ユーティリティで使用される特別なプール（特別なプール）を除く）。 各プールには、プール記述子と呼ばれる制御構造があります。 特に、プールの空き領域を形成するプールの空きブロック（チャンク）のリストを格納します。 プール自体はメモリのページで構成されます。 標準の4メガバイトまたは大きな2メガバイトにすることができます。 使用されるページ数は動的に調整されます。



カーネルプールのページは、異なるサイズのフラグメント（ブロック（チャンク））に分割されます。 カーネルモジュールがプールからメモリの割り当てを要求するときに、カーネルモジュールに割り当てられるのはブロックです。







ブロックには次のメタデータが含まれます。

• 前のサイズ-前のブロックのサイズ。
• プールインデックスは、同じタイプのプールが複数ある状況で使用されます。 たとえば、システムには複数のページプールがあります。 このフィールドは、ブロックが属するプールを決定するために使用されます。
• ブロックサイズ-現在のブロックのサイズ。 前のサイズフィールドと同様に、そのサイズは次のようにエンコードされます。
  
  （ブロックデータサイズ+ヘッダーサイズ+ブロックを占有するプロセスへのポインターのオプションの4バイト）>> 3（またはx64システムの場合は>> 4）。
• プールタイプは、文書化されていない（！）ビットフラグのセットです。
  
  
  • T（追跡）：ブロックは、ドライバーチェックユーティリティによって追跡されます。 このフラグはデバッグに使用されます。
  • S（セッション）：ブロックはセッションのページプールに属し、ユーザー固有のセッションデータにメモリを割り当てるために使用されます。
  • Q（クォータ）：ブロックはクォータ管理システムに登録されています。 このフラグは32ビットシステムにのみ適用されます。 設定されている場合、このブロックを所有するプロセスへのポインタがブロックの最後に書き込まれます。
  • U（使用中）：ブロックは現在使用中です。 「使用済み」状態とは異なり、ブロックは解放できます。つまり、ブロックからメモリを割り当てることができます。 このフラグは、Windows Vista以降、2番目のビットにあり、それ以前は3番目のビットにありました。
  • B（基本プール）：このフィールドは、ブロックが属する基本プールを決定します。 ページプールと非ページプールの2つの基本的なプールがあります。 ポンプされていないものはゼロでエンコードされ、ポンプされたものは1でエンコードされます。 Windows Vistaより前では、このフラグは（ベースプールタイプ+ 1）としてエンコードされていたため、2ビットを占有していました。 ページプールの場合は0x10、非ページプールの場合は0x1。
• プールタグは、デバッグの目的で使用されます。 カーネルモジュールは、ブロックが属するサブシステムまたはドライバーを識別する4つの印刷可能な文字の署名を示します。 たとえば、タグ「NtFs」は、ブロックがNTFS ntfs.sysファイルシステムドライバーに属していることを意味します。

64ビットシステムでは、ブロック構造にいくつかの違いがあります。 まず、ヘッダーフィールドが大きくなり、次に、このブロックを使用するプロセスへのポインターを持つ8バイトフィールドがあります。

プール内のメモリを割り当てるための原則の概要

プールが空であると想像してください。 つまり、そこにはまったく場所がありません。 メモリを割り当てようとすると（たとえば、0xFF0バイト未満）、メモリページが最初に割り当てられ、次にページの先頭にあるブロックが割り当てられます。







これで、2つのブロックが割り当てられました-割り当てられたブロックと空きブロックです。 空きメモリは、その後のメモリ割り当て操作で使用できます。 ただし、これ以降、プールアロケータは、割り当てられたブロックをページの最後またはこのページの空き領域に配置します。







ブロックの解放に関しては、説明されているプロセスはまったく逆です。 ブロックは自由になり、隣接している場合は1つのブロックにマージされます。







説明されている状況は架空のものであり、例としてのみ使用されていることに注意してください。実際には、プールはカーネルモジュールで使用できるようになるずっと前にメモリページで満たされます。

プールからのメモリ割り当ての制御

カーネルプールは負荷の高いオペレーティングシステムエンティティであることに注意してください。 まず第一に、それらはカーネルのあらゆる種類のオブジェクトと内部データ構造を作成するために使用されます。 さらに、多くのシステムコールでプールを使用して、ユーザーモードパラメータをバッファします。 オペレーティングシステムはドライバーを介してハードウェアを、システムコールを介してソフトウェアを常に維持するため、システムのダウンタイム中でもプールの使用頻度を概算できます。



遅かれ早かれ、プールは断片化されます。 これは、異なるサイズのメモリブロックの割り当てと割り当て解除が異なる順序で行われるためです。 したがって、スプレーという用語が表示されます。 プールからメモリを順番に割り当てる場合、ブロックは連続している必要はなく、ほとんどの場合、メモリの異なる部分にあります。 したがって、メモリを制御された（赤）ブロックで満たすと、右側よりも左側に画像が表示される可能性が高くなります。







ただし、搾取のコンテキストでは重要な状況があります。「シェーディング」された黒い領域がない場合、余分なスポットのない真新しい領域を取得します。 そしてその瞬間から、「スプレーブラシ」は、塗りつぶしのある通常のブラシに変わります。 この事実により、プールとその「画像」の動作を大幅に制御できます。 重要なのは完全な制御ではありません。この場合でも、他の誰かが常に別の色の「スプラッシュ」で私たちを遮ることができるため、「写真」を完全に所有しているという保証はありません。







プールスプレーに使用されるオブジェクトの種類に応じて、必要な数の以前に作成されたオブジェクトを削除することにより、空きブロックから特定のサイズのウィンドウを作成することができます。 しかし、プールからのメモリの割り当てを制御できる最も重要な事実は、アロケータが最大のパフォーマンスを目指していることです。 プロセッサキャッシュを最も効率的に使用するために、最後に解放されたメモリブロックが最初に割り当てられます。 割り当てられたブロックのアドレスを推測できるため、これが制御された割り当てのポイントです。



もちろん、ブロックサイズが重要です。 したがって、最初に解放されたブロックからウィンドウサイズを計算する必要があります。 0x20バイトをプールするオブジェクトのサイズで0x315バイトのブロックサイズを選択的に制御する場合は、0x315 / 0x20 =（0x18 + 1）ブロックを解放する必要があります。 これは理解できると思います。



カーネルプールスプレー技術の使用方法に関する注意事項：

• オペレーティングドライバーを使用してプールからメモリを割り当てる可能性がない場合は、プールスプレーのオブジェクトとしてオペレーティングシステムオブジェクトを使用する機会が常にあります。 奇妙なことに、OSオブジェクトはOSカーネルに格納されるため、それらのメモリはさまざまなプールから割り当てられます。
  
  
  • 非ページプールには、プロセス、スレッド、セマフォ、ミューテックスなどが格納されます。
  • スワッププールには、ディレクトリオブジェクト、レジストリキー、セクション（いわゆるファイルの関連付けまたはファイルマッピング）などが含まれます。
  • セッションプールには、GDIおよびUSERサブシステムのオブジェクト（パレット、デバイスコンテキスト（DC）、ブラシなど）が格納されます。
  これらのオブジェクトが占有しているメモリを解放するには、対応する記述子を閉じるだけで十分です。
• プールをオブジェクトで満たし始めるまでに、そこにブロックを割り当てることができる多くのメモリページが含まれます。 ただし、これらのページは断片化されます。 制御されたブロックで連続的に埋めてスペースを確保する必要があるため、最初に行う必要があるのは、現在のページに空きスペースがないようにプールを「スパム」することです。 この場合にのみ、新しいページが使用可能になり、制御されたブロックで連続して満たすことができます。 つまり、多くのオブジェクトを作成する必要があります。
• 必要なウィンドウサイズを計算するときは、ブロックヘッダーのサイズだけでなく、32ビットシステムでは最終サイズが8バイトに、64ビットシステムでは16バイトに丸められることも考慮してください。
• ブロックの割り当てを制御できるという事実にもかかわらず、それらの相対的な位置を予測することはかなり困難です。 ただし、プールスプレーにOSオブジェクトを使用する場合、NtQuerySystemInformation（）関数とSystemExtendedHandleInformationパラメーターを使用して、記述子によってオブジェクトのアドレスを見つけることができます。 彼女に提供される情報は、プール噴霧の精度を向上させるために必要です。
• プールにスプレーするときはバランスを保ちます。 オブジェクトを選択するときに欲張りにならないでください。 明らかに、システムのメモリが不足した場合、ブロックの割り当てを制御することは不可能です。
• カーネルプールを使用したエクスプロイトの信頼性を高めるための秘Oneの1つは、プールスプレーを実行して脆弱性を開始するスレッドの優先度を上げることです。 スレッドは本質的にプールメモリを常に競合しているため、システム内の他のスレッドよりも頻繁に実行される可能性を高めることにより、ヒープを使用する優先順位を上げると便利です。 これにより、テクニックがより全体的になります。 また、プールスプレーと脆弱性の開始の間の遅延を考慮に入れてください。それが小さいほど、必要なブロックに陥る可能性が高くなります。

VMware CVE 2013-1406

2月上旬に、VMware製品の更新に関する興味深い推奨事項がリリースされました。 それらから判断すると、更新されていないコンポーネントに脆弱性が存在し、メインOSとゲストOSの両方でローカル権限が昇格されました。 このような「おいしい」脆弱性は無視できません。



脆弱なコンポーネントはvmci.sysでした。 VMCIは、仮想マシン通信インターフェイスの略です。 このインターフェイスは、仮想マシンとメインOS間の対話に使用されます。 VMCIは、vsocklib.dllライブラリでWindowsソケットサービスプロバイダーとして実装された独自のタイプのソケットを提供します。 vmci.sysドライバーは、必要な機能を実装する仮想デバイスを作成します。 常にメインOSで実行されています。 ゲストシステムの場合、VMCIが機能するには、VMwareツールをインストールする必要があります。



レビューを書くとき、レビューが探偵小説に変わるように、脆弱性の高レベルのロジックを説明することは素晴らしいことです。 残念ながら、この場合、VMCIの実装に関する公開情報がほとんどないため、これは成功しません。 しかし、エクスプロイト開発者はこれについて心配していないと思います。 少なくとも、システム全体がどのように機能するかを分析するのに多くの時間を費やすよりも、実用的なエクスプロイトを取得する方が有益です。



PatchDiffは、パッチを適用した3つの機能を明らかにしました。 それらはすべて、同じIOCTL制御コード0x8103208Cの処理に関連しています。 どうやら、その処理で特にすべてがうまくいかなかったようです...







3番目に更新された関数は、最終的に最初と2番目の両方から呼び出されました。 彼女は、要求されたサイズに0x68を掛けたブロックを割り当て、ゼロで埋めて初期化する必要がありました。 このブロックには、リクエストを処理するための内部データ構造が含まれています。 問題は、割り当てられたブロックのサイズがユーザーモードで示され、実際にチェックされなかったため、内部構造が割り当てられなかったため、興味深い結果がもたらされることでした。



制御コード0x8103208Cの場合、入力および出力バッファーが指定されました。 弱点に到達するには、そのサイズは0x624バイトでなければなりません。 要求を処理するために、0x20Cバイトの内部構造が割り当てられました。 最初の4バイトは、アドレス[user_buffer + 0x10]で指定された値で埋められました。 将来、2番目のデータ構造を強調表示するためにこれらのバイトが使用され、そのアドレスは最初のデータ構造の最後に示されました。 これにより、2番目の構造体の割り当ての結果に関係なく、特定のディスパッチ関数が呼び出されました。





このディスパッチ関数は、プロセスへのポインターを探しました。 処理には、構造に設定されたフラグに応じて、オブジェクトの逆参照と関数の呼び出しが含まれていました。 しかし、誤ったパラメーターで処理するために構造を分離することは不可能だったため、ディスパッチ関数は最初のブロックの境界を越えて単に「通過」しました。 このような処理により、アクセス違反と「死のブルースクリーン」が発生しました。





したがって、制御されたアドレスで任意のコードを実行できます。

 .text:0001B946 UnsafeFire proc near .text:0001B946 .text:0001B946 .text:0001B946 arg_0 = dword ptr 8 .text:0001B946 .text:0001B946 000 mov edi, edi .text:0001B948 000 push ebp .text:0001B949 004 mov ebp, esp .text:0001B94B 004 mov eax, [ebp+arg_0] .text:0001B94E 004 push eax .text:0001B94F 008 call dword ptr [eax+0ACh] ; BANG!!!! .text:0001B955 004 pop ebp .text:0001B956 000 retn 4 .text:0001B956 UnsafeFire endp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

運営

ディスパッチ関数はブロックの境界を超えて拡張されるため、隣接ブロックまたは未投影ページのいずれかで発生します。 投影されていないメモリに入ると、未処理の例外が発生するため、「ブルースクリーン」が表示されます。 しかし、隣接ブロックにヒットすると、ディスパッチ関数はヘッダーを処理用の構造体へのポインターとして解釈します。



x86システムがあるとします。 ディスパッチ関数がポインターとして解釈しようとする4バイトは、実際には以前のブロックサイズ、プールインデックス、現在のブロックサイズ、およびプールタイプフラグです。 処理中のブロックのプールのサイズとインデックスがわかっているため、ポインターの下位ワードの意味がわかります。



0xXXXX0043-0x43はブロックのサイズであり、隣接するブロックの[前のサイズ]フィールドになります。 0-プールインデックス。これらのブロックは非ポンププールにあり、システム内では1つだけであるため、正確にゼロであることが保証されます。 隣接ブロックが同じメモリページを共有している場合、それらは同じタイプとプールのインデックスに属していることに注意してください。



上位ワードには、予測できないブロックサイズと、逆に予測可能なプールタイプフラグが格納されます。

• B = 0：非ページプールからのブロック
• U = 1：ブロックが使用中であることを意味します
• Q = 0/1：ブロックはクォータにすることができます
• S = 0：プールはセッションではありません
• T = 0：ブロックはデフォルトで追跡されません
• 未使用ビットはゼロです

したがって、Windows 7および8で有効な次のメモリ領域があります。

• 0x04000000-通常ブロックの場合は0x06000000
• 0x14000000-クォータブロックの場合は0x16000000

上記の情報に基づいて、Windows XPなどのメモリ領域を個別に計算できます。



ご覧のとおり、これらの領域はユーザー空間に属しているため、ディスパッチ関数に、私たちが制御するコードを含む任意のコードを実行させることができます。 これを行うには、最初にプロセス内の指定されたメモリ領域を投影し、次に0x10000バイトごとに、ディスパッチ機能の要件を満たす必要があります。

1. アドレス[0x43 + 0x38]で、次の条件を満たすためにDWORD = 0x00000001を配置する必要があります。
   
   

    .text:0001B2E1 010 lea edx, [eax+38h] .text:0001B2E4 010 lock xadd [edx], ecx .text:0001B2E8 010 cmp ecx, 1
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

2. アドレス[0x43 + 0xAC]に、シェルコードへのポインターを配置する必要があります。
3. アドレス[0x43 + 0x100]に、ObfDereferenceObject（）関数によって逆参照されるシェルオブジェクトへのポインターを配置する必要があります。 参照カウンタは、オブジェクトに対して負のオフセットでヘッダーに格納されるため、ObfDereferenceObject（）関数のコードが投影されていない領域に落ちないようにしてください。 また、参照カウンターに適切な値を指定します。たとえば、参照カウンターがゼロに達すると、ObfDereferenceObject（）はユーザーモードメモリに完全に適さない関数によってメモリを解放しようとするためです。

VMware製品によってオフセットが異なる場合があることに注意してください。



すべてが正しく行われました！

エクスプロイトの安定性が向上

この脆弱性を悪用するための優れた戦略を開発したという事実にもかかわらず、それはまだ信頼できません。 たとえば、ディスパッチ関数は、フィールドを予測できない空きブロックに分類される場合があります。 そのようなブロックのタイトルは（ゼロに等しくないため）ポインターとして解釈されるという事実にもかかわらず、その処理の結果はブルースクリーンエラーになります。 これは、ディスパッチ関数が投影されていないメモリ領域に落ちたときにも発生します。



この場合、カーネルプールスプレー技術が助けになります。 プールスプレーオブジェクトとして、セマフォはサイズが最適であるため、選択しました。 この手法を使用した結果、エクスプロイトの安定性が大幅に向上しました。



SMEPなどのセキュリティメカニズムのサポートがWindows 8に登場したことを思い出させてください。そのため、開発者の怠lazが悪用開発を多少複雑にします。 SMEPバイパスを使用してベースに依存しないコードを記述することは、読者の課題です。



x64システムに関しては、ポインターのサイズが8バイトに等しくなったという事実に問題があります。 これは、ポインターの最も古いダブルワード（DWORD）がプールタグフィールドに入ることを意味します。 また、ほとんどのドライバーとカーネルサブシステムはこのようなラベルにASCII文字を使用しているため、ポインターは非標準のアドレス空間に入り、操作に使用できません。 この記事を書いている時点では、これについて賢明なことは考えていませんでした。

まとめ

提供された情報が役に立てば幸いです。 必要なものすべてをいくつかの段落に収めることができないことをおpoびします。 セキュリティレベルの完全な向上という名のもと、研究と運用の成功を願っています。



PS脆弱性を排除するには、メインシステムだけでなく、すべてのゲストシステムも更新する必要があることを思い出します。

PPS特定の用語の翻訳に不快感を感じる場合は、Microsoft言語ポータルでこの翻訳が推奨されているため 、将来的にそれを我慢する準備をしてください。



デモ！





参照資料

[1] Tarjei Mandt。 Windows 7でのカーネルプールの悪用。BlackHat DC、2011

[2]ニキータ・タラカノフ。 Windows XPからWindows 8へのカーネルプールオーバーフロー。ゼロナイト、2011年

[3] Kostya Kortchinsky。 実世界のカーネルプールの活用。 SyScan、2008

[4] SoBeIt。 Windowsカーネルメモリプールを活用する方法。 X'con、2005