JavaScriptを使用したオペレーションヒープオーバーフロー

翻訳者から

この研究では、著者はヒープメモリオーバーフローを悪用する興味深い手法を明らかにしています。 もちろん、この脆弱性はかなり前に修正されていますが、手法自体は非常に興味深いものであり、オーバーフロープロセスは非常に詳細です。

情報セキュリティに興味があり、オーバーフローがどのように発生するかを理解したい場合は、それが現在およびその後のニュース速報に表示されるので、この調査を気に入っていただけることでしょう。

まえがき

この記事では、新しいヒープオーバーフローの悪用方法（ヒープ

オーバーフロー）JavaScriptインタープリター。 要するに、ヒープを取得するには

オーバーフローの場合、JavaScriptコマンドを使用して、バッファーオーバーフローの直後に信頼できる関数ポインターの表示を提供できます。 このチュートリアルでは、著者がCanSecWest 2008 Pwn2Ownコンテストで優勝するために使用したSafariテクニックを使用します。

はじめに

多くのバッファおよび整数オーバーフローの脆弱性により、ヒープポインタへの相対オフセットで複数の任意の値を書き込むことができます。 攻撃者にとって残念なことに、多くの場合、ポインタに続くデータは予測不能であり、操作が困難で信頼性が低くなります。 完全なヒープオーバーフローにより、攻撃者はオーバーフローしたバイトの数と値を完全に制御できるようになります。また、書き換えが面白く予測可能なものがない場合、これは実際には不可能です。



メタデータ構造の安全なリリースのおかげで、ヒープはオーバーフローの興味深い対象ではなくなりつつあります。 現在、オーバーフローデータには、通常のプログラムの実行が攻撃者のコードへのポインターで上書きされた関数ポインターにつながるようなデータが必要です。 ただし、このような操作は信頼性を保証するものではありません。 オーバーフローを成功させるには、バッファオーバーフロー後、まだ利用できないポインターがヒープ内にある必要があり、それらの間に他の重要なデータやマークされていないメモリがあってはなりません。 このような理想的な条件は、どのアプリケーションでも確かにまれです。



ただし、JavaScriptなどのクライアント側のスクリプト言語アクセスが与えられた場合、攻撃者はWebブラウザーなどのアプリケーションの脆弱性に対するこれらの理想的な条件を作成する可能性があります。 記事（Sotirov、A. Heap Feng Shui in JavaScript。Blackhat Europe 2007）で、SotirovはInternet ExplorerでJavaScriptディストリビューションを使用して攻撃者がターゲットヒープを制御する方法を説明しています。 この記事では、彼の一連の風水（ヒープ風水）に触発された新しい手法について説明します。

2テクニック

2.1コンテキスト

広義には、この方法を使用して、JavaScriptを使用するWebブラウザーに対するクライアントエクスプロイトを開発できます。 このコンテキストでは、攻撃者は（特に）JavaScriptコマンドを含むWebページを作成し、被害者にブラウザでページをロードさせます。 攻撃者は、特定のJavaScriptコマンドを使用して、攻撃の成功を組織化するために、被害者のブラウザープロセスのヒープの状態に影響を与えます。



将来、満杯のバッファは脆弱なバッファであることに留意してください。 ヒープオーバーフローを実現するには、脆弱なバッファーの配置とオーバーフローをJavaScriptインタープリターで実行する必要があります。 特に、JavaScriptインタープリターが作成される前に脆弱なバッファーが既に割り当てられている状況では、このメソッドは使用されません。



また、シェルコードが利用可能であり、それをメモリにロードするメカニズムがすでに見つかっていると想定しています。 これはJavaScriptでは簡単です。大きな行にロードするだけです。

2.2概要

目標は、脆弱なバッファの直後にヒープ上のバッファを管理することです。 これは、すべての穴が脆弱なバッファーを保持するのに十分な大きさであり、管理するバッファーに囲まれているヒープを編成することで実現します。



この手法は5つの段階で構成されています。



1.ヒープを最適化します。

2.ヒープに穴を作成します。

3.穴の周りにブロックを準備します。

4.トリガーの分離とオーバーフロー。

5.シェルコードへの移行を開始します。

これらの手順については、このセクションの残りの部分で詳しく説明します。

2.3デフラグ

プロセスヒープの状態は、プロセスの有効期間中に発生したメモリの割り当てと解放の履歴によって異なります。 そのため、連続的なマルチスレッドプロセス（Webブラウザなど）のヒープ状態は予測できません。 原則として、このようなヒープは、空きメモリに多くの空きがあるという事実によって断片化されます。 空きメモリのサイズが異なるホールが存在するということは、同じサイズのバッファの連続した分布のアドレスが信頼できる関係を持つ可能性が低いことを意味します。 図1は、断片化されたヒープ内での分布の様子を示しています。





図1.断片化されたヒープ。



しばらく使用されてきたヒープ内でこれらのホールが発生する可能性がある場所を予測することは不可能であるため、次の分布が発生する場所を予測することは不可能です。



ただし、ターゲットアプリケーションをある程度制御できる場合は、任意のサイズの多くの分布をアプリケーションに強制することができます。 特に、本質的にすべての穴を埋める多くの分布を作成できます。 穴がいっぱいになると、つまりヒープが最適化されるとすぐに、図2のように、通常、同様のサイズの分布は予測どおりに互いに近くなります。





図2.最適化されたヒープ。 将来の予算配分は連続していることが判明しました。



デフラグは常に特定のバッファサイズを指すことを強調します。 脆弱性を利用する準備として、脆弱なバッファのサイズに関してヒープを最適化する必要があります。 このバッファのサイズはさまざまですが、既知である必要があります。 図2に示すように、JavaScriptでの最適化の設定は非常に簡単です。



例：

var bigdummy = new Array(1000); for(i=0; i<1000; i++){ bigdummy[i] = new Array(size); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のコードスニペットでは、新しい配列（サイズ）を呼び出すたびに、ヒープに4 *サイズ+ 8バイトが割り当てられます。 この分布は、8バイトのヘッダーとそれに続くサイズポインターの配列で構成されるArrayStorageオブジェクトに対応します。 最初は、すべての分布がゼロにリセットされます。 サイズは、結果の分布ができるだけサイズに近く、脆弱なバッファのサイズ以上になるように選択する必要があります。 上記の値1000は経験的に決定されました。

2.4穴を開ける

私たちの目標は、脆弱なバッファーに続くバッファーを制御することです。 最適化が機能すると仮定すると、ヒープの最後に、脆弱なバッファー（まだ割り当てられていない）とほぼ同じサイズのいくつかの隣接するバッファーが必要です（図3）。





図3.多くのディストリビューションでの最適化されたヒープ 制御している同じサイズのバッファーの長い行が表示されます。



次のステップは、これらの隣接するバッファの残りすべてを解放し、脆弱なバッファのサイズに一致する代替のバッファとホールを残すことです。



これを達成するための最初のステップは、次のコードです。

 for (i=900; i<1000; i+=2){ delete(bigdummy[i]); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

forループの下限は、デフラグ段階で900回の配布が行われた後、ヒープの最後で後続のすべての配布が連続して発生するという仮定に基づいています。



残念ながら、この段階では問題があります。 JavaScriptでオブジェクトを削除するだけでは、すぐにヒープ上のオブジェクトスペースが解放されるわけではありません。 ヒープ内のスペースは、ガベージコレクションが発生するまでクリアされません。 Internet ExplorerはCollectGarbage（）メソッドを提供します。このメソッドは、ガベージコレクションをすぐに開始しますが、他のブラウザー実装はそうではありません。 特に、WebKitはサポートしていません。 そのため、WebKitでのガベージコレクションの説明に移ります。



WebKitソースコードのレビューでは、ガベージコレクションをトリガーできる主なイベントが3つあることが示されました。 これらのイベントを理解するには、WebKitのJavaScriptコードがオブジェクトを操作する方法に精通している必要があります。



実装は、primaryHeapとnumberHeapの2つの構造をサポートします。各構造は、CollectorBlockオブジェクトへのポインターの配列です。 CollectorBlockは固定サイズのセルの配列であり、各セルにはJSCellオブジェクト（または派生）を含めることができます。 各JavaScriptオブジェクトは、これらのヒープのいずれかのセルを占有します。 ラージオブジェクト（配列や文字列など）は、システムヒープの追加メモリを占有します。 この追加のシステムメモリをリンクストレージと呼びます。



各CollectorBlockは、フリーセルのリンクリストを保持します。 選択が要求され、既存のCollectorBlocksに空きセルがない場合、新しいCollectorBlockが割り当てられます。



JSObjectから取得したすべてのJavaScriptオブジェクトは、primaryHeapに割り当てられます。 numberHeapは、NumberImpオブジェクト用に予約されています。 後者はJavaScriptのNumberオブジェクトに対応していませんが、原則として、それらは中間算術計算に対応する短絡オブジェクトです。



ガベージコレクションが開始されると、両方のヒープの参照がゼロのオブジェクトがチェックされ、そのようなオブジェクト（および関連するストレージがある場合）が解放されます。



ガベージコレクションをトリガーする3つのイベントに戻ります。



1.専用のガベージコレクションタイマーの有効期限。

2.ヒープの個々のCollectorBlockがすべていっぱいになったときに発生する配布要求。

3.十分に大きい関連リポジトリーを持つオブジェクト（またはいくつかのそのようなオブジェクト）を選択します。



これらのイベントの最初はあまり有用ではありません、なぜなら JavaScriptにはスタンバイモードがありません。また、スクリプトの顕著な遅延により、[遅いスクリプト]ダイアログボックスが表示される場合があります。



これらのイベントの最後は、primaryHeap内のオブジェクトの数と、関連するストレージのサイズに依存します。 実験では、primaryHeapの状態は、ブラウザーで開いているWebページの数と、これらのページがJavaScriptを使用する程度に応じて大きく異なることが示されています。 したがって、このイベントでガベージコレクションを確実に開始することは困難です。



一方、numberHeapはこれらの変更に対して比較的鈍感なようです。 調査によると、numberHeapは、JavaScriptを使用した重要なページビューでも、1つの専用CollectorBlockのみをサポートしています。 numberHeap CollectorBlockには4062個のセルがあるため、多数のNumberImpを作成するJavaScriptコード（中間計算を使用して多数の算術演算を実行）がガベージコレクションを開始する必要があります。 例として、doubleの操作はnumberHeapからNumberImpの割り当てにつながる操作であるため、次のJavaScriptコードを使用してガベージコレクションを開始できます。

 for (i=0; i<4100; i++) { a = .5; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードを完了すると、ヒープは図4のようになり、次のステップの準備が整います。





図4.すべてのバッファーが解放された管理ヒープ 脆弱なバッファの割り当ては、穴の1つで終了します。

2.5ブロックの準備。

この手順は簡単です。 次のJavaScriptを使用します。

 for (i=901; i<1000; i+=2) { bigdummy[i][0] = new Number(i); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードbigdummy [i] [0] = new Number（i）は、新しいNumberInstanceオブジェクトを作成し、bigdummy [i]に対応するArrayStorageオブジェクトにこのオブジェクトへのポインターを格納します。 図5は、JavaScriptを実行した後のヒープの一部を示しています。





図5.オーバーフローが始まる直前の攻撃者が制御するブロックの詳細。

2.6。 再配布とオーバーフローを開始します。

ここで、脆弱なバッファを割り当てます。 前の手順が正常に終了した場合、脆弱なバッファの配布は作成した穴の1つにあり、オーバーフローの準備ができています。 オーバーフローオブジェクトは、脆弱なバッファーに続くArrayStorageオブジェクトのpNIポインターを上書きすることです。 新しい値は、シェルコードのスレッドのアドレスである必要があります。 スレッドの詳細については後述しますが、現時点では、典型的なスレッドNOP（https://en.wikipedia.org/wiki/NOP_slide）はここでは適切ではないことに注意してください。 強調表示してオーバーフローすると、ヒープは図6のようになります。





図6.オーバーフローが開始された直後に攻撃者によって制御されるブロックに関する情報。

2.7シェルコードへの移行の開始

シェルコードへの移行は、上記のブロックの準備中に作成されたNumberオブジェクトとの単純な対話によって実行されます。 具体的には、JavaScript実装の基になるNumberInstanceオブジェクトの仮想メソッドを強制的に呼び出す必要があります。 上書きされていないブロックの場合、実行は*（（* pNI）+ 4 * k）に転送されます。kは、呼び出される仮想関数テーブル内のメソッドのインデックスです。 脆弱なバッファの直後に続くブロックの場合、実行は*（（* pSled）+ 4 * k）に転送されます。 このpSledの二重逆参照は少し面倒ですが、以下のケーススタディはそれに対処する簡単な方法を示しています。



次のJavaScriptは、NumberInstanceオブジェクトごとに仮想関数呼び出しを行い、シェルコードの実行を開始します。

 for (i=901; i<1000; i+=2) { document.write(bigdummy[i][0] + "<br />"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3.ケーススタディ

JavaScriptの束を使用した信頼できる作業の分野での私たちの研究は、PCRE（Perl-Compatible Regular Expression）WebKitの分析で見つかった脆弱性に動機付けられました。 これは整数オーバーフローであり、コンパイルされた正規表現を含むバッファーの背後で任意のオーバーフローサイズを許可しました。最大サイズは65535バイトです。 ただし、バッファが割り当てられた直後にオーバーフローが発生したため、オーバーフロー中に未割り当てメモリに遭遇することがよくありました。 他のケースでは、重要なデータを書き直しましたが、実行間でどのデータが変更されたかはまったく予測不可能でした。 セクション2で説明した機器はこれらの問題を解決し、信頼性の高い動作を保証しました。



最初に、約4000バイトのターゲットサイズのヒープを最適化する必要がありました。 次のデバッガー出力は、最初のいくつかのディストリビューションを使用してヒープを最適化する方法を示しています（ディストリビューションアドレスの周りのジャンプに注意してください）。



Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$1 = 0x16278c78

Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$2 = 0x50d000

Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$3 = 0x510000

Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$4 = 0x16155000

Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$5 = 0x1647b000

Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$6 = 0x1650f000

Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$7 = 0x5ac000









ほぼ1000の配布が完了するまでに、ヒープはかなり予測可能に見え始め、すべての配布は最終的に連続します。



Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$997 = 0x17164000

Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$998 = 0x17165000

Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$999 = 0x17166000

Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$1000 = 0x17167000

Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$1001 = 0x17168000

Breakpoint 3, 0x95850389 in KJS::ArrayInstance::ArrayInstance () array buffer at$1002 = 0x17169000









セクション2.4で説明したガベージコレクション手法を使用して、最後に多数のホールを解放すると、0x17168000で制御するデータの直前の0x17168000の最後のホールで脆弱なバッファーがドロップアウトすることがわかります。



Breakpoint 2, 0x95846748 in jsRegExpCompile () regex buffer at$1004 = 0x17168000









したがって、正規表現バッファーをArrayStorageデータにオーバーフローさせます。 オーバーフローバイトは、正規表現バイトにコンパイルする必要があります。 幸いなことに、正規表現文字クラスの構築により、33バイトにコンパイルされるため、コンパイルされた形式でほぼ任意のバイトが許可されます。最後の32バイトは256ビットビットの配列です。 。 したがって、文字クラス[\ x00 \ x59 \ x5c \ x5e]を使用し、ArrayStorageデータの先頭に配置します。これは、コンパイルされたビットクラスの最初の3ワードが非ゼロdword、ゼロdword、およびヒープ内のアドレス、つまり：



0x00000001 0x00000000 0x52000000







最後に、ヒープ上で特別に細工されたアドレスを使用し、大きなdword文字列0x52780278を使用して、その後にシェルコードを続けます。 このアドレスが必要な範囲内になるように、スプレーの配布を手配します。 次に、実行開始後に命令として解釈されると、条件付きジャンプになります。

 78 02: js +0x2 78 52: js +0x52
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

遷移条件の値に関係なく有効なNOPです。条件が真の場合、次のコマンドの先頭に2のジャンプが行われます。条件が偽の場合、0x52のジャンプについても真ではありません。 これは、ヒープスプレーアドレスを決定する際の最も重要なバイトがスレッドで完全に使用されておらず、4バイトでアライメントされていることを意味します。

4.結論

この記事で説明した手法により、バッファオーバーフローの信頼性の高い動作を確保することができました。最初は、書き換えのための予測可能な興味深いデータがありませんでした。 攻撃者が配信サイズ、オーバーフローサイズ、オーバーフローデータなど、システムを制御する必要がある限り、攻撃者がJavaScriptにアクセスできる場合、このメソッドを他のブラウザーの脆弱性に適用する必要があります。 他のクライアント側スクリプト言語を使用する場合、同様の方法が適用される可能性があると思われます。