悪用に対するブラウザーの保護に関する一連の記事を続けます。

• はじめに
• Internet ExplorerとEdge

Chromeブラウザーの内部を調べて、その不正利用兵器の内容を調べてみましょう。

最新バージョンのWindowsおよびコンパイラーによって提供される一般的なメカニズムが含まれます。

• モジュールデータベースのランダム化（画像ASLR）。
• HighEntropy ASLR（64ビットアドレスを使用、Windows 8以降）;
• Force ASLR（モジュールベースの強制ランダム化）;
• 割り当てのランダム化（HeapAlloc、VirtualAlloc、Windows 8以降）：
  
  メモリ割り当て関数は、返されるメモリベースを3つの方法で選択します。
  
  
  • 最下位アドレスを選択します。
  • 最上位アドレスの選択
  • 特定のベースに関連するアドレスを選択します。
    
    Windows 8より前のシステムでは、最初の2つの方法はランダム化されていなかったため、
    
    予測可能なアドレスにメモリを割り当てることができます。
• データ実行防止：
  
  非実行可能メモリ（スタック、ヒープ、これらのモジュールのセクションなど）。
• スタックCookie（カナリア）：
  
  関数のプロローグでは、スタックに戻りアドレスの前にランダムな値が配置され、制御を返す前にチェックされます。 スタック内のバッファオーバーフローの操作を複雑にします。
• 安全な構造化例外処理（SAFESEH）：
  
  制御構造SEH_EXCEPTION_REGISTRATION_RECORDの内容を上書きすることにより、制御の傍受を防ぎます。 この構造で指定されたハンドラに制御を渡す前に、チェックされます。 ハンドラーが属する実行可能モジュールが/ SAFESEHで構築されている場合、アドレスはこのモジュールのハンドラーのSEHテーブルと照合されます（リンク中に、バイナリーに縫い付けられます）。
• 構造化例外ハンドラーの上書き保護（SEHOP）：
  
  それ自体は理想からほど遠いため、以前の手法を補完します。 第一に、アプリケーションの再コンパイルが必要でした。第二に、ハンドラが/ SAFESEHのないモジュールにある場合、またはモジュールの外側にある場合でも、単に機能しませんでした。 そのため、MicrosoftはOSレベルのテクノロジー-SEHOPを追加しました。 その本質は、SEHチェーンの整合性をチェックすることです。ストリームの開始時に、「カナリア」がSEHハンドラーのチェーンに追加され、ハンドラーが呼び出される前にその存在がチェックされました。 原則として、例外ハンドラーのアドレスを書き換えると、ポインターはチェーン内の次の構造を上書きします。これにより、チェーンが破損し、「カナリア」にアクセスできなくなります。
• 制御フローガード（CFG）：
  
  間接ジャンプコマンドでアドレスをチェックすることにより、仮想関数テーブルを含むプログラムデータのアドレスを書き換えることにより、制御フローが傍受されるのを防ぎます。 モジュール関数の有効なアドレスはビットマップに保存されます。ビットマップはコンパイラーによって作成されます。 詳細
• Windows緩和ポリシー：
  
  Windows 8以降によってプロセスに適用されるいくつかの制限。Chromeでは、サンドボックスに次のものを使用します。
  
  
  • 画像の再配置
  • ヒープ終了
  • ボトムアップASL
  • 高エントロピーASLR
  • 厳密なハンドルチェック
  • フォントの読み込みを無効にする
  • リモートデバイスからのイメージロードを無効にする
  • 「必須の低」（低整合性レベル）の画像ロードを無効にします
  • 子プロセスの作成をさらに無効にする

ブラウザの内部メカニズムを検討します。

• 配分PartitionAlloc：
  
  さまざまなサイズとタイプのオブジェクトをさまざまなヒープに分散できるため、解放されたメモリの候補オブジェクトを選択する攻撃者の能力が低下します。 ヒップ自体の内側とその境界の両方で、ヒープオーバー/アンダーフローをキャッチするのに役立ちます。 詳細-さらに。
• C ++のガベージコレクターのトレース-Oilpan;
• JavaScript JITコンパイラー：
  
  エクスプロイト要素の生成に使用することを困難にする多くのメカニズムが含まれています。
• サンドボックス：
  
  コンポーネントのセキュリティ侵害による被害を減らすために設計されたブラウザセキュリティシステム。

UaFとメモリ破損の概要

ブラウザは、ドキュメントコンポーネントオブジェクト（Webページ）を管理するためのAPIを提供します。 このドキュメントの内容はノードのツリーの形式で表され、各ノード（要素、属性、テキスト、グラフィック、またはその他のオブジェクト）はDOMの表現です。 このツリーのノード（「ノード」）は、JavaScriptで作成、破棄、および変更できます。 多くの相互依存する複雑なオブジェクトの存在は、バグの存在の前提条件であり、JavaScriptを使用してこれらのオブジェクトを管理する便利さは、これらのバグを使用する方法です。

ヒープ上のオブジェクトに損傷を与えるバグは、ブラウザーが悪用する一連のアクション全体の開始点であることが非常に多いです。 それらによって引き起こされる脆弱性は、大きく2つのカテゴリに分類できます。

1. 一時的（一時的）-オブジェクトの存在期間外にオブジェクトを使用しようとした結果として発生します（たとえば、リリース後にオブジェクトのメソッドを呼び出します）。
2. 空間（空間）-メモリ内のオブジェクトの場所を超える誤ったアクセス（たとえば、無効なインデックスの配列要素へのアクセス）によって生成されます。

脆弱なオブジェクトを使用して、メモリ内の他のオブジェクトへのターゲットを絞った影響を防ぐために、アロケーターで実装された多くのメカニズム（ヒープマネージャー）を考慮することが提案されています。

Blink-Chromeレンダラー-独自の2つのアロケーター：PartitionAllocとOilpan（別名BlinkGC）を使用します。 2つのまれなケースがあります。

• 破棄可能なメモリ-大きなグラフィックオブジェクトをキャッシュするために使用されるページメモリ。 デバイスの空きメモリがなくなると解放されます。
• malloc、彼らは完全に取り除きたい。

Partitionalloc

PartitionAllocは、 自動ガベージコレクションが想定されていないオブジェクトに使用されます。 これが彼のOilpanとの大きな違いです。

PartitionAlloc設計には、メモリ内のオブジェクトの安全性に関連する要素が含まれます。

• 異なるタイプのオブジェクトの割り当ての分割。 この分離により、脆弱性のあるオブジェクトから別のタイプのオブジェクトへのデータの読み取りまたは書き込みにつながるバグを悪用した場合、攻撃者が持つ能力が低下します。たとえば、このヒープの線形バッファオーバーフローです。
  
  
  1. LayoutObjectsは、ページ要素を表示するためにレンダラーが使用するDOMノードに密接に関連するオブジェクトです。
  2. バッファ-配列、文字列、ビットベクトル用のバッファ。
  3. FastMalloc-さまざまなオブジェクトのかなり広範なリストです。
• ヒープメタデータを別の領域に保存する-つまり また、損傷を防ぐために断熱されています。
• freelist（空きメモリブロックのリスト）へのポインタは、部分的な書き換えまたは逆参照から保護されています。
• 大きな割り当ては個別に配置され、ガードページ（プロセスが緊急に中断されるアクセス時に割り当てられたブロックの終わりの前後のメモリページ）によってフレーム化されます。

この開発は、Mobile Pwn2Own 2013でPinkie Pie が示したエクスプロイトを見るとわかります。ここでは、著者は型付き配列のコンストラクターで発生する整数オーバーフローを使用しています。 条件は次のとおりです：Float64配列のバッファーが割り当てられますが、そのすべての要素の順次初期化はその終わりを超え、Float64型の任意の値の記録は、割り当てられたバッファーの後のメモリの8バイトごとにさらに任意に継続できます。 適切な長さの配列には、大きなバッファーが必要です。PartitionAllocは、割り当てをシステムアロケーター（Androidのdlmalloc）に委任します。 ピンキーパイは、ヒープ上の次の割り当てのタイトルを書き直し、サイズを変更し、そこに配置されたオブジェクトを解放し（フリーリストに適切なサイズのブロックを追加します）、この時点で特定のサイズの次のオブジェクトの割り当てを達成しました-任意の値を書き続けることができます。

ここから、開発者がアロケータメタデータを保護する理由、大規模な割り当てがガードページによってフレーム化され、この方法でバッファを超えることができない理由、型付き配列のバッファが他のオブジェクトから分離される理由がわかります。

オイルパン

Oilpanは、自動ガベージコレクションを提供します。 このシステムは、解放後使用クラスエラーの原因である開発者による手動メモリ管理の必要性を取り除きます。 そのようなエラーによって引き起こされた脆弱性の本質を簡単に思い出してみましょう。オブジェクトは時期尚早にリリースされます。つまり、その後に使用できるリリースです。

例として、プロジェクトバグトラッカーで見つけたものを見てみましょう： https ://bugs.chromium.org/p/chromium/issues/detail?id=69965ここで、Geolocationクラスに関連するUaFバグを検討します。 ページが更新されるとGeolocationクラスのオブジェクトが破棄されますが、ジオロケーションを解決するリクエストは以前にキャンセルされず、ハングポインターがリクエストマネージャーに残り、将来タブが閉じられたときにそれらをキャンセルしようとすると、freedへの誤ったアクセスが発生します位置情報オブジェクト。 このバグのパッチは、geolocationクラスにpageDestroyedメソッドを追加します。これは、ページオブジェクトをリリースするための正しい順序を調整しているようです。 それ以来、Geolocationクラスは、Oilpanの実装に関連する変更を受け、現在ではこのシステムによって自動的に制御されています。

このようなバグの悪用は、脆弱なオブジェクトがヒープから削除される条件を満たし、このオブジェクトから解放されたメモリに制御データを配置し、この方法で「偽オブジェクト」を作成し、この偽オブジェクトの要素を独自のメンバーとして使用する条件を満たします。 。 このアクションの2番目の部分-空きメモリに配置して偽のオブジェクトを作成する-を防ぐために、Chrome開発者は、異なるタイプのオブジェクトが存在するメモリ領域を分離します。 これがどのように行われるかを見てみましょう：

// Override operator new to allocate Node subtype objects onto // a dedicated heap. GC_PLUGIN_IGNORE("crbug.com/443854") void* operator new(size_t size) { return allocateObject(size, false); } static void* allocateObject(size_t size, bool isEager) { ThreadState* state = ThreadStateFor<ThreadingTrait<Node>::Affinity>::state(); const char typeName[] = "blink::Node"; return ThreadHeap::allocateOnArenaIndex( state, size, isEager ? BlinkGC::EagerSweepArenaIndex : BlinkGC::NodeArenaIndex, GCInfoTrait<EventTarget>::index(), typeName); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Chromium // src / third_party / WebKit / Source / core / dom / Node.h

オーバーライドされたnewでは、allocateObjectが呼び出され、引数isEager == falseであるため、ThreadHeap :: allocateOnArenaIndexは3番目の引数arenaIndexをBlinkGC :: NodeArenaIndex-オブジェクトを選択するアリーナインデックス（メモリ領域）になります。

 inline Address ThreadHeap::allocateOnArenaIndex(ThreadState* state, size_t size, int arenaIndex, size_t gcInfoIndex, const char* typeName) { ASSERT(state->isAllocationAllowed()); ASSERT(arenaIndex != BlinkGC::LargeObjectArenaIndex); NormalPageArena* arena = static_cast<NormalPageArena*>(state->arena(arenaIndex)); Address address = arena->allocateObject(allocationSizeFromSize(size), gcInfoIndex); HeapAllocHooks::allocationHookIfEnabled(address, size, typeName); return address; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Chromium // src / third_party / WebKit / Source / platform / heap / Heap.h

他にどのような地域が特定されていますか？

  enum HeapIndices { EagerSweepArenaIndex = 0, NormalPage1ArenaIndex, NormalPage2ArenaIndex, NormalPage3ArenaIndex, NormalPage4ArenaIndex, Vector1ArenaIndex, Vector2ArenaIndex, Vector3ArenaIndex, Vector4ArenaIndex, InlineVectorArenaIndex, HashTableArenaIndex, FOR_EACH_TYPED_ARENA(TypedArenaEnumName) LargeObjectArenaIndex, // Values used for iteration of heap segments. NumberOfArenas, }; * * * // List of typed arenas. The list is used to generate the implementation // of typed arena related methods. // // To create a new typed arena add a H(<ClassName>) to the // FOR_EACH_TYPED_ARENA macro below. #define FOR_EACH_TYPED_ARENA(H) \ H(Node) \ H(CSSValue) #define TypedArenaEnumName(Type) Type##ArenaIndex,
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Chromium // src / third_party / WebKit / Source / platform / heap / BlinkGC.h

ここでは、Nodeのメモリオブジェクト、CSSValue、HashTablesで、Vectorsクラスが分離されます。 このアロケーターによる他のオブジェクトは、サイズが領域ごとに分散されます。

Oilpan / BlinkGCの重要な機能である自動ガベージコレクションに移りましょう。 このシステムで管理する必要があるオブジェクトは、 GarbageCollected 、 GarbageCollectedFinalized、またはGarbageCollectedMixinテンプレートクラスを継承します。 ヒープにあるこれらのクラスのメンバーオブジェクトは、必要なセマンティクスに応じて、 MemberまたはWeakMemberテンプレートクラスによって表されます。

ガベージコレクションアルゴリズムはマークアンドスイープアルゴリズムであり、2つの主要なステップで構成されます。

1. mark-オブジェクトのグラフがトラバースされます;このために、それぞれのtrace（）メソッドが呼び出され、これから到達可能なオブジェクトをマークします そのようなバイパスの開始点は、プログラムの現在の状態に応じて2つのバリエーションで選択できます。
   
   
   • 正確-メッセージ処理サイクルの終わりにプログラムスレッドが停止するときに選択されます。 これにより、ストリームスタックに「生の」ポインタが存在しないことが保証されます。つまり、特別なグローバルな「永続ハンドル」ポインタから続行できます。
   • 保守的-スレッドのスタックを通過し、そこから可能なポインタを取得する必要がある場合に実行されます。
2. スイープ-前のステップで識別された到達不能オブジェクトはリリース用にマークされ、メモリが必要になると破棄されます。 ヒープからのオブジェクトの遅延削除の非決定的な順序により、オブジェクトのデストラクタを呼び出すときに、ヒープ内の関連オブジェクトの存在に依存できなくなります。 そのため、開発者は特別なメソッド-ファイナライザーを追加します。これらは、まだ生きているときに到達できないオブジェクトに対してこれらのステージ間で呼び出されます。

Jit硬化

動的に生成されたコードのアセンブリ中に受け取った命令が変更されなかった場合、攻撃者は実行可能メモリにシェルコードを作成できる強力なプリミティブを受け取ります。 これを回避するために、いくつかの対策が導入されました。

• NOP

  
  
  
  
  
  
  

  NOPは、1〜8バイトのさまざまなサイズのプログラム本体（環境の状態を変更しない命令で、その目的のみが行われる）にランダムに挿入されます。 これらは、アセンブルされたコードに一定のバイトシーケンスが現れる可能性を排除するために必要です。

  
  
  
  
  
  
  

   void Assembler::Nop(int n) { // The recommended muti-byte sequences of NOP instructions from the Intel 64 // and IA-32 Architectures Software Developer's Manual. // // Length Assembly Byte Sequence // 2 bytes 66 NOP 66 90H // 3 bytes NOP DWORD ptr [EAX] 0F 1F 00H // 4 bytes NOP DWORD ptr [EAX + 00H] 0F 1F 40 00H // 5 bytes NOP DWORD ptr [EAX + EAX*1 + 00H] 0F 1F 44 00 00H // 6 bytes 66 NOP DWORD ptr [EAX + EAX*1 + 00H] 66 0F 1F 44 00 00H // 7 bytes NOP DWORD ptr [EAX + 00000000H] 0F 1F 80 00 00 00 00H // 8 bytes NOP DWORD ptr [EAX + EAX*1 + 00000000H] 0F 1F 84 00 00 00 00 00H // 9 bytes 66 NOP DWORD ptr [EAX + EAX*1 + 66 0F 1F 84 00 00 00 00 // 00000000H] 00H ... }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  

• 一定の折りたたみ

  
  
  
  
  
  
  

  算術式は、コードアセンブリ中にカウント（折りたたみ）されます。

  
  
  
  
  
  
  

   <script> x = 0x123 + 0x567; // == 0x68A </script>
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  

   mov rax,68A00000000h
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  

• 絶え間ない盲目

  
  
  
  
  
  
  

  2バイトまでの値のみがコードに変更されずに保存されます。 例：

  
  
  
  
  
  
  

   <script> a = 0x1234; </script>
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  

  で組み立てられます：

  
  
  
  
  
  
  

   ... mov rax,123400000000h ...
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  

  より大きな定数は、ランダムな値（jit_cookie）でけんかします：

  
  
  
  
  
  
  

   void MacroAssembler::SafeMove(Register dst, Smi* src) { ... if (IsUnsafeInt(src->value()) && jit_cookie() != 0) { if (SmiValuesAre32Bits()) { // JIT cookie can be converted to Smi. Move(dst, Smi::FromInt(src->value() ^ jit_cookie())); Move(kScratchRegister, Smi::FromInt(jit_cookie())); xorp(dst, kScratchRegister); } else { DCHECK(SmiValuesAre31Bits()); int32_t value = static_cast<int32_t>(reinterpret_cast<intptr_t>(src)); movp(dst, Immediate(value ^ jit_cookie())); xorp(dst, Immediate(jit_cookie())); } } else { Move(dst, src); } }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  

• ガードページ

  
  
  
  
  
  
  

  アセンブルされたJITコードを含むバッファーは、ヒープが近くの割り当てでオーバーフローした場合に上書きされないように、PAGE_NOACCESSページによってフレーム化されます。

  
  
  
  
  
  
  

• JITページのランダム化

  
  
  
  
  
  
  

  組み立てられたJITコードが配置されるメモリの場所は、多くの場合（常にではありませんが）ランダム化されます。 3回試行しても空きアドレスが推測されない場合、Chromeはシステムアロケーターが作成されたバッファーのアドレスを選択できるようにします。

  
  
  
  
  
  
  

   static void* RandomizedVirtualAlloc(size_t size, int action, int protection) { ... if (use_aslr && (protection == PAGE_EXECUTE_READWRITE || protection == PAGE_NOACCESS)) { // For executable pages try and randomize the allocation address for (size_t attempts = 0; base == NULL && attempts < 3; ++attempts) { base = VirtualAlloc(OS::GetRandomMmapAddr(), size, action, protection); ... } void* OS::GetRandomMmapAddr() { ... static const uintptr_t kAllocationRandomAddressMin = 0x0000000080000000; static const uintptr_t kAllocationRandomAddressMax = 0x000003FFFFFF0000; ... uintptr_t address; platform_random_number_generator.Pointer()->NextBytes(&address, sizeof(address)); address <<= kPageSizeBits; address += kAllocationRandomAddressMin; address &= kAllocationRandomAddressMax; return reinterpret_cast<void *>(address); }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  

サンドボックス

Chromeは、ブラウザのさまざまな部分にさまざまな特権と制限を割り当てることができるマルチプロセスアーキテクチャを実装しています。 サンドボックスが動作するユニットはプロセスです。 Chromeサンドボックスの最小構成には、 ブローカーと呼ばれる特権プロセスと、 分離された 1つ（またはそれ以上）の2つのプロセスが含まれます。 たとえば、分離プロセスのレンダリング方法-HTMLドキュメントをレンダリングするBlinkエンジンのインスタンス。 レンダラーは、Webページのタブおよびブラウザー拡張機能用に起動されます。 レンダラーを危険にさらすリスクは大きいです。なぜなら、その内部には、ユーザーがサーフィンするあらゆるソースからロードされた異種コードの解釈があるからです。 レンダラーに加えて、個別のプロセスはプラグインコンテナー（フラッシュ）であり、補助プロセスはクラッシュレポーター、グラフィックスのGPUアクセラレーターです。 レンダラーなどはIPC（プロセス間通信）を使用して、ブローカーからリソースへのアクセスを要求します。 これらのAPI呼び出しはIPCを介してブローカーに委任され、ブローカーは各分離プロセスに指定されたポリシーで委任された呼び出しをチェックし、許可された呼び出しが実行され、同じIPCメカニズムを通じて結果が返されます。

Chromeサンドボックスモデル、 ソース

Chromeプロセス分離がベースとするWindowsツール：

• アクセストークン
• ジョブオブジェクト
• デスクトップオブジェクト
• 整合性レベル
• Appcontainer
• Windows軽減ポリシー

隔離されたプロセスと特権ブローカーの間に相互作用があることを再度注目する価値があります。つまり、上記のシステムメカニズムの脆弱性だけでなく、IPCによって達成されたブローカーの脆弱性の悪用によってもサンドボックスを終了できることを意味します。 このアプローチは、モバイルPwn2Own 2013で、この記事で既に説明したRCEとともに、Pinkie Pieによって実証されました。パートIIのリンクを参照してください 。

アクセストークン

アクセストークンには、SID（アクセスサブジェクトの識別子：ユーザーとグループ）が含まれます。 分離されたプロセスに対して、NULL SID（S-1-0-0）を含むマーカーが設定されます。これに対して、取得可能なACLを持つオブジェクトがシステムで検出される可能性は低くなります。

そのようなプロセスはどのようにしてファイルへのハンドルを取得しますか？ API関数（ここでは-ZwCreateFile）に通常のフックがインストールされ、呼び出しはサンドボックスモジュールを介してブローカーにリダイレクトされ、ブローカーはファイルを開いてハンドルを複製します。

ジョブオブジェクト

ACLによって制御されないリソースに関連するいくつかの特別な制限が含まれます。 このエンティティは、子プロセスの作成、クリップボードの読み取り/書き込みなどを禁止します。 詳細

デスクトップオブジェクト

分離されたChromeプロセス用に別のデスクトップオブジェクトが作成され、ウィンドウにメッセージを送信して他のプロセスとの相互作用を防ぎます。

この相互作用がなぜ危険なのですか？ これは、Windowsアーキテクチャの古い弱点であり、いわゆる「 粉砕攻撃 。 Vistaまでのウィンドウメッセージは匿名であり、どのプロセスにも送信できました。 ターゲットプロセスが関与せずに制御を転送する関数のアドレスを含むWM_TIMERメッセージは、特に機敏な機会を与えました。

Vista以降のバージョンでは、プロセス間のメッセージ転送は、整合性レベルに基づいて制限されていました：ユーザーインターフェイス権限エスカレーション。 特権の低いプロセスは、特権のあるプロセスにメッセージを送信できなくなりました。

整合性レベル、AppContainer

Windowsアクセス制御メカニズムについては、以前の記事で説明しました 。

Windows軽減ポリシー

プロセスに対して有効にできる一連の新しいWindowsセキュリティ機能は、 EMET（Enhanced Mitigation Experience Toolkit）機能と部分的に重複しています。 ここでは、フォントのダウンロードの無効化（Windowsカーネルで解析）、プロセスへのモジュール、プロセスの作成などの機能があります。

プロセスの作成の禁止は、分離されたChromeプロセスのJobオブジェクトで既に行われていることと重複していますが、Jobオブジェクトには1つの面白いギャップがあります。 回避策は、プログラムのコンソールウィンドウを作成するAllocConsole APIを呼び出すことです。コンソールウィンドウの場合、ホストプロセスconhost.exeがシステムによって起動されます。 これらのポリシーとそれらの弱点については、 プレゼンテーションの研究者James Forshawで詳しく読むことができます。

ProcessSystemCallDisablePolicy / Win32k.sys Lockdown

このポリシーは別途検討します。

Windowsグラフィックスサブシステムは、長年にわたってLPEの脆弱性を提供してきました。 ブラウザ攻撃の場合、それらはRCEの後に使用されます。 レンダリングプロセスでコードの実行を受けたエクスプロイトは、Windowsコンポーネントの脆弱性を介して特権を昇格させ、システムへのフルアクセスを取得します。 これは、win32kのカーネルプール破損の脆弱性に対する十分に文書化されたエクスプロイトによって説明できます。これは、Pwn2Own 2013でMWR Labsの研究者がChromeのRCEと連携して実証しました。

この脆弱性は、ウィンドウ間でメッセージを転送するために使用されるコールハンドラーで発見されました： W32KAPI LRESULT NtUserMessageCall( IN HWND hwnd, IN UINT msg, IN WPARAM wParam, IN LPARAM lParam, IN ULONG_PTR xParam, IN DWORD xpfnProc, IN BOOL bAnsi);



。 最後のパラメーターbAnsiは、メッセージのテキストのエンコードを定義します。これは、サービスを呼び出したプロセスからカーネルメモリにコピーされます：WCHARまたはASCII-1文字あたり2または1バイト。 また、このパラメータは、カーネルプールにバッファを割り当てるときと、メッセージをバッファにコピーするとき（最初はブールとして、次にビットマスクとして）に解釈が異なりました。 これにより、2倍のバイト数をコピーしてバッファをオーバーフローさせることができました。 したがって、カーネル内のデータを操作することで、ring0でシェルコードの実行を達成しました。シェルコードは特権winlogon.exeプロセスのACLをリセットしました。つまり、些細なコードを挿入する前に無防備のままにしました。 利益！

Win32kの問題

この単純な一見した対策の開発は、Chrome自体のコードだけでなく、Adobe Flash PlayerおよびPdfiumの開発チームとの調整も必要であるため、多くの時間と労力がかかりました（レンダリングプロセスだけでなく、PPAPIにもロックダウンが必要です）プラグインが実行されるプロセス）。 Googleのエンジニアは、win32kを使用してブローカーをFlash通信スタックに追加しました。 現時点では、オペレーティングシステム自体がシステムコールをフィルタリングする機能を提供するため、ロックダウンの本格的な実装はWindows 10にのみ存在します 。 この救済策の問題と解決策を説明する文書に精通することを強くお勧めします。

おわりに

もちろん、Chromeの強みはサンドボックスです。 ここでは、レンダラーのコードベースの脆弱性の悪用を緩和するための特権を制限するさまざまな方法を紹介します。 これらのメソッドのセットは、オペレーティングシステムが提供するものに依存します。Windowsの新しいバージョンでは、多くの新しく興味深いものが追加されています。 さらに、動的メモリの管理にも多くの注意が払われており、これは最新のWeb用の新しいブラウザ機能を作成する際にバックグラウンドに残りますが、セキュリティの観点から最も重要です。 開発者はプログレッシブガベージコレクションシステムを導入し、通常のC ++アプリケーションでは一般的ではないブラウザーコンポーネントが実行される環境の新しいプロパティを取得しました。

著者

• トゥルチェンコフ・ドミトリー/ @dt
• バービギンイゴール/ @ igor1024