後方互換性は良いことですが、妥当な範囲内で使用する必要があります。 結局のところ、Windowsカーネルには前世紀に開発されたコードがまだあります。 彼の高い安全性について話すのは愚かでしょう。 そして、DOS仮想マシンのサブシステムに根付いた脆弱性の3つの特権エスカレーションの例でそれを証明します。
1978年、Intelは最初のx86プロセッサである8086をリリースしました。これは、リアルモードとして知られる16ビットコードを実行するためのかなり限られた環境を提供しました。 その後まもなく、オペレーティングシステムとそこで実行される通常のプログラムの両方のために、新しいハードウェアプラットフォーム用のソフトウェアソリューションの積極的な開発が開始されました。 Microsoftのディスクオペレーティングシステム（DOS）は、すぐれたデスクトップデスクトップ環境としての地位を確立し、このOSのアプリケーションは10年以上にわたって作成され、市場に参入しました。 最も有名な例は、Norton Commander、ChiWriter、またはQuattro Proです。 すでにより強力で安全な保護モードを活用した1992年にWindowsオペレーティングシステム用のNTアーキテクチャを開発する際の重要な決定事項の1つは、DOSとの下位互換性を維持すること、つまり、新しいグラフィック環境で古いプログラムを安全に起動できるようにすることでした。
警告
すべての情報は情報提供のみを目的として提供されています。 編集者も著者も、この記事の資料によって引き起こされる可能性のある損害について責任を負いません。
NTVDM
Windowsで作成された特別な互換モードは、非常に機能的であることが判明しました。 技術面と作業ロジックの両方からかなり複雑なコンポーネントであるという事実により、この外観は、ローカルユーザーがオペレーティングシステムでの権限を高めることを目的とした攻撃を開始する多くの新しい機会を切り開きました。 NTVDMは、セキュリティの問題を繰り返し発見して修正しましたが、これまでのところ、カーネルには多くの興味深い未開拓の機能があります。 次のセクションでは、そのうちの1つ、NTVDM.EXEホストプロセスで発生する例外の特定の処理について詳しく説明します。 ただし、64ビットバージョンのシステムはロングモードモードの実装によりVDMをサポートしていないため、DOS互換サブシステムで検出される可能性のあるバグは32ビットWindowsプラットフォームのみに影響することに注意してください。 Intelプロセッサ上の64ビットコード。 新しいWindows 8および8.1オペレーティングシステムでは、このサブシステムがデフォルトで無効になっているため、潜在的なカーネルの脆弱性の影響は平準化されており、実行には管理者権限が必要です。 それでも、これらの脆弱性は、Windows XPからWindows 7 32ビットまでのシステムでユーザーの介入なしに正常に悪用される可能性があります（現時点では、このようなシステムがデスクトップOSのフリート全体の約50％を占めると思われます）。
リアルタイム
最新の32ビット環境で16ビットアプリケーションとの下位互換性を維持することは、リアルモードとプロテクトモードの動作が根本的に異なるため、技術的な観点から非常に困難です。 これには、プロセッサモード、ワードとアドレスの幅、命令のエンコード、その他多くのことが含まれます。 つまり、最新のオペレーティングシステムの標準ツールを使用して80年代から廃止されたプログラムを実行することはできません。 一方、16ビットプログラムを起動するたびにプロセッサをリアルモードに切り替えることもオプションではありません。これにより、権利の分離などの保護モードの基本設定が無意味になります。 ほぼ無制限のランタイム環境で動作し、コンピューターの周辺全体に直接アクセスする、潜在的に信頼されていないコードに制御を移すと、システムのセキュリティに対する潜在的な脅威をもたらすだけでなく、以前の作業コンテキストに戻るという決定が行われるため、オペレーティングシステムからコンピューターの制御が奪われますそれはこの古いアプリケーションでのことです。
仮想8086モード
これらおよび他の多くの後方互換性の問題をよく理解していたインテルのエンジニアは、保護モードの重要なコンポーネントとなった仮想8086（V8086）と呼ばれるまったく新しい実行モードを開発しました。 V8086モードの主な機能は、その中で実行されるコードについて、リアルモードとは完全に区別できないが、同時にメインオペレーティングシステムによって完全に制御されることです。 これにより、セキュリティを維持しながら、悪影響を与えることなく、32ビット環境で古いアプリケーションを実行できます。 このテクノロジーは、オペレーティングシステムが仮想マシンモニター（VMM）として機能するDOSソフトウェアの仮想化メカニズムと見なすことができます。 VMMは作業環境を作成し、ゲストアプリケーションが使用する重要で特権のある命令を処理し、16ビットコードは特別なモードでネイティブの速度で実行されます。 V8086を使用したオペレーティングシステムの典型的なIntelが開発した実行順序を図に示します。 1。
図 1.廃止された16ビットアプリケーションを実行しているときのオペレーティングシステムの制御の移行
Microsoft Windowsの場合、エンティティ「オペレーティングシステム」はさらに2つのコンポーネントに分割されます。カーネルと、ユーザーレベルで動作するNTVDM.EXEプロセスです。 説明されたサブシステムのサポートは両方のレベルで利用可能です-古いソフトウェア内で発生するイベントにはカーネルによって直接処理されるものと、リング3レベルでの助けが必要なものがあります（図2を参照）。 古いソフトウェアコードの実行は特別なプロセスで分離されているため、特定のプロセッサイベントがVDMホストからのものかどうかに応じて、カーネルは特定のプロセッサイベントに個別の処理が必要かどうかを簡単に判断できます。 その結果、ほとんどのリング0レベルのプロシージャは、特別なプロセスから呼び出されると追加の機能を提供します。 顕著な例の1つとして、x86のトラップハンドラー（nt！KiTrap0c、nt！KiTrap0d、nt！KiTrap0eなど）、NTシステムコール（nt！NtVdmControlなど）、win32k.sysシステムコール（例：nt！NtUserInitTask）。 NTVDM.EXEプロセスはシステムによって特別な方法で処理されますが、ローカルユーザーのセキュリティトークンを継承することに注意することが重要です。 これにより、攻撃者は、ドキュメント化された2つのAPI関数（OpenProcessとCreateRemoteThread）のみを使用してプロセス内で任意のコードを実行し、VDMサポートを担当するカーネル部分の仮想の脆弱性を悪用できます。
図 2. Microsoft Windowsでのランタイム実行実行ランタイム16ビットアプリケーションの例
DPMI
最後に、NTVDMはDOSプロテクトモードインターフェイス（DPMI）インターフェイスの仕様の大部分をサポートしていることを忘れてはなりません。つまり、仮想8086モードの実装に加えて、ランタイム環境（メモリセグメントの作成など）を提供し、コードを実行することもできます保護モード。 したがって、単純な16ビットエミュレーションに加えて、カーネルで32ビット命令を処理するためのコードが表示される場合があります。
CVE-2013-3196（ntのwrite-what-where！PushInt）
一般保護違反
仮想8086モードの最も重要な機能の1つと、DPMIをサポートする廃止された32ビットコードを実行するためにNTVDM.EXEによって作成された作業環境は、クリティカルまたは昇格した命令（INT、OUTまたはSTI）は、すぐにカーネルで一般保護違反例外を発生させます。 前述のように、その後、オペレーティングシステムは命令の動作を安全にエミュレートし、中断されたゲストコードの実行に戻り、実行を継続する必要があります。 判明したように、16ビットおよび32ビットエミュレーションモードの命令をエミュレートするためのコードは完全にカーネルスペースにあり、攻撃の興味深い可能性を開きます。特別なx86命令の動作をプログラムで再現します。 エミュレータを使用するには、次の条件が満たされている必要があります。
-
#GP
例外が仮想8086モード内で発生する（EFlags.VMフラグが設定されている） または #GP例外がユーザーモード（リング3）で発生し、 - cs：セグメントセレクターは、例外の時点で
KGDT_R3_CODE (0x1b)
と等しくありません。 - VDMホストプロセスで#GP例外が発生します。
図 3. #GPハンドラーが使用する仮想8086モード命令ディスパッチテーブル
いずれかのオプションが完全に実行されると、＃GPハンドラーは制御を
nt!VdmDispatchOpcode_try
内部プロシージャに転送し、内部プロシージャは失敗した命令の基本的なデコードを実行し、この命令に適用可能な1つ以上のハンドラー関数を呼び出します。 16ビットと32ビットのエミュレーションモードのハンドラーのリストを図5に示します。 3および4; ご覧のとおり、カーネルは非常に長い命令とそのプレフィックスのリストを生成します。 私たちの意見では、今年まで、コードのこの部分は、これまで脆弱性のテストが行われていなかった可能性が最も高いため、調査の重大なターゲットになりました。 この「発見」の後、潜在的な欠陥を探すためにすべてのプロセッサをリバースエンジニアリングし、数時間以内に最初の結果を得ることにしました。 最初の脆弱性は、プロテクトモードのINT命令のエミュレーション層にありました。
図 4. #GPハンドラーが使用するプロテクトモード命令ディスパッチテーブル
犬はどこに埋葬されていますか
nt！OpcodeINTnnハンドラー関数の基本的な役割は、失敗の原因となった命令のオペランドimm8を取得し、別のnt！PushInt内部プロシージャを呼び出すことです。 その主なタスクは、ユーザーss：セグメントのベースアドレスを取得し、ss：espスタックポインターの完全なアドレスを使用して、システム割り込みハンドラーのアドレスをスタック（ユーザーのアドレス空間内）に配置することです。 リバースエンジニアリングによって取得されたCコードは、3つの16ビットまたは32ビットワードをスタックに配置する役割を果たします（ゲスト実行モードに応じて）は、以下のとおりです。
if (reginfo->ViFlags & VDM_INT_32) { *(DWORD *)(reginfo->RiSsBase + NewVdmEsp + 0) = reginfo->RiEip; *(DWORD *)(reginfo->RiSsBase + NewVdmEsp + 4) = trap_frame->SegCs; *(DWORD *)(reginfo->RiSsBase + NewVdmEsp + 8) = GetVirtualBits(reginfo->RiEFlags); } else { *(WORD *)(reginfo->RiSsBase + NewVdmEsp + 0) = reginfo->RiEip; *(WORD *)(reginfo->RiSsBase + NewVdmEsp + 2) = trap_frame->SegCs; *(WORD *)(reginfo->RiSsBase + NewVdmEsp + 4) = GetVirtualBits(reginfo->RiEFlags); }
実装の問題は、おそらくNTVDM.EXEプロセスのアドレススペースを常に指すという仮定のために、ユーザースペーススタック（リング3）へのポインターの正確性がまったくチェックされないことでした。 そしてもちろん、これは常に当てはまるわけではありません。なぜなら、エクスプロイトは任意のポインター、たとえばカーネルに属するアドレスにespレジスタを設定できるからです。 したがって、この脆弱性を悪用するには、DOS仮想マシンのコンテキストで、
mov esp, 0xdeadbeef
、
int 0
2つの簡単な指示に従うだけで十分でした。 唯一の制限は、
cs:
と
ss:
両方がLocal Descriptor Table（LDT）内のコードとデータセグメントを選択し、int引数引数がカーネルレベル割り込み（0〜 255（シーケンス0x2a – 0x2eを除く）。 パッチ未適用のWindows 7 SP1で説明されている2つの指示を実行した結果を以下に示します。
TRAP_FRAME: a2ea4c24 -- (.trap 0xffffffffa2ea4c24) ErrCode = 00000002 eax=024ef568 ebx=00000000 ecx=00000000 edx=6710140f esi=a2ea4cb8 edi=deadbee3 eip=82ab21a7 esp=a2ea4c98 ebp=a2ea4d34 iopl=0 nv up ei pl nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202 nt!PushInt+0xa5: 82ab21a7 89143b mov dword ptr [ebx+edi],edx ds:0023:deadbee3=???????? Resetting default scope
32ビット変数の1つがカーネルによって任意に選択されたeip例外に保存されるという事実により、状況は軽視できる単純なwrite-what-where条件になります（たとえば、最上位ビットを直接設定することはできません）。 このような便利な基本機能を自由に使用できるため、たとえば、nt！NtQueryIntervalProfileシステムコールを介してユーザー空間から呼び出される既知のnt！HalDispatchTable + 4ポインターなど、関数ポインターの1つを書き換えることにより、カーネルの制御フローを「ハイジャック」することが可能になります。
図 5. nt！PushIntでのwrite-what-whereの実装の成功
この脆弱性の除去は非常に簡単で、nt！PushIntに追加された3つの追加手順で構成されています。 彼らは、
ss:esp
アドレス（ユーザー空間からのものである必要があります）が実際にアドレス空間の下部を指していることを確認します（図6を参照）。
図6. nt！PushIntの初期実装とパッチ適用後のバイナリの違い。
CVE-2013-3197（ntのwrite-what-where！PushException）
Windowsシステムの割り込みハンドラー（
nt!KiTrap0d
に加えて）を注意深く見ると、VDMの特定の機能が#GPハンドラーだけでなく、それらのほとんどによって提供されていることが明らかになります。 この点で、一般保護違反の機能は、特定の種類の例外（重要な命令や特権命令など）を処理するための専用ルーチンを備えていることです。 他のハンドラーはこのような複雑な機能を使用せず、VDM例外が発生した場合は、代わりに
nt!Ki386VdmReflectException
関数を呼び出すだけです。 これにより、
nt!VdmDispatchOpcode_try
命令をエミュレートするのとほぼ同じ方法で、仮想環境でイベントをエミュレートしようとします。 コントロール転送グラフは、ほとんどのハンドラーがこの関数に依存していることを示しています（図7を参照）。
図 7.関数グラフnt！Ki386VdmReflectException
頭痛の原因
通常の状況（つまり、通常のプロセス）では、通常はnt！CommonDispatchExceptionバリアントの1つで実行が終了し、イベントがユーザースペースの例外ハンドラーに送信されます。 VDMの場合、カーネルはまずnt！PushExceptionを使用してユーザー空間スタックにフレームトラップを作成し、cs：eipアドレスに制御をリダイレクトします。これは、NtCurrentTeb（）-> Vdm-> VdmIntDescriptor [trap_no]フィールド（ 。図8）; この手順が機能しない場合のみ、例外は通常の方法で処理されます。 また、前のケースのように、エミュレートされたトラップフレームを作成するとき、カーネルはスタックポインターが実際にユーザーのアドレス空間内にあることを確認しません。 これもまた、6または12の代わりにサイズが16または32バイトのwrite-what-where条件を使用する可能性につながります。脆弱性の使用は同じくらい簡単で、カーネルスペースの任意のアドレスにespを設定し、例外をスローします（たとえば、＃DE via edx命令）、完全に初期化されたVDM環境の通常の詳細、およびエラー発生時のユーザーセグメントcs：およびss：
TRAP_FRAME: 8dd97c28 -- (.trap 0xffffffff8dd97c28) ErrCode = 00000002 eax=000007f7 ebx=00000000 ecx=00000000 edx=deadbebf esi=8dd97ce4 edi=00000634 eip=82a874b5 esp=8dd97c9c ebp=8dd97d1c iopl=0 nv up ei ng nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282 nt!PushException+0x150: 82a874b5 6689441a0e mov word ptr [edx+ebx+0Eh],ax ds:0023:deadbecd=???? Resetting default scope
図 8. NTVDMの実行を再開するために使用される内部ユーザー空間構造。例外により中止されます
そして今回は、監視対象アドレスに書き込まれた値の1つがeipエラーであるため、関数ポインターを使用する同じ方法（関数ポインター活用手法）を使用してコンピューターを完全に制御できます。 ただし、LDTの値には制限があるため、この脆弱性はWindows Vista以降のシステムでのみ使用できます。 Microsoftセキュリティ更新プログラムでは、16ビットと32ビットの両方のトラップフレームを作成するブランチのユーザースペースのスタックでポインターをチェックする2つの単純なブロックを挿入しました。
CVE-2013-3198（ntのwrite-what-where！VdmCallStringIoHandlerPushException）
特権VDM命令の処理に加えて、カーネルは重要な命令、つまり、I / Oポートでの割り込みと通信の制御を提供するCPL <= IOPLの場合にのみ実行できる命令の実行もエミュレートします。 最終的に、文字列の入出力のすべての命令（仮想8086モードおよび保護モードのINSB、INSW、OUTSB、OUTSW）は、内部関数nt！Ki386VdmDispatchStringIoによって実行され、「ポートエミュレーション」（ポートと呼ばれる大規模で複雑なメカニズムのエントリポイントとして機能しますエミュレーション）。 その正確な機能は開発チーム以外にはほとんど知られていませんが、このメカニズムはリバースエンジニアリングによって分解され、2009年にフランスの研究者Ivanlef0u によって詳細に説明されました 。 つまり、Windowsカーネルで実行されているデバイスドライバーは、文書化されていない関数ZwSetInformationProcess（ProcessIoPortHandlers）を使用して、特定のプロセス、ポート範囲、およびポートアクセスタイプのI / Oエミュレーションハンドラーを登録できます。 したがって、カーネル空間のコンポーネントは、理論的にはVDMの下で実行されているプログラムの物理デバイスをエミュレートできます。 ただし、さらに重要な質問があります。Windowsのインストール直後に登録されているデフォルトハンドラはありますか？
私たちの知る限り、現在のところWindowsのポートエミュレーションは1つだけです。古いプログラムがフルスクリーンモードで実行されると、デフォルトのグラフィックドライバーVIDEOPRT.SYSがVGA範囲（0x3b0-0x3df）のハンドラーを登録します。 この登録のスタックトレースを以下に示します。
ChildEBP RetAddr Args to Child 807b1738 82a55023 85886680 00000001 b06b1bf3 nt!Psp386InstallIoHandler 807b1994 828588a6 00000088 0000000d 807b1a40 nt!NtSetInformationProcess+0x7ad 807b1994 82857815 00000088 0000000d 807b1a40 nt!KiSystemServicePostCall 807b1a1c 91619f84 00000088 0000000d 807b1a40 nt!ZwSetInformationProcess+0x11 807b1a60 91616467 86a357f0 00000001 8597ae80 VIDEOPRT!pVideoPortEnableVDM+0x82 807b1ab4 82851c1e 86a357f0 86f32278 86f32278 VIDEOPRT!pVideoPortDispatch+0x360 807b1acc 9a5c45a2 fe915c48 fffffffe 00000000 nt!IofCallDriver+0x63 807b1af8 9a733564 86a35738 00230000 fe915c48 win32k!GreDeviceIoControlEx+0x97 807b1d18 828588a6 00000000 0130f294 00000004 win32k!NtGdiFullscreenControl+0x1100 807b1d18 77c77094 00000000 0130f294 00000004 nt!KiSystemServicePostCall 0130f25c 77ab6951 00670577 00000000 0130f294 ntdll!KiFastSystemCallRet 0130f260 00670577 00000000 0130f294 00000004 GDI32!NtGdiFullscreenControl+0xc 0130f28c 00672c78 00000088 0000003a 003bd0b0 conhost!ConnectToEmulator+0x6c 0130f3c0 0065f24d 00000001 003bd0b0 0130f4d4 conhost!DisplayModeTransition+0x40e 0130f458 7635c4e7 000e001c 0000003a 00000001 conhost!ConsoleWindowProc+0x419
つまり、この手法は、ビデオカードの代替ドライバーがシステムにインストールされておらず、標準のMicrosoftのドライバーが使用されている場合にのみ機能します。 全画面モードとウィンドウモードの切り替えは、文書化されたAPI呼び出しSetConsoleDisplayMode（CONSOLE_FULLSCREEN_MODE）およびSetConsoleDisplayMode（CONSOLE_WINDOWED_MODE）を使用して簡単に実現できます。
トラブルの原因
それで、命令のエミュレートに戻ります-nt！Ki386VdmDispatchStringIo関数は、nt！Ps386GetVdmIoHandlerを使用してエミュレートされた操作のハンドラーを定義し、ds：siのメモリからユーザーデータを読み取り、「読み取り」操作の場合はsi、I / Oハンドラーを呼び出してデータを書き込みますes：書き込み操作の場合はdi。 おそらく既に推測したように、2つのポインター（ユーザー空間から取得されたと思われる）はいずれも使用前に検証に合格しません。 特に、プロテクトモードセグメントでは32ビットのベースアドレスを使用できることを考えると、最善のアイデアではありません。そのため、この脆弱性により、カーネルメモリでランダムに選択されたアドレスを読み書きできます。
要約すると、この脆弱性を悪用するには、VDMコンソールをフルスクリーンモードに切り替えてVIDEOPRT.SYSドライバーにVGA I / Oハンドラーを登録させ、
cs:
および
es:
でユーザーセグメントを作成およびロードする必要があります（そして最後のセグメントのベースアドレスはカーネルメモリを指します上書き）、diレジスタを値0x0で初期化し、dxを値0x3b0で初期化してから、insb命令を呼び出します。 もちろん、すべての操作はNTVDM.EXEプロセス内で実行する必要があります。 esセグメントのベースを0xaaaaaaaaaにインストールし、パッチが適用されていないシステムでエクスプロイトを実行すると、次のようになります。
TRAP_FRAME: 963889fc -- (.trap 0xffffffff963889fc) ErrCode = 00000002 eax=aaaaaa00 ebx=00000001 ecx=fffffffd edx=00000003 esi=8297d260 edi=aaaaaaaa eip=82854fc6 esp=96388a70 ebp=96388a78 iopl=0 vif nv up ei ng nz ac po cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00090293 nt!memcpy+0x166: 82854fc6 8807 mov byte ptr [edi],al ds:0023:aaaaaaaa=?? Resetting default scope
デフォルトでは、ポート0x3b0はメモリに1バイト-0x00を書き込むため、この脆弱性を使用してカーネル空間関数へのポインターをリセットできます。 これを行ったら、リング0コードの実行を、すでにNTVDMアドレス空間にあるNULLページにリダイレクトできます。 したがって、この場合も、ローカルプロセスのセキュリティトークンを増やすか、他の便利な方法でシステムのセキュリティを侵害することができます。
この問題を解決するために、Microsoftはds：siのユーザー空間からデータを読み取る前にProbeForReadをインライン呼び出しし、es：diにデータを書き込む前にProbeForWriteを一般的に呼び出しました。
大声で考え
この記事で説明した3つの特権エスカレーションの脆弱性はすべて、ユーザーが提供したデータが検証に合格しないために発生するwrite-where-where条件が原因で起こりました。 他の状況では、ベースNTカーネルイメージ（ntoskrnl.exe）に対するこのタイプの脆弱性は非常にまれです。 また、近年マイクロソフトはこれらの問題のほとんどを内部的に追跡して解消することができましたが、VDMのI / Oエミュレーションコード、例外、指示をどうにか見逃していました。 最も可能性が高いのは、高レベルのCおよびC ++コードに非常に効果的な静的解析ツールが現在アセンブラーをサポートしていないか、アセンブラーとの相互作用が不十分であるためです。 これらの脆弱性を悪用する能力は、Windows Vistaで最初に登場したLDT入力制御コードの小さな無関係な変更の後にのみ登場したことは注目に値します。 この変更により、nt！PspIsDescriptorValid内部関数は、データベースおよび入力制限に関連するチェックを奪われました。 ただし、これは偶然の一致にすぎません。 この脆弱性の根底にある本当の理由は、セグメント制御の違いではなく、エミュレーションコードがメモリ操作で完全なアドレスss：esp、ds：siおよびes：diを使用したという事実でした。 Windowsカーネルは次のように述べています。特権コードはメモリのユーザーセグメントを決して信頼すべきではありません。
要約する
これらの3つの発見の例を使用すると、多くのカーネルの脆弱性は、90年代のほぼ初めに書かれたコードの存在によって引き起こされることが再び明確にわかります。 その後、セキュリティは重要な優先事項とは見なされず（現在とは異なり）、不正なコードが作成され、20年前に書かれて以来、セキュリティを確保するという観点からセキュリティをレビューした人はいません。 同時に、最新のWindows 8.1およびServer 2012を含む最新バージョンのWindowsでは、コードの大部分が使用されます。2013年に作成された最新のカーネルソースコードは、安全な開発ガイドラインに準拠し、リリース前に徹底的にテストする必要があります。 したがって、システムの最新バージョンで導入された新しい機能要素を掘り下げる代わりに、ずっと前に作成された重要なコンポーネントのエラーを探す方がはるかに効率的であると考えています。
さて、最後に注意する価値があるのは、Windows 8のDOSアプリケーションとの既定の下位互換性を無効にすることは、マイクロソフトの優れたソリューションであったということです。 彼のおかげで、まだ発見されていないエラーのほとんどは使用できないか、検索しても意味がありません。攻撃者はその使用から十分な利益を得られないからです。 さらに、このソリューションにより、NULLページを完全に無効にすることが可能になりました（VDMホストプロセスでは以前にそれらが必要でした）。このため、カーネルとデバイスドライバーの両方でよく見られるNULLポインターの参照解除などのエラーは、完全に消失するか、大幅に減少します。 将来のセキュリティ機能に対する全体的な影響という点では、これはマイクロソフトがこれまでに行った最も重要な改善の1つです。 さて、さあ先に進みましょう-カーネルであなた自身のバグを見つけてください！
Mateusz "j00ru" Jurczykによる投稿。
2014年1月から最初にHacker誌に掲載されました。
ハッカーを購読する
