CVE-2020-16899: Microsoft Windows TCP/IP サービス拒否の脆弱性

CVSS スコア: 7.5

CVSS ベクター: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H/E:P/RL:O/RC:C

概要

10月13日、Microsoftは発表しました：Windows IPv6 スタックに重大な脆弱性があり、攻撃者が悪意を持って細工したパケットを送信すると、最新バージョンの Windows 10 および Windows Server 2019 で即座に BSOD（ブルースクリーン・オブ・デス）が発生します。この脆弱性は攻撃者にコード実行を許すものではないようですが、脆弱な Windows バージョンに対する大規模なサービス拒否攻撃に利用される可能性があります。より影響度の高い RCE バージョンの検出ロジックは CVE-2020-16898: "Bad Neighbor" にあります。

この文書は McAfee Advanced Threat Research によって作成されました。この脆弱性をより深く理解し、悪用から防御しようとしているネットワーク管理者およびセキュリティ担当者に貴重な洞察を提供することを目的としています。ここで作成されたシグネチャは、本番環境で使用する前にステージング環境で十分に検討および検証されるべきであり、対象となる展開環境に合わせた特定のチューニングが有効な場合があります。

ここに記載された情報は予告なく変更されることがあり、特定の状況や環境に対する情報の正確性や適用性についての保証や表明は一切なく、「現状のまま」、すべての欠陥を含んで提供され、自己責任で使用するものとします。さらに、いかなるシグネチャについても、パフォーマンスや有効性のベンチマークを保証することはできません。

脆弱性の説明

この脆弱性は、Windows IPv6 スタックが 1 つ以上の DNSSL オプションレコード（オプションタイプ = 31）を含む ICMPv6 ルーター広告（タイプ = 134）パケットを処理する際に発生し得る境界外読み取り（out-of-bounds read）に起因します。DNSSL レコードの目的は、その最後のフィールドに含まれる DNS 名前サフィックスの検索リストを提供することです。この検索リストは、ヌル終端された複数の DNS 名を連続して保持できるため、フィールド（したがってレコード全体）のサイズは大きく変動する可能性があります。これに対応するため、DNSSL オプションレコードには独自の長さ（Length）フィールドが含まれています。ただし、長さは 8 バイト単位でカウントされるため、検索リスト内のドメイン名の少なくとも 1 つには、レコードの 8 バイトアライメントを維持するための追加のヌルパディングが含まれる場合があります。この脆弱性は、これらのヌルの処理中に発生し得ます。

Windows IPv6 スタックは、検索リスト内の各ドメイン名に対して 256 バイトのバッファを割り当てます。RFC 1035 はドメイン名を 255 バイトに制限しているため、通常はドメイン名とそのヌル終端文字を格納するのに十分です。ただし、各ドメイン名の末尾にある後続のヌルを消費するコードには、オプション内の残りバイト数に等しい上限があり、これは 256 バイトを超える可能性があります。その結果、ヌル消費コードがバッファに割り当てられたバイト数よりも多くのバイトを誤って消費し、境界外読み取りが発生する可能性があります。バッファがメモリページの末尾に位置する場合、この OOB 読み取りにより BSOD が発生する可能性があります。

シグネチャ

この脆弱性に対する Suricata シグネチャは cve-2020-16899.rules にあり、以下のロジックを含んでいます：

alert icmp any any -> any any (msg:"Potential CVE-2020-16899 Exploit"; lua:cve-2020-16899.lua; sid:202016899; rev:1;)

対応する Lua スクリプトは cve-2020-16899.lua にあります。このスクリプトには、ICMPv6 レイヤーを適切に解析し、CVE-2020-16899 の潜在的な悪用を特定するために必要なロジックが含まれています。内容は次のとおりです：

ICMPv6 レイヤーの先頭を見つけたら、レイヤーの最初のバイトを検査して、ルーター広告 ICMPv6 パケットであることを確認します。そうでない場合は終了します。

Suricata のプリミティブは ICMPv6 オプションを解析するようには更新されていないため、単純に ICMPv6 レイヤーの 17 バイト目にジャンプします。オプションが存在する場合、そこがオプションの開始位置だからです（最初の 16 バイトは RFC 4443 による固定長フィールドです）。そこから、パケット内のバイトがなくなるまで各オプションをループ処理します。各オプションについて、まず最初のバイトを検査します。これはオプションタイプフィールドに対応します。DNSSL 以外のすべてのオプションは無視しますが、オプションタイプ = 31（DNSSL）の場合、長さ（オプションの 2 番目のバイト）が 35 以上であるかどうかを確認します。35 は脆弱性をトリガーするために必要な最小長です：

• 該当する場合、DNS 検索リストフィールドにジャンプし、そこに含まれる各 DNS 名の長さ（オプションのヌルパディングを含む）を計算します。テストにより、悪用には少なくとも 264 バイト（パディングを含む）の DNS 名が必要であることが判明したため、この条件と前述の他の条件を満たすパケットにフラグを立てます。
• 該当しない場合、次のオプションに移動します。長さは 8 バイト単位でカウントされるため、長さに 8 を掛け、そのバイト数だけ前方にジャンプして次のオプションの先頭に到達します（すでに消費した長さバイトを考慮して 1 を引きます）。