Micro0トレンドマイクロは、macOSで同一領域のメモリが二重に解放される「ダブルフリー」の脆弱性を発見しました。CVE-2019-8635」が割り当てられています。CVE-2019-8635は、AMD製GPU「Radeon」のコンポーネントにおけるメモリ破壊に起因します。攻撃者がこの脆弱性の利用に成功すると、権限を昇格し、ルート権限で不正なコードを実行可能です。弊社の情報公開を受けAppleは修正プログラムを公開しました。CVE-2019-8635には、「discard_StretchTex2Tex」関数および「AMDRadeonX400_AMDSIGLContext」クラスにおけるサイドバンドトークンの処理のそれぞれに存在する2つの欠陥が含まれます。「AMDRadeonX400_AMDSIGLContext」クラスは「IOAccelContext2」クラスを拡張した「IOAccelGLContext2」クラスから派生したクラスで、グラフィックの描画に使用されます。問題の脆弱性に起因するメモリの二重解放は、「AMDRadeonX4000_AMDSIGLContext」クラスの「discard_StretchTex2Tex」関数および「AMDSIGLContext::process_StretchTex2Tex」関数で発生します。2」関数である「IOAccelContext2::submit_data_buffers」を使用することでアクセス可能です。「AMDRadeonX4000_AMDGraphicsAccelerator」のクライアントは接続タイプ「1」で開くことが可能です。「AMDRadeonX4000_AMDSIGLContext」クラスの「discard_StretchTex2Tex」関数のダブルフリーを利用した権限昇格脆弱性この脆弱性を利用することにより、ローカルの攻撃者はユーザスペースでコードを実行することを可能にします。前提条件として、攻撃者は低い権限でのコード実行が可能である必要があります。この脆弱性は、ユーザが提供したデータに対して適切なバリデーションがなされていないことに起因します。その結果、割り当てられたデータ構造の終端を越えた領域の読み取りが発生します。攻撃者は、その他の脆弱性とともにこれを利用することで、権限をカーネルレベルに昇格することが可能です。「AMDRadeonX4000_AMDSIGLContext」クラスにおけるダブルフリーを利用した権限昇格脆弱性ダブルフリーの脆弱性は、同じ「AMDRadeonX4000_AMDSIGLContext」クラスにおけるサイドバンドトークンの処理にも存在します。これにより、ローカルの攻撃者は、影響を受けるバージョンのmacOSで任意のコードを実行することが可能になります。上述の欠陥と同様に、攻撃者は低い権限でのコード実行が可能である必要があります。前述したダブルフリーは「AMDRadeonX4000_AMDSIGLContext::discard_StretchTex2Tex」関数で発生しますが、こちらは「AMDRadeonX4000_AMDSIGLContext::process_StretchTex2Tex」関数で発生します。この脆弱性は、オブジェクトを操作する前にその存在を確認するバリデーションがなされていないことに起因します。この脆弱性を利用することで、攻撃者は権限をカーネルレベルに昇格することが可能です。脆弱性攻撃の潜在的な可能性という点においてこれら2つの脆弱性は類似しており、その違いは利用する関数にあります。図1は「AMDRadeonX4000_AMDSIGLContext::discard_StretchTex2Tex」関数の疑似コードです。「cmdinfo+32」が0x8c00(10進数で35840)に等しい場合、この関数は「IOAccelResource」である「v10」および「v11」を、それぞれ「*(shareMem_start_address_187_offset16+8)」と「*(shareMem_start_address_187_offset16+12)」の値をインデックスとして「IOAccelShared2」から取得します。次にこの関数は、2つのアクセレレータリソースを「IOAccelResource2::clientRelease()」を使用して解放します。これら2つのインデックスは、「IOAccelContext2」のユーザクライアントを使用し、ユーザスペースからマップメモリを通して直接操作することが可能です。ここで、ユーザスペースが「lookupResource」関数のインデックスと同じ領域をマッピングしている場合、「clientRelease」関数は同じリソースクライアントを2度解放することになります。これによりダブルフリーが発生します。図1:「AMDRadeonX4000_AMDSIGLContext::discard_StretchTex2Tex」関数の疑似コード図2は「AMDRadeonX4000_AMDSIGLContext::process_StretchTex2Tex」関数の疑似コードです。「v15」が0x8c00(10進数で35840)に等しいとき、この関数は「accelResource_offset8」と「accelResource_offset12」を、それぞれ共有メモリのオフセット24および28の値をインデックスとして「IOAccelShared2」から取得します。最終的に、この関数は「IOAccelShared2」から「accelResource_offset12」を解放します。「accelResource_offset8->member2」が10と等しくない場合、「IOAccelShared2」から「accelResource_offset8」を解放します。共有メモリのオフセット24および28を同じ値に設定すると、同一の「accelResource」を2回解放することになります。「process_StretchTex2Tex()」関数がストレッチ操作を完了する際、「IOAccelResource2::clientRelease()」関数が2つのリソースクライアントを解放します。これら2つの「accelResource2」は、それぞれのインデックスと共に「IOAccelShared2::lookupResource」関数を使用して「AMDRadeonX4000_AMDSIGLContext」クラス内の「accelShare2」の共有メモリから取得されます。これらのインデックスは「IOAccelContext2」のユーザクライアントがメモリをマッピングすることでユーザスペースから操作可能です。ユーザスペースが「lookupResource」関数のためのインデックスと同一のインデックスをマッピングした場合、「clientRelease」は同じリソースクライアントを2回解放し、ダブルフリーが発生します。図2:「AMDRadeonX4000_AMDSIGLContext::process_StretchTex2Tex」関数の疑似コード図1および図2に示した疑似コードにおいて、共有メモリのアドレスは「commandStreamInfo」のオフセット24の位置を指しています。図3のように、この「commandStreamInfo」のバッファは実際「IOAccelContext2::processSidebandBuffer」関数でセットされており、変数「v5」は共有メモリのオフセット16の位置を、したがって「this->member196」は「commandStreamInfo」のオフセット24の位置を指しています。図3:「IOAccelContext2::processSidebandBuffer」の疑似コード図4は「IOAccelContext2::clientMemoryForType」関数の疑似コードです。この関数はユーザスペースのバッファをカーネルスペースにマッピングする関数「IOConnectMapMemory64」によって呼び出されます。この関数を使用する際は、パラメータとして「connect」オブジェクト、メモリタイプ、およびその他の引数を与える必要があります。図4では、「connect」オブジェクトは「IOAccelContext2」のインスタンス、メモリタイプは「0」です。メモリタイプに「0」を指定すると、「clientMemoryForType」関数はバッファメモリのディスクリプタを作成し、ユーザスペースに開始アドレスを返します。続いて、この関数はバッファメモリアドレスを変数「shareMem_start_vm_address_187」にセットします。この変数名は便宜的に命名したものです。これがまさに「IOAccelContext2::processSidebandBuffer」関数で使用される値です。ここで、この共有バッファと2つのインデックスは操作可能なため、ダブルフリーを引き起こすことができます。図4:「IOAccelContext2::clientMemoryForType」関数の疑似コード以下は、アプリケーションのクラッシュログに含まれるバックトレース情報です。2893」だけが異なります。22カーネルによって検出されたシステムエラー「カーネルパニック」が発生すると、パニックテキストがログに追加されます。ユーザスペースのコードによって検出される類似したエラーとは異なり、カーネルパニックは、カーネルコードでハンドルされていないプロセッサの例外に起因します。これには例えば無効なメモリアドレスへのアクセスや呼び出しチェーンのバグのようなものが含まれます。問題のパニックログは以下の通りです。0以下はカーネルパニック発生時のレジスタのデバッグ情報です。レジスタ「$r12」は共有メモリアドレスのオフセット16の位置を指しています。リソースのインデックスは両方とも0x42になっています。攻撃者は修正プログラムが適用されていないmacOSを攻撃し、権限を昇格してシステムを侵害するためにダブルフリー脆弱性を利用することが可能です。Appleはすでにこのメモリ破壊の問題に対処するために、メモリの取り扱いを改善した修正プログラムを公開しています。10.14.4のためのセキュリティ更新プログラムが利用可能です。ユーザは速やかに更新プログラムを適用してください。Protection」ソリューションを利用可能です。posts:Apple、脆弱性「CVE-2017-13811」のセキュリティアップデートを公開。