Clever Geek Handbook

ブラウザーとアプリ固有のセキュリティの緩和。 パート1



この記事は、Webブラウザーのメモリ破損の脆弱性の悪用に対処するために設計されたセキュリティメカニズムに関する短いシリーズの紹介です。 このサイクルの一部として、ブラウザー開発者が実装するメカニズムと目的を検討し、それらをどのように回避できるか、または回避できるかについて説明します。



アプリケーション保護のトピック、またはエクスプロイト開発者が保護を克服する方法に興味がある場合は、catへようこそ。



セキュリティの緩和



どういうわけか、私たちはすでにブログ「On Flags 0x41414141 Times」で同様のトピックを取り上げました。

同様のメカニズムは、動作または適用されるレベルに応じてカテゴリに分類できます。



  1. ハードウェアレベル-（DEP、MPX、CFI、SMEP、SMAP、UMIPなど）。
  2. オペレーティングシステムレベル-OSの作成者によって実装されます。 たとえば、SEHOP、ForceASLR。 Linuxの場合、追加のパッチ（Grsecurity）として実装できます。
  3. コンパイラ/リンカーレベル-スタックCookie、SafeSEH。
  4. アプリケーションレベルで：



    • サードパーティ-EMET、Malwarebytes Anti-Exploit、HitmanPro、PaX、およびさまざまなアンチウイルスの同様の実装。
    • 埋め込み-アプリケーションのソースコードに直接実装されます。


公平を期すために、この区分は条件付きであり、必ずしもそれほどカテゴリー的ではないことに注意する価値があります。 たとえば、WindowsのCFG（Control Flow Guard）では、OSがこのメカニズムをサポートする必要があり、アプリケーション自体は特別なフラグで構築されています。 少なくとも1つの条件が満たされていない場合、CFGはタスクを実行しません。



メカニズムは、特定の問題を解決することも目的としています。



  1. 複雑（テクニックの安定性を低下させる）
  2. 特定の手法の作業を不可能にするため（特定の手法に対する反作用）
  3. 軽減（システムの他の部分からの隔離、サンドボックス）


この記事ではこのようなメカニズムの出現の歴史には触れず、プレゼンテーションを読むことをお勧めします。





アプリ固有のセキュリティ緩和策



この一連の記事は、最後のカテゴリ、いわゆる アプリ固有のセキュリティの緩和。 これらのメカニズムの外観は、アプリケーションの機能とその実装の機能によるものであり、原則として、メモリ操作の独自の抽象化に影響または実装します：独自のVM、独自のヒープマネージャ、独自のスクリプト言語など。



最も著名な代表者を呼び出すことができます：





そのため、たとえば、最新のオペレーティングシステムのレベルでは、同じヒープを保護するメカニズムが既にありますが、開発者が内部実装を作成するという事実により、OSからヒープを保護するメカニズムは、概してプログラム自体の機能に関与していません。 内部実装は、内部構造、オブジェクト間の接続、攻撃者が目指しているアルゴリズムを生成します。 当然、これらはすべて利便性、シンプルさ、速度のために最初に作成されましたが、実践が示すように、その後、セキュリティを確保するために設計されたさまざまな追加メカニズムを取得し始めます。 さて、このようなソリューションの機能についても忘れてはなりません。これは、導入されたセキュリティメカニズムにも特別な痕跡があるからです。



ブラウザ



ブラウザーは、メモリ破損の脆弱性の悪用に対する独自のセキュリティメカニズムを実装する最も明るい（そしておそらく最も興味深い）ソフトウェア担当者であるため、研究センターでそれらに焦点を合わせることにしました。 一連の記事は、x86 / x64アーキテクチャでWindows OSを実行しているデスクトップコンピューター用のIE + Edge、Chrome、Firefoxに当てられます。 これらのメカニズムのリストは、更新されたコレクション「メモリ破損の脆弱性に対するブラウザのセキュリティの緩和」から取ったものです。友人のArthur Gerkisに感謝します。



2011年にAccuvant LABSはBrowser Security Comparison：A Quantitative Approachをリリースしましたが、それ以来多くの水が漏れ、ブラウザーは劇的に変化しました。 ただし、この情報に精通することはまだ場違いではありません。



将来的に検討されるメカニズムを一般化すると、いくつかのグループを特定できます。





ブラウザやAdobe Flashを含む広範なクライアントソフトウェアの悪用は、一連の脆弱性、テクニック、アプローチです。 pwn2own 2016でそれらがどのように壊れたかの小さな選択を見てください：







成功したブラウザーのエクスプロイトについて詳しく知りたい場合は、BlackHat LasVegas 2016での「地球上の$地獄：ブラウザーからシステムへの妥協」（ プレゼンテーションとホワイトペーパー ）のパフォーマンスに注意することをお勧めします。



ご覧のとおり、このような「装甲」プログラムでさえ、OSとその両方のすべての保護メカニズムをバイパスして攻撃に成功しています。 その結果、研究者は多数のセキュリティメカニズムをバイパスします。もちろん、実際には、使用する脆弱性のタイプに大きく依存するため、実際にはそれよりも少なくなります。 たとえば、SafeSEH、SEHOPを使用したスタックCookieメカニズムは、UaFの脆弱性が脆弱性の性質がスタックにまったく関係なく、これらのメカニズムが関与しないためである場合、バイパスされません。 ブラウザーに対する最大の脅威は、解放後使用（UaF）の脆弱性（ CWE-416 ）です。すべてはブラウザーの複雑さに依存します。 したがって、開発者がこのタイプの脆弱性に対抗することを目的とした保護メカニズムの作成に取り組んでいることは驚くことではありません。 （セキュリティの観点から）ブラウザーの作成者にも細心の注意を払う次のポイントは、JIT（ジャストインタイム）コードを書くことです。 これは、攻撃者がそのようなコードを使用してシェルコードをJITスプレー内に配置できるため、同時にDEPとASLRの両方をバイパスできるためです。 したがって、開発者はこの方向で「ナットを締める」ようになりました。 これについては後で説明します。



攻撃者は特定の目標を持っていることを理解することが重要です。 そのため、たとえば、彼は常に自分のシェルコードを実行してシステム内の足場を取得し、他のアプリケーションからデータにアクセスする必要はありません。 これが不要な場合は、CFGとサンドボックスをバイパスする必要はありません。 同時に、彼はブラウザによって利用可能/保存されたデータを盗むか、独自の標準機能を使用することができますが、自分の目的（データの置換やブラウザの設定の変更など）のためです。



RWプリミティブ



攻撃者がRWプリミティブ（メモリへの読み書きを可能にする脆弱性または一連の脆弱性）を持っている場合、現在の保護メカニズムはすべてバイパスされるという事実が徐々に現れてきます。



ほとんどの場合、これは次のおかげで実現されます。





メモリリークのおかげで、必要なものをメモリ内で見つけることでメモリのランダム化（ASLR）をバイパスできます。また、何でも、どこにでも自分で尋ねる必要がある場合はどこでも書き込めます。 。 場合によっては、目的のアドレス、シェルコードが置かれている場所、メモリ内のフラグ（チェックをバイパスする）、トークンの値（システムで特権を上げるため）などがあります。



「どこに書き込む」プリミティブは時々制限されることに注意してください。





しかし、そのような制限があっても、成功した操作を実行できる場合があります。すべては、アプリケーションと脆弱性の性質に依存します。これは、Internet ExplorerのBlackHat USA 2014のプレゼンテーション「Write Once、Pwn Anywhere」で非常によく示されています



RWプリミティブのパワーを理解するために、いくつかの例を示します。





この小さな選択では、メモリ破損の脆弱性を悪用する一般的で非常に強力なプリミティブを1つ示したいと考えていました。 どのブラウザでも動作しますが、RWプリミティブを見つけるのはそれほど簡単ではありません。



一連の記事では、ブラウザーメカニズムをバイパスするためのより具体的な手法を検討します。



中間結論



メモリ破損クラスの脆弱性は、現在も現在も今後も悪用され続けています。 時間の経過とともに唯一のものは、すべてがより複雑になることです。 そして、多くは脆弱性の性質に依存します。 コンパイラ、OSに期待しますが、悪者にならないでください。



PSメモリの破損は攻撃者にとっては良いことであり、論理的な脆弱性は素晴らしく、UXSSのようなWebバグでさえ常に100％の信頼性があり、多くの場合クロスプラットフォームです。


More articles:


All Articles