MS14-045 と Avast! の相性が若干 悪い理由 を推測してみた・ω・

マイクロソフト セキュリティ情報 MS14-045 - 重要
マイクロソフト社、8 月に公開した定例アップデートを撤回

このブルースクリーンの問題は、Windows のフォントキャッシュファイルが適切に処理されないために発生しているようです。また、この問題は起動中に発生するため、再起動を繰り返しても Windows を起動できなります。

(確かに、MS14-045 を適用した後には、再起動が必要となっています)。

0x50 PAGE_FAULT_IN_NONPAGED_AREA というエラーメッセージが表示される場合、こ定型文の問題の影響を受けています。

テスト段階でこの問題が明らかにならなかった理由は、特定の状況下でのみこの問題が発生するためです。

OpenType フォント (OTF) ファイルが、標準以外のフォントディレクトリにインストールされており、完全修飾されたファイル名でレジストリに登録されている場合に問題が発生します。

たとえば、Windows 8.1 のデフォルトのインストール環境では、TTF (TrueType フォント), TTC (TrueType フォントコレクション) および FON (Windows ビットマップフォント) ファイルのみが含まれており、パス名は登録されていません。

当初、 Avast! と MS14-045 の相関が深く疑われていたのですが、一応嫌疑は晴れたことになっています。

ですが、本当に関係ないのでしょうか?
さて、ここで、 Avast! 8 のフォント問題の記事を思い出してみましょう ・ω・

Avast! 8 が 文字化けするのに フォントリンクが無効な件

Avastは、Open フォント(ただし OTFではなく TTF)を独自フォルダにエイリアスして取り込んでるのです。Windows 2000では、そのような環境でフォントリンクを使うことを想定されていないので、文字化けが起こるという内容でした

きわめて類似した事例です・ω・

次に、 Symantec の改変対策の記事を思い出してみましょう。

【ハッキング実証実験】Symantecの改変対策がザルなのを証明

推測ですが。以下の順番でシーケンスが走るのだと思われます。

・削除をスケジューリング ←改変防止機能がチェックしていない
・最初の再起動
・ドライバのロード
・ファイルのスケジュールによる削除
・改変防止機能が起動
・ドライバが正常に動作しているため、異変を検出できない。
・2回目の再起動
・ドライバファイルがないのでロード失敗
・ドライバの無効化に成功!

セキュリティ関係のドライバの起動の後で、MoveFileEx の遅延 ファイルの置換が発生すると推測しました。

・Windows Update がファイルの置換をスケジューリング
・最初の再起動
・ドライバのロード ( System APIは古いドライバが呼ばれる)
・ファイルのスケジュールによるSystem APIの置換
・古いFont APIからの起動のため、とりあえず問題ない。
・2回目の再起動
・ドライバのロード ( System APIは新しいドライバが呼ばれる)
・突然のBSoD!

2回目の再起動で不具合が発生する理由は、こんな感じじゃないかなと思っています・ω・

要するにフォントの複雑なライセンス利権の問題で、こういうトリッキーな導入をしたのが悲劇の始まりだったというわけですね ・ω・ なむなむ。

Avast!や Adobe にこういった設定が見受けられるので、不具合が起こりやすいということなんでしょうね。
(Avast!の場合は、OTFではなくTTFなので発生しにくいのだと思われ)

・2回再起動してBSoDが発生する場合は、セキュリティソフトが深く関係していることが多い。
・今回は、2回再起動で発生する人が散見された。

だから、全く無関係だったとは私は言えないと思うのですよ・ω・

MS14-045 と Avast! の相性が若干 悪い理由 を推測してみた・ω・

マイクロソフト セキュリティ情報 MS14-045 - 重要
マイクロソフト社、8 月に公開した定例アップデートを撤回

このブルースクリーンの問題は、Windows のフォントキャッシュファイルが適切に処理されないために発生しているようです。また、この問題は起動中に発生するため、再起動を繰り返しても Windows を起動できなります。

(確かに、MS14-045 を適用した後には、再起動が必要となっています)。

0x50 PAGE_FAULT_IN_NONPAGED_AREA というエラーメッセージが表示される場合、こ定型文の問題の影響を受けています。

テスト段階でこの問題が明らかにならなかった理由は、特定の状況下でのみこの問題が発生するためです。

OpenType フォント (OTF) ファイルが、標準以外のフォントディレクトリにインストールされており、完全修飾されたファイル名でレジストリに登録されている場合に問題が発生します。

たとえば、Windows 8.1 のデフォルトのインストール環境では、TTF (TrueType フォント), TTC (TrueType フォントコレクション) および FON (Windows ビットマップフォント) ファイルのみが含まれており、パス名は登録されていません。

当初、 Avast! と MS14-045 の相関が深く疑われていたのですが、一応嫌疑は晴れたことになっています。

ですが、本当に関係ないのでしょうか?
さて、ここで、 Avast! 8 のフォント問題の記事を思い出してみましょう ・ω・

Avast! 8 が 文字化けするのに フォントリンクが無効な件

Avastは、Open フォント(ただし OTFではなく TTF)を独自フォルダにエイリアスして取り込んでるのです。Windows 2000では、そのような環境でフォントリンクを使うことを想定されていないので、文字化けが起こるという内容でした

きわめて類似した事例です・ω・

次に、 Symantec の改変対策の記事を思い出してみましょう。

【ハッキング実証実験】Symantecの改変対策がザルなのを証明

推測ですが。以下の順番でシーケンスが走るのだと思われます。

・削除をスケジューリング ←改変防止機能がチェックしていない
・最初の再起動
・ドライバのロード
・ファイルのスケジュールによる削除
・改変防止機能が起動
・ドライバが正常に動作しているため、異変を検出できない。
・2回目の再起動
・ドライバファイルがないのでロード失敗
・ドライバの無効化に成功!

セキュリティ関係のドライバの起動の後で、MoveFileEx の遅延 ファイルの置換が発生すると推測しました。

・Windows Update がファイルの置換をスケジューリング
・最初の再起動
・ドライバのロード ( System APIは古いドライバが呼ばれる)
・ファイルのスケジュールによるSystem APIの置換
・古いFont APIからの起動のため、とりあえず問題ない。
・2回目の再起動
・ドライバのロード ( System APIは新しいドライバが呼ばれる)
・突然のBSoD!

2回目の再起動で不具合が発生する理由は、こんな感じじゃないかなと思っています・ω・

要するにフォントの複雑なライセンス利権の問題で、こういうトリッキーな導入をしたのが悲劇の始まりだったというわけですね ・ω・ なむなむ。

Avast!や Adobe にこういった設定が見受けられるので、不具合が起こりやすいということなんでしょうね。
(Avast!の場合は、OTFではなくTTFなので発生しにくいのだと思われ)

・2回再起動してBSoDが発生する場合は、セキュリティソフトが深く関係していることが多い。
・今回は、2回再起動で発生する人が散見された。

だから、全く無関係だったとは私は言えないと思うのですよ・ω・

おすすめ

1件の返信

  1. jyamira1 より:

    今回の一番のネックは、権限/特権/セキュリティー記述子などではという気がしています。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です