Windowsマシンで [〜#〜] emet [〜#〜] を実行します。これは非常に効果的です。アプリケーションにいくつかの緩和策を適用することで、トラック内の多くの脅威を阻止します。 Webサイトがバグを悪用しようとしたためにInternetExplorerが停止した回数を数えられません...
EMETでのWord2013に問題があります。新しいドキュメントを作成して保存すると、EMETはWordを停止します。 EMETをトリガーするものは何でも、名前を付けて保存の下の参照ボタンのクリック/タップに関連します-)。したがって、[ファイルの保存]ダイアログに関連しています(キーボードショートカットを使用して開くと保存はOKです。具体的にはファイルの保存ダイアログ)。
EMETがWordを停止すると、次のエラーがアプリケーションイベントログに書き込まれます。
EMET detected Caller mitigation and will close the application: WINWORD.EXE
Caller check failed:
Application : C:\Program Files (x86)\Microsoft Office\Office15\WINWORD.EXE
User Name : Windows8\John Doe
Session ID : 1
PID : 0xBE4 (3044)
TID : 0x6DC (1756)
API Name : ntdll.NtCreateFile
ReturnAddress : 0x165EB24A
CalledAddress : 0x7729CE80
TargetAddress : 0x165EA820
StackPtr : 0x04ECF494
EMETが不快だと感じたものがわからないため、アプリケーションの構成でオフにすることはできません(つまり、EMETでのWordの特定の修正)。選択肢は次のようになります。 EAF
とEAF+
をオフにしたのは、EMETが以前に特に不満を言っていたためです(ストローをつかんでいるため、DEPはオフになっています)。
Wordで呼び出されたEMET呼び出し元の緩和策を特定するにはどうすればよいですか?
これらはおそらく関連しています: EMETを使用するとIE 10が「ファイルのアップロード」でクラッシュします 。ただし、リンクされた質問は、IEのファイルアップロードでEMETをトリガーします。
Win7 Prof.64ビットのWord2013(Office Home and Business 2013 v15.0.4779.1002)とEMET 5.5.5736.25442で同じ問題が発生しました。互換モードでdocxを開いたのですが、「FILE」に切り替えようとしました。 「それを変換するためのリボンで、Wordはすぐにクラッシュしました。
当初、アプリWINWORD.EXEの場合、EAF +とフォントを除くすべてがEMETでアクティブ化されていました。 これらのクラッシュを回避するために、Caller(ROP Caller Check)を追加で非アクティブ化するだけで済みました。