Translated message

A translation of this page exists in English.

DRAM 関連の障害 (Rowhammer、SPOILER、RAMBleed、Blacksmith、Half-Double を含む TRRespass)

更新 -

ダイナミックランダムアクセスメモリー (DRAM) は、コンピューターシステム内に低遅延ランダムアクセスデータストレージの大部分を提供します。これは、マザーボードに固定されたハードウェアチップの形式をとります。DRAM チップは、通常は 2 次元アレイとして配置された数百万のメモリーセルを保持します。メモリーセルはコンデンサとトランジスタで設定されています。コンデンサは電荷を保持しますが、トランジスタはその電荷の伝達を助けます。各メモリーセルは、その電荷によって示される 1 ビットの情報を保持できます。正の電荷は値 1 を示し、負の電荷は値 0 を示します。行内のメモリーセルは、行のワード線をアクティブにすることによってアクセスされます。メモリーの同じ行が繰り返しアクセスされる場合、そのワードラインはそのたびにアクティブ化および非アクティブ化されます。このようにワード線のアクティブ化と非アクティブ化が繰り返されると、DRAM 障害が発生する可能性があります。

DRAM 障害とは何ですか?

DRAM 関連の障害は、次のように大まかに分類できます。

  1. 間違ったアドレスからデータが読み取られます。
  2. データが間違ったアドレスに書き込まれます。
  3. データの読み取り中にデータが破損します (つまり、間違ったデータが返されますが、メモリー内のデータは変更されません)。
  4. データは書き込み中に破損します (つまり、データは正しいアドレスに書き込まれますが、間違ったビットが格納されます)。
  5. データは、そのメモリーアドレスに書き込むことなく、自然に破損します。

DRAM の動的部分は、自然発生的な破損を避けるために定期的なリフレッシュが必要であるという事実を指します (上記のリストの項目 5)。システムはこの更新をバックグラウンドで自動的に実行します。リフレッシュ操作にはエネルギーが必要で、リフレッシュ中のメモリー領域へのアクセスがブロックされるため、リフレッシュを最小限に抑える動機が生じます。

システムには、DRAM 障害に対するさまざまなレベルの保護が備わっています。ハードウェア設計中に、シミュレーションを使用して、リフレッシュ操作がデータ破損を防ぐのに十分であること、およびメモリーバスが転送中のアドレスとデータを破損しないことを確認します (リストの項目 1 ~ 4)。現在のコンシューマー向けシステムは、冗長性がなく、適切に設計されたメモリーのリフレッシュのみに依存しているため、保存されたデータは通常まったく保護されていません。多くのサーバーシステムでは、エラー訂正コード (ECC) を備えた DRAM が使用されており、自然発生的な破損に対する回復力が大幅に向上しています。一部のサーバーシステムにはさらに保護機能があります。

DRAM 障害はどのようにして引き起こされるのでしょうか?

DRAM 障害は、他のハードウェア障害と同様に、自然発生的に発生する可能性があります。DRAM モジュールに欠陥がある場合、または仕様外で動作する電源の欠陥など、その他のハードウェア欠陥がある場合、DRAM 障害が非常に顕著な速度で発生し、システムの安定性に影響を与える可能性があります。

特定のメモリーアクセスパターンでは、欠陥のある DRAM モジュールが露呈する可能性が高いことが長い間知られていました。Red Hat Enterprise Linux の一部として提供される memtest86+ RAM テスターは、このようなテストパターンを使用して、メモリーサブシステムのハードウェア欠陥を明らかにします。

ローハンマー攻撃はどのように機能しますか?

Rowhammer は、 CPU 命令の CLFLUSH、CLFLUSHOPT、および CLWB ファミリーを使用した DRAM ストレスのための特定のテクニックを指します。この命令ファミリーは、i386 および x86_64 アーキテクチャーによって提供される非特権命令です。これらを悪用すると、特定の場所への DRAM トラフィックが増加する可能性があります。これは、DRAM 障害誘発要因を作成する場合に特に興味深いものになります。CLFLUSH 命令には特別な権限が必要ないため、これらのプログラムはハイパーバイザーゲストで通常のプロセスとして実行できます。

Rowhammer によって引き起こされる破損の種類は、最初のリストの項目 5 に対応します。保存されたデータは、明示的なメモリーへの書き込みを行わずに変更されますが、必ずしもアクセスされているアドレスにあるとは限りません。これは、アクセスパターンが、必要な DRAM リフレッシュレートに関する設計上の想定を無効にするために発生します。つまり、この方法で DRAM にアクセスすると、メモリーリフレッシュは格納されたデータを確実に保存できるほど頻繁には行われません。

CLFLUSH 命令は、さまざまなシステムでは困難な、特に効果的なメモリーストレッサーを提供します。CPU は、キャッシュをバイパスできる他の手段 (非一時的なメモリーアクセスなど) も提供します。特に賢いストレステスターは、メモリーアクセスを慎重に選択することで、非常に似た効果を達成する可能性があります。必要に応じてキャッシュラインを削除します。

鍛冶屋 (CVE-2021-42114)

Blacksmith は TRRespass ファミリーの攻撃を拡張したもので、より複雑なパターンを使用して同じ種類のビット反転を誘発します。発表された調査 によると、DRAM のさまざまなモデル (DDR4 など) のハードウェア緩和策をバイパスする能力が高くなります。

TRRespass (CVE-2020-10255)

このようなメモリーストレス要因を軽減するために、システムベンダーはターゲット行リフレッシュ (TRR) メカニズムを DRAM に組み込みました。TRR は基本的に、対象となるメモリー行をリフレッシュしてビットフリップを誘発し、ロウハンマー効果による自然発生的なセル破損を回避します。

この分野の最新の研究によると、公開されている TRR メカニズムは単一の緩和策ではなく、すべての DRAM または Rowhammer 亜種を修正するものではありません。前記 TRR 保護メカニズムは、メモリーコントローラーユニット (MMU) 内または DRAM チップ内に実装され得る。調査によると、最新の DDR4 DRAM チップを搭載した多くの新しいマシンでは、TRR メカニズムが存在しないか、デフォルトで有効になっていません。サーバークラスのマシンではデフォルトで TRR が有効になっていますが、小売コンシューマーマシンでは TRR が有効になっていない場合があります。また、この緩和策はメモリーアドレス空間全体をカバーしているわけではないようです。そのように制限される可能性があります。

TRR 保護メカニズムは依然として非常に不透明であり、多数の Rowhammer 亜種から DRAM をどのように保護するかに関する文書はありません。TRR に関するこの不透明さを克服するために、TRRespass ツールが構築されています。多面型の Rowhammer ファザーです。これは、自然発生的なビット破損を引き起こす可能性のあるメモリーアクセスの新しいパターンを見つけるのに役立ちます。

ネタバレ: ローハンマー攻撃とどのような関係があるのでしょうか?

SPOILER の脆弱性はマイクロアーキテクチャーの漏洩であり、攻撃者が特権のないユーザー空間プロセスで仮想ページから物理ページへのマッピングを決定できるようになります。これは、メモリー順序バッファーでの投機的なロードおよびストア操作のデータ依存関係を利用し、rdtscp 命令と mfence 命令を使用して、メモリーレイアウトを明らかにするタイミングの不一致を測定します。これにより、連続した物理メモリーページの範囲を検出できるようになり、Rowhammer がより効果的かつ簡単になります。数週間ではなく、わずか数秒の攻撃です。

SPOILER 脆弱性は Intel CPU に固有であり、第 1 世代の Intel Core プロセッサーから発生します。この脆弱性は、Spectre の脆弱性とは異なります。これは、Web ブラウザーで実行される悪意のある JavaScript コード、またはシステム上で実行される信頼できないコードによって悪用される可能性があります。

ランブリード

RAMBleed CVE-2019-0174 という脆弱性が、現代の業界全体の DRAM メモリー実装で発見されました。この脆弱性により、特権のない攻撃者が Rowhammer ビット反転効果を利用して、他のプロセスに属する特定のメモリーを読み出すことが可能になります。そうしないと、読み取られたデータにアクセスできなくなり、機密情報が含まれる可能性があります。RAMBleed は、Rowhammer によるビット反転により、攻撃者が他のプロセスに属するメモリー内のビットの値を推測できるため、サイドチャネル読み取りの脆弱性です。ハンマーリングが実行される慎重に構築された攻撃者ページで被害者のデータページを囲むと、攻撃者が制御するページの 1 つでデータ依存のビット反転が誘発され、データが再構築される可能性があります。

以前の Rowhammer 攻撃とは異なり、RAMBleed では huge Page や hugeTLB を使用する必要はありません。概念実証コードは、毎秒約 3 ~ 4 ビットの速度でメモリーを読み取ることができます。この攻撃はアーキテクチャー固有のものではなく、Rowhammer に対して脆弱な DRAM メモリー実装のすべてではないにせよ、多くが RAMBleed に対して脆弱です。

Rowhammer に対して一般的に提案されているハードウェアベースの軽減策がいくつかあり、RAMBleed も軽減できる可能性があります。これらは、ターゲット行リフレッシュ (TRR)、DRAM リフレッシュ間隔の増加 (DRAM リフレッシュレートの 2 倍)、および ECC メモリーの使用です。これらの戦略が実際に問題を軽減できる程度はさまざまであり、ハードウェアプラットフォームによって異なります。ベンダーは、プラットフォーム固有の適切なガイダンスを提供することが期待されています。

ECC メモリーの普及により複雑さが増したため、現在まで、この攻撃はサーバープラットフォームでは実証されていません。ただし、研究者らは、ECC メモリーが存在する場合でも永続的なフリップを作成して ECC を回避し、サーバーに対して攻撃を実行し、おそらく VM 全体に対して攻撃を実行することが理論的には可能であることを文書化しました。ECC メモリーは Rowhammering プロセスを複雑にしますが、Rowhammer を防止するものではなく、したがって RAMBleed も防止しません。

ハーフダブル

行ハンマー攻撃は、ターゲットビットに隣接する DRAM 行にアクセスすることによって、攻撃されているセルに隣接する 1 行の距離にあるシステムを攻撃していました。ハーフダブル攻撃は、この攻撃が隣接セルのすぐ隣にない行へのアクセスに基づいてターゲットセルに影響を与える可能性があることを証明しました。これにより、攻撃者はターゲット攻撃で追加の行を使用し、既存のハードウェア緩和策を無効にすることができます。このハーフダブル攻撃はシリコンの物理的特性を悪用しており、メモリーチップの密度が増加するにつれてより実行可能になります。

JEDEC は、DRAM とハーフダブル攻撃 (JEP 300-1 および JEP301-1) に対するシステムレベルの軽減技術に関する 2 つの文書を公開しました。

DRAM 障害の影響は何ですか?

メモリーは基本的なシステムコンポーネントです。すべてはその正しい動作にかかっています。したがって、ほとんどの DRAM 障害は、システムの正しい動作を損なう可能性があります。これには、セキュリティー境界の強制と、秘密鍵マテリアルなどの重要なデータの保護が含まれます。

このような障害が発生すると、ローカルとリモートの両方の攻撃者がその恩恵を受ける可能性があります。いつものように、ローカルの攻撃者は、DRAM 障害を明示的にトリガーするのに有利な立場にあります。

サンドボックスソリューションは影響を受けますか?

Java および JavaScript サンドボックスでは、CLFLUSH 命令へのアクセスが提供されないため、この特定の DRAM ストレス処理のバリアントは機能しません。ただし、両方の言語の現在のバージョンでは十分に柔軟なデータ構造が提供されているため、他の手段で DRAM 障害を引き起こす可能性があります。

SELinux とコンテナーは、実行前に命令ストリーム全体をインターセプトしないため保護を提供せず、CLFLUSH などの命令をブロックできません。

ハイパーバイザーについてはどうですか?

RHEV などのハイパーバイザーは、現在、DRAM 障害やゲストによる乱用に対する保護を提供していません。

Chrome ブラウザーはユーザーを保護できますか?

  • -> https://nvd.nist.gov/vuln/detail/CVE-2015-0565

Google は、Chrome ブラウザー、特にネイティブクライアント機能の DRAM フォールトインジェクションに関連する脆弱性に対処したと公に主張しています。

Chrome のネイティブクライアントコンポーネントは、信頼できるコンパイラーアプローチを使用して、信頼できないソースからダウンロードされたネイティブマシンコードを実行します。命令ストリームはスキャンされ、サンドボックスからの脱出を可能にする危険な命令がないか監査されます。以前の Chrome バージョンでは CLFLUSH 命令が許可されており、CLFLUSH ベースの DRAM フォールトインデューサを実行できました。現在の Chrome バージョンのネイティブクライアントでは CLFLUSH が許可されていないため、このアプローチは機能しません。

上で説明したように、DRAM に負荷をかけるために CLFLUSH は必要ないため、Chrome の保護は不完全である可能性があります。これはネイティブクライアントベクターにのみ適用され、Web ブラウザーで DRAM 障害をトリガーする他の方法 (JavaScript など) が存在する可能性があります。

この種の問題に対してソフトウェアベースの解決策は可能でしょうか?

Rowhammer スタイルの DRAM フォールトインジェクションが同じセキュリティードメイン (ゲストまたはプロセス) 内のデータにのみ影響するように、メモリーをハイパーバイザーゲストまたはオペレーティングシステムプロセスにマップすることは理論的には可能です。次のようないくつかの理由から、これが実際には実現可能である可能性は低いです。

  • セキュリティー境界を越えた読み取り専用ページの共有 (カーネルの同じページのマージ、プロセス間の読み取り専用マッピングの共有など) を無効にして、システム負荷密度を大幅に軽減する必要があります。
  • このメカニズムはメモリー設定に大きく依存しており、CPU シリコンとマイクロコードのリビジョン、システムファームウェアのバージョン、メインボードのリビジョンなどに応じて、非常に特殊なシステム設定でのみ有効です。

現在でも、このような機能を備えたシステムでは、edac-utils パッケージの edac-util コマンドを使用して、MCE イベント (mcelog を使用)、特に EDAC (エラー検出および修正) カウンターの発生を監視することができます。これらのツールを使用すると、悪用可能な DRAM 障害が発生する前に、DRAM 関連のシステム劣化の初期の兆候を特定できます。

DRAM 障害に対処するために顧客は何をすべきですか?

Red Hat は、DRAM 障害はハードウェアベンダーが十分な設計上の余裕と ECC メモリーなどのテクノロジーを備えて対処する必要がある問題であると考えています。

Red Hat では、カーネルが MCE イベントを記録した 後など、DRAM の欠陥が疑われる場合に備えて、memtest86+ を実行することを推奨します。

システムベンダーは、DRAM 障害が自社のハードウェアプラットフォームにどのような影響を与えるかについて追加情報を持っている場合があります。Red Hat の顧客は、必要に応じて追加情報についてシステムベンダーに問い合わせることを推奨します。

参考資料

  • https://comsec.ethz.ch/wp-content/files/blacksmith_sp22.pdf
  • https://comsec.ethz.ch/research/dram/blacksmith/
  • https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
  • https://www.vusec.net/projects/trrespass
  • https://download.vusec.net/papers/trrespass_sp20.pdf
  • https://rambleed.com/
  • https://arxiv.org/pdf/1805.04956.pdf
  • https://arxiv.org/pdf/1912.03076.pdf
  • https://www.vusec.net/projects/eccploit/
  • https://www.vusec.net/projects/throwhammer/
  • https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
  • http://aod.teletogether.com/sec/20140519/SAMSUNG_Investors_Forum_2014_session_1.pdf
  • https://www.idginsiderpro.com/article/3529519/rowhammer-memory-attacks-close-in-on-the-real-world.html

Comments