Chromium プロジェクトの開発者 912 年以降、Chrome の安定版リリースで 2015 件の高リスクかつ重大な脆弱性が特定され、その 70% はメモリの安全性の低下 (C/C++ コードでポインターを操作する際のエラー) が原因であると結論付けられました。 これらの問題の半数 (36.1%) は、バッファに関連付けられたメモリを解放した後のバッファへのアクセス (解放後使用) が原因で発生します。
Chromium を設計したとき、当初は コードにエラーが発生する可能性があるため、脆弱性の影響を制限するためにサンドボックス分離の使用に重点が置かれました。 現在、このテクノロジーの使用可能性はその能力の限界に達しており、リソース消費の観点からこれ以上プロセスに細分化することは非現実的です。
コードベースのセキュリティを維持するために、Google はまた、「これによると、追加されたコードは、検証されていない入力データの操作、安全でないプログラミング言語 (C/C++) の使用、昇格された特権での実行という XNUMX つの条件のうち XNUMX つだけを満たさなければなりません。 このルールは、外部データを処理するコードを最小限の権限に減らす (分離する) か、安全なプログラミング言語で記述する必要があることを意味します。
コード ベースのセキュリティをさらに強化するために、コード ベースでのメモリ エラーの発生を防ぐプロジェクトが開始されました。 主なアプローチは XNUMX つあります。メモリを安全に操作するための関数を備えた C++ ライブラリを作成することと、ハードウェア保護メカニズムを使用してガベージ コレクターの範囲を拡張することです。 (メモリタグ付け拡張機能)、メモリを安全に操作できる言語 (Java、Kotlin、JavaScript、Rust、Swift) でコンポーネントを作成します。
作業は次の XNUMX つの分野に集中することが予想されます。
- C++ 開発プロセスに対する大幅な変更。パフォーマンスへの悪影響は排除されません (境界チェックとガベージ コレクションの追加)。 生のポインタの代わりに、次の型を使用することが提案されています。 これにより、パフォーマンス、メモリ消費量、安定性に顕著な悪影響を与えることなく、悪用可能な use-after-free エラーをセキュリティ上の脅威にならないクラッシュに減らすことができます。
- コンパイル時にメモリ安全性チェックを実行するように設計された言語を使用すると (コード実行時のそのようなチェックに固有のパフォーマンスへの悪影響は排除されますが、新しい言語のコードと他の言語のコードとの相互作用を整理するための追加コストが発生します) C++）。
メモリセーフなライブラリを使用するのが最も簡単な方法ですが、効率は低くなります。 Rust でコードを書き直すことは、最も効果的な方法であると評価されていますが、非常にコストがかかる方法でもあります。
出所： オープンネット.ru