Windows Updateは適切な更新サイクルで――CredSSP脆弱性対策について：山市良のうぃんどうず日記（127）（1/2 ページ）

山市良のうぃんどうず日記］

“初物”にはやっぱりリスクが伴う

　前回は「Windows 10 April 2018 Update（バージョン1803、ビルド17134.1）」のリリースに合わせ、特別版をお送りしました。自分に都合の良いタイミングで、自分主導でアップグレードすること、そしてまだWindows 10 バージョン1803にアップグレードしていない（Windows Updateで検出されない）場合は、まず情報収集することが大事であることをお伝えしました。

　新バージョンのリリース直後は隠れた不具合が多数含まれている可能性があり、いち早く飛びつく場合は“失敗のリスク”をある程度覚悟しておかなければなりません。何の問題もなく成功し、快適なWindows 10生活を送れる人もいれば、失敗の連続に時間と労力をとられる人もいます。特に、万が一に備えたフルバックアップは大事なことです。

　Windows 10 バージョン1803は、正式リリースから約1週間というところで、「Intel SSD 600p」シリーズまたは「Intel SSD Pro 6000p」シリーズを搭載したデバイス（PC）をWindows 10 バージョン1803にアップグレードしようとすると、“再起動時またはシステム停止後にUEFI（Unified Extensible Firmware Interface）設定画面に入る動作が繰り返される”という重大な問題が報告されています。

　筆者はこの問題を、2018年5月8日（米国時間）リリースのWindows 10 バージョン1803の累積更新プログラム「KB4103721」のサポート情報「Known issues in this update（この更新プログラムの既知の問題）」として、5月10日になって追記されたことで知りました。本稿執筆時点（2018年5月11日）では、Windows Updateによる対象デバイスへの機能更新の配布は停止されています。問題が発生したPCは、Windows 10 バージョン1709以前に戻し、問題が修正されるのを待つ以外にないようです。

• May 8, 2018−KB4103721（OS Build 17134.48）［英語］（Microsoft Support）

　“Windows 10はSSDじゃないと、とても使い物にならない”（Windows Updateに時間がかかるなど）という意見を目にしたことがありますが、その人のPCは大丈夫だったのか少し気になりました。また、一部の環境では（Intel SSDとは関係なく）、Windows 10 バージョン1803向けに初めて提供された累積的な品質更新プログラムの影響で、PCが起動できなくなる問題がユーザーフォーラムなどで報告されています。まだWindows 10 バージョン1803にアップグレードしていない場合は、もうしばらく様子を見た方が無難かもしれません。

　また、アップグレードして今のところ問題がなくても、しばらくして不具合に気付くことがあるかもしれません。Windows 10 バージョン1709以前のバックアップ（システムイメージ）がある場合は、しばらく保持しておくことをお勧めします。安定しているようだからと、Windows 10 バージョン1803のバックアップで上書きしてしまうと後悔することになるかもしれません。例えば、32bit（x86）版のWindows 10 バージョン1803には不具合があり、システムイメージの作成が「RPCサーバーを利用できません。（0x800706BA）」で失敗することを確認しています。

• Windows 10 ver 1803のシステムイメージの作成失敗（x86のみ）（筆者の個人ブログ：山市良のえぬなんとかわーるど）

3月から開始され、5月に完了した、CredSSPの脆弱性対策

　リリース直後にインストールすることのリスクは、Windows 10の新バージョン（ビルド）へのアップグレードである「機能更新プログラム」だけでなく、毎月の第二火曜日（日本ではその翌日の水曜日）やその間に提供される「品質更新プログラム」にもいえることです。Windows 10 Pro以上のエディションであれば、「Windows Update for Business（WUfB）」や企業の「Windows Server Update Services（WSUS）」を利用して更新のタイミングを調整できるので、リスクをある程度軽減できます。残念ながら、Windows 10 Homeエディションにはそのための機能はありません。

　更新のタイミングを調整できるといっても、いつまでも更新しない状態を続けるのは、セキュリティ問題を放置することになるので避けるべきです。Windows Update for Businessには「更新の一時停止」という機能がありますが、この機能を使って更新をストップできる時間幅は「最大35日間」です。Microsoftはおそらく、この35日間を最大の更新間隔と想定しており、この想定に基づいて動いているはずです（更新プログラム自身の不具合の改修や段階的な仕様変更など）。

　この想定に基づいて考えるとしっくりくる事例が、2018年3月に公開された以下のセキュリティアドバイザリで説明されている「CredSSP（Credential Security Support Provider）プロトコルの脆弱（ぜいじゃく）性問題」への対策でした。CredSSPを使用するものの1つに、リモートデスクトップ接続の「ネットワークレベル認証（NLA）」があります。

• CVE-2018-0886｜CredSSPのリモートでコードが実行される脆弱性（Microsoft セキュリティ TechCenter）

　この脆弱性は、悪用される可能性は低く、サービス拒否（Denial of Service：DoS）攻撃の対象になるものではありませんが、現在サポート対象のWindows全て（Windows 7、Windows 8.1、Windows 8.1 RT、Windows Server 2008以降のWindows Server）が影響を受けるものです。どのような脆弱性なのか気になる方は、上記のセキュリティアドバイザリで確認してください。

　この脆弱性を緩和する対策は、2018年3月の定例更新の累積的な品質更新プログラム（Windows 10／Windows Server 2016以降の「累積更新プログラム」、Windows 8.1／Windows Server 2012 R2以前の「セキュリティマンスリー品質ロールアップ」）として初めて提供されました。

　しかし、新しいポリシーとして追加された「Encryption Oracle Remediation」（5月の累積的な品質更新プログラム以降は「暗号化オラクルの修復」）というポリシーを構成しない限り、CredSSPの挙動が変化することもなければ、脆弱性が緩和されることもありませんでした。この対策は、4月の累積的な品質更新プログラムにも、累積的なので当然のことながら含まれます。なお、「暗号化オラクルの修復／Encryption Oracle Remediation」という名称は、CVE-2018-0886の脆弱性に由来するものだとは思いますが、詳しいところは分かりません。

　しかしながら、「暗号化オラクルの修復（Encryption Oracle Remediation）」ポリシーが未構成の場合の既定が、3月、4月の更新の時点では「脆弱（Vulnerable）」だったものが、5月の更新で「緩和（Mitigated）」に変更されました。クライアント側が5月以降の更新で最新になってからは、サーバ（Windows Serverではなく、接続先という意味）側が3月以降に更新されていれば、CredSSPの脆弱性が自動的に緩和されるようになりました。一方で、5月以降、リモートデスクトップ接続が見たこともないエラーメッセージを表示して失敗するという現象に遭遇する可能性も出てきました（画面1）。

画面1　5月以降の品質更新の影響で、以前は接続できていたリモートデスクトップ接続がこのようなエラーで失敗する場合がある（左はWindows 8.1以降、右はWindows 7）。これは、CredSSPの脆弱性対策の効果（安全性確保のため）

　CredSSPの脆弱性への対応措置は、3月の更新から段階的に行われたものであり、Microsoftが想定している更新間隔（最大35日）内に更新されていれば、接続に失敗するという影響を受けることはありません。この変更については、3月に公開されたサポート情報「KB4093492」で予告されていました。また、5月初めには、日本マイクロソフトのサポートチームからも詳細な説明が公開されました。しかし、サポート情報や公式ブログによる発信だけでは周知されるのは難しかったでしょう。

• CVE-2018-0886のCredSSPの更新プログラム（Microsoft サポート）
• 2018年5月の更新プログラム適用によるリモートデスクトップ接続への影響（Microsoft Japan Windows Technology Support）

　以下の表1にリモートデスクトップ接続について、CredSSPの脆弱性への対応措置が与える影響をまとめました。3月または4月の更新、5月の更新の適用状況と、「暗号化オラクルの修復」ポリシーの構成（または未構成のときの既定値）の組み合わせにおける、接続の可否および脆弱性の状態を示しています。

表1　クライアントとサーバの両方が5月以降の更新でパッチ済みであれば、ポリシーを構成しなくても、その接続はCredSSPの脆弱性に対して安全（緑の枠）。サーバ側が未パッチの場合、安全性を確保するため接続はブロックされる（赤の枠）

　3月の更新以降、「暗号化オラクルの修復」ポリシーを構成することで、表1が示すように、CredSSPの脆弱性に対してさまざまなセキュリティ強化策を講じることができるようになりました。

　しかし、表1で注目してほしいのは“ポリシーが未構成時の既定値の影響”です。4月の更新以前は明示的にポリシーを構成しない限り、何の影響もありませんでした（脆弱性は解決されていない状態）。5月の更新により、ポリシーが未構成時の既定値が「緩和（Mitigated）」に変更されたことで、クライアントとサーバの両方が最新状態に更新されていれば脆弱性の影響を受けることなく、安全に接続するようになります（表1の緑の枠で囲んだところ）。一方、サーバ側に3月以降の更新が適用されていない場合は、脆弱性を回避するために接続がブロックされるようになります（表1の赤の枠で囲んだところ）。この部分が前出の≪画面1＞のエラーになったところです。