それでは、FATファイルシステムデバイスの簡単な説明から始めましょう-脆弱なfastfat.sysドライバーが実装するFATファイルシステムデバイスとの連携。 詳細なドキュメントは、仕様で見ることができます（ リンク ）。 私たちは、私たちにとって関心のある条項についてのみ検討します。
c-jump.comから取得したFATファイルシステムの構築の図（ リンク ）
ボリュームの先頭（ゼロオフセット）には、いわゆるブートセクター（実際にはBIOSパラメーターブロック、または略してBPB）があります。 これはボリュームの一般的な構造を記述する構造であり、ドライバーがボリュームを正しく処理するために必要です。 この構造には多くの便利なフィールドがあり、それらのいくつかに戻ります。 現時点で注目に値する主なことは、Fat32ファイルシステムについて具体的に話していることです。 他のFAT実装では、BPBのバイアスは異なるだけでなく、バイアスも異なります。
次に、BPBの後にFAT自体（FATデータ構造）が続きます。これは、本質的にファイルクラスターの単一リンクリストです（ディスク全体がクラスターに分割されます（さらに、一度に1つのファイルにのみ1つのクラスターのデータを含めることができます）。そのサイズはフォーマット中に設定されますディスク-次に、クラスターはセクターに分割されます）
リソースtechnet.microsoft.comから取得したディスク上のデータ領域のデバイスの図（ リンク ）
この段階では、BPBについて覚えておくか、NumFatsフィールドに注意を払う必要があります。 仕様に従って、このフィールドは各ファイルのFAT構造のコピー数を設定します。 同じ仕様では、このフィールドの標準値（したがって、さまざまなドライバーとのFS互換性が保証される）は2であることが示されています。 各ファイルには、FAT構造の2つのコピーがあります-これは、不良セクタの場合のファイルの損失を防ぐために必要です。 脆弱性が存在するのは、このフィールドの処理です。 numfat> 2の場合、コードのセクションへの条件付き遷移が発生し、カーネルプールにメモリが誤って割り当てられます（コードはドライバー内で実行されるため）。
この脆弱性も調査したBeyondTrustの専門家のブログであるblog.beyondtrust.comリソースから取得したfastfat.sysドライバーのFatCommonWrite関数の脆弱なコードの一部のイラスト（ リンク ）
この脆弱性は、FatCommonWrite関数にあります。または、ExAllocatePoolWithTagの呼び出しにあり、引数として-必要な場所に値numfatが渡されます-IoRuns構造のコピーの数にサイズを掛けません。 図に示されているコードでは、ecxレジスタにBPB構造体へのポインターがあり、それからオフセット96hにNumFatsフィールドがあります。これは、図からわかるように、ExAllocatePoolWithTag関数のNumberOfBytes引数として（スタックとして、パッチとして取得されます） 、Microsoftからリリースされた、図に示されているブロックに欠落している乗算を追加するだけです。
この段階では、デバイスのメモリドライバーについて詳しく説明する価値があります（このクラスの脆弱性の非常に優れた分析は、ハブ- リンクにあります ）。 要約すると、ドライバーのメモリはプールに分割され、各プールはチャンクのリストであり、それに応じてドライバーに必要な情報があります。
したがって、メモリ領域にはカーネルプールのオーバーフローなどの脆弱性があり、その結果、オーバーフローしたチャンクの直後のメモリにある別のドライバーのメモリチャンクを中断することにより、悪用される可能性があります。
カーネルプールオーバーフローに関するハーバーの記事から引用したチャンクオーバーフロープロセスの図（ リンク ）
この段階では、すでに何らかの結果が得られています。別のドライバーのメモリが破損し、Bad Pool HeaderエラーのあるBSODが発生します。 しかし、これは十分ではありません、なぜなら メモリ破損は、特権の昇格とはほど遠いものです。
目標は、攻撃された（すぐにオーバーフローする）チャンクのヘッダーを正しいものに変更することですが、有効ではありませんが、任意です（ドライバーのメモリストリームをキャプチャするため）。 これにより、攻撃者がドライバーに代わってコードを実行する機会を持つ可能性があります。 特権のエスカレーション。 ただし、チャンクを圧倒するデータの分析が示すように、この状況ではそのような可能性はありません。 これを正当化するために、脆弱な機能でメモリが割り当てられているIoRuns構造を検討してください。 おそらく（再び、Windows 2000のソースに基づいて）IoRuns構造は、FAT構造をファイルシステムに書き込むためのツールとして機能します（新しいファイルがディスクに書き込まれたときにFatCommonWrite関数が呼び出されるため、つまりFATを作成/変更するため）構造体）。 ポイントは、すべてのコピー（番号はBPBのNumFatsフィールドによって規制されている）が非同期に書き込まれることです。このため、各コピーには独自のIoRunsインスタンスが割り当てられ、書き込むオフセット（VboおよびLboフィールド）と書き込む量（ ByteCount）。
IoRuns構造の初期化サイクルの図（WDK 8.0サンプルのソースによる）
したがって、IoRuns構造体のフィールドの値を置き換えるのはそれほど簡単ではなく、他のすべての構造体は、最初の構造体のフィールドの値に依存するか、明確に計算されます。 私たちが持っているもの：最初のフィールドはFAT構造のコピーが記録され始めるオフセットです、2番目のフィールドはこのコピーが記録されるオフセットです（ライターの値による）、おそらく3番目のフィールドはFAT構造への追加のプロローグを処理するために必要です。 最後のフィールドはBPBから直接設定されます-フィールドBPB_BytsPerSecと同じです。 FAT構造の各コピーは、1つのセクターを占有します。
次のチャンクを上書きして正しいままにするようなデータを設定することは、単に不可能です。 ULONGフィールドを1つだけ制御するため、特権エスカレーションを実装することは不可能であるという結論に至ります。
要約すると、この調査では、MS14-063が本当に重要であり、特権のエスカレーションにつながる可能性があるとMicrosoftの専門家が言うときに正しいのかという疑問が生じます。 分析によると、この脆弱性はこの脆弱性に対するBSODコールでのみ可能ですが、エスカレーションについて話す必要はありません。