kernel.orgの元チーフシステム管理者であるKeesCook そしてUbuntuセキュリティチームのリーダーであり、現在GoogleでAndroidとChromeOSを保護するために働いています。 カーネルスタックオフセットをランダム化する一連のパッチをリリースしました システムコールを処理するとき。 パッチは、スタックの場所を変更することでカーネルのセキュリティを向上させます。lまたは、スタック攻撃がはるかに困難になり、成功しなくなります
パッチの元のアイデアは、PaXRANDKSTACKプロジェクトに属しています。 2019年、IntelのエンジニアであるElena Reshetovaは、Linuxカーネルの主要な構成に含めるのに適した、このアイデアの実装を作成しようとしました。
その後、イニシアチブはキースクックによって取られました カーネルのメインバージョンに適した実装を提示し、そのパッチはLinuxのバージョン5.13で計画されています。
モードはデフォルトで無効になり、有効にするために、カーネルコマンドラインパラメータが提供されます "Randomize_kstack_offset =オン/オフ»および設定 CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT、 さらに、このモードを有効にすることによるオーバーヘッドは、パフォーマンスの約1％の損失と見積もられています。
提案された保護の本質は、各システムコールでランダムなスタックオフセットを選択することです。、これは、アドレス情報を受信した場合でも、メモリ内のスタックレイアウトの決定を複雑にします。これは、スタックのベースアドレスが次の呼び出しで変更されるためです。
の実装とは異なり PaXRANDKスタック、カーネルに含めるために提案されたパッチでは、 ランダム化は初期段階では行われません, しかし、pt_regs構造を設定した後、これにより、ptraceベースのメソッドを使用して、長時間実行されるシステムコール中にランダムオフセットを決定することができなくなります。
Linuxカーネルスタックの保護が絶えず改善されているため（保護ページを使用したvmapベースのスタックマッピング、thread_infoの削除、STACKLEAK）、攻撃者はエクスプロイトが機能するための新しい方法を見つける必要がありました。
彼らは、カーネルスタックの決定論を持っており、それに依存し続けています。 VMAP_STACKおよびTHREAD_INFO_IN_TASK_STRUCT それらは関連していませんでした。 たとえば、スタックオフセットがシステムコール間で決定論的でなかった場合、次の最近の攻撃は妨げられていたでしょう。
randomize_kstack_offset関数の目的は、ランダムオフセットを追加することです pt_regsがスタックにプッシュされた後、システムコール処理中に残りのスレッドスタックが使用される前に、プロセスがシステムコールを発行するたびに変更します。 ランダム性の原因は現在、アーキテクチャによって定義されています（ただし、x86はrdtsc（）の下位バイトを使用します）。
エントロピーのさまざまなソースに対して将来の拡張が可能ですが、このパッチの範囲外です。 また、予測不可能性を高めるために、システムコールの最後に新しいオフセットが選択され（システムコールの入力時よりもユーザースペースからの測定が容易ではないはずです）、それらはXNUMXつの変数ごとに格納されます。 CPU。値の存続期間が単一のタスクに明示的に関連付けられたままにならないようにします。
スタックセーバーはコンパイルユニットに対してすでに無条件に無効になっているため、x86ではこれに対する目に見える変更はありませんが、arm64では変更が必要です。 残念ながら、特定の機能のスタックセーバーを無効にするために使用できる属性はありません。 PaX RANDKSTACK関数との比較：RANDKSTACK関数は、スタックの開始位置（cpu_current_top_of_stack）をランダム化します。つまり、スタック上のpt_regs構造体の位置を含みます。
最初は このパッチは同じアプローチに従いましたが、 しかし、最近の議論では、攻撃者がptrace機能を利用できるかのように、ほとんど価値がないと判断されました。PTRACE_PEEKUSRを使用して、pt_regs構造にさまざまなオフセットを読み書きし、アクセスキャッシュの動作pt_regsを観察して、ランダムを見つけることができます。スタックオフセット。
最後に、 初期実装はARM64およびx86 / x86_64プロセッサをサポートします.