チェックポイントは、脆弱性の悪用をより困難にするセーフリンク保護技術を提案しました

チェックポイント会社 提示 安全リンク保護メカニズム。malloc 呼び出しの実行時に割り当てられるバッファーへのポインターの定義または変更を操作するエクスプロイトの作成を困難にします。セーフリンクは脆弱性悪用の可能性を完全にブロックするわけではありませんが、悪用可能なバッファオーバーフローに加えて、情報の漏洩を引き起こす別の脆弱性を見つける必要があるため、最小限のオーバーヘッドで特定のカテゴリの悪用の作成が大幅に複雑になります。メモリ内のヒープの配置。

Safe-Linking を実装するパッチは、Glibc (ptmalloc)、uClibc-NG (dlmalloc)、gperftools (tcmalloc)、Google TCMalloc 用に用意されており、Chromium の保護をアップグレードするためにも提案されています (
2012 年以来、Chromium には同じ問題の解決を目的とした MaskPtr 保護技術が組み込まれていますが、Checkpoint のソリューションはより高いパフォーマンスを示しています)。
提案されたパッチは、8 月のリリースでの配信がすでに承認されています glibc 3.32 セーフリンクはデフォルトで有効になります。 uClibc-NG はセーフリンクをサポートします 入力しました リリース 1.0.33 に含まれており、デフォルトで有効になっています。 gperftools (旧 tcmalloc) の変更点 受け入れられましたですが、将来のリリースではオプションとして提供される予定です。

開発者 TCMalloc (新しい tcmalloc) が受け入れを拒否しました 変更は、深刻なパフォーマンスの低下と、すべてが期待どおりに動作していることを定期的に確認するための大規模なテストを追加する必要性を挙げています。チェックポイントのエンジニアによるテストでは、セーフリンク方式では追加のメモリ消費が発生せず、ヒープ操作を実行する際のパフォーマンスの低下は平均でわずか 0.02%、最悪の場合でも 1.5​​% 低下することがわかりました (比較のために、 Chromium で使用されている方法は「2% 未満」と推定されます)。インクルージョン
セーフリンクにより、free() が呼び出されるたびに 2 ~ 3 個の追加のアセンブリ命令が実行され、malloc() が呼び出されるたびに 3 ~ 4 個の追加のアセンブリ命令が実行されます。初期化ステージとランダム値生成ステージを実行する必要はありません。

チェックポイントは、脆弱性の悪用をより困難にするセーフリンク保護技術を提案しました

セーフリンクを使用すると、さまざまなヒープ実装のセキュリティを向上させるだけでなく、バ​​ッファ自体の隣に配置されたポインタの単一リンク リストを使用するデータ構造に整合性制御を追加することもできます。このメソッドは実装が非常に簡単で、マクロを 1 つ追加し、それをコード内の次のブロックへのポインターに適用するだけです (たとえば、Glibc の場合)。 変化 ほんの数行のコードです)。この方法は、要約すると次の変更になります。

+#define PROTECT_PTR(pos, ptr) \
+ ((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))

+#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)

- nextp = p->fd;
+ nextp = REVEAL_PTR (p->fd);
...

この方法の本質は、ASLR アドレスランダム化メカニズム (mmap_base) からのランダム データを使用して、Fast-Bins や TCache などの単一リンク リストを保護することです。値がリスト内の次の要素へのポインターに適用される前に、マスク変換が実行され、ページの配置がチェックされます。ポインタは、演算「(L >> PAGE_SHIFT) XOR (P)」の結果によって置き換えられます。ここで、P はポインタの値、L はポインタが格納されているメモリ位置です。

チェックポイントは、脆弱性の悪用をより困難にするセーフリンク保護技術を提案しました

システムで使用する場合 ASLR (アドレス空間レイアウトのランダム化) ヒープ ベース アドレスを持つ L ビットの一部には、P (12 バイトのページの 4096 ビット シフト演算によって抽出) をエンコードするためのキーとして使用されるランダムな値が含まれています。ポインターは元の形式で保存されず、置き換えるにはヒープ割り当ての知識が必要になるため、この操作により、エクスプロイトでポインターがハイジャックされるリスクが軽減されます。さらに、パッチ コードには、ブロック アライメントの追加チェックも含まれています。これにより、攻撃者はポインタをアライメントされていない値に置き換えることができなくなり、アライメントされたビット数の知識が必要になります。これにより、64 ビット システムではさらにブロックが可能になります。 15 回中 16 回の攻撃試行では調整が考慮されていません。

この方法は、部分的なポインターの書き換え (下位バイトの変更)、完全なポインターの書き換え (攻撃者のコードへのリダイレクト)、および整列されていないアドレスでのリストの位置の変更を使用する攻撃から保護するのに効果的です。例として、最近では、malloc で Safe-Linking を使用すると悪用をブロックできることが示されています。 特定された 同じ脆弱性研究者による CVE-2020-6007 Philips Hue Bridge スマート ライトで、バッファ オーバーフローが原因で発生し、デバイスの制御を取得できるようになります。

出所: オープンネット.ru

コメントを追加します