DNSpooq - dnsmasq 内に存在するの複数の脆弱性 (CVE-2020-25681、CVE-2020-25682、CVE-2020-25683、CVE-2020-25684、CVE-2020-25685、CVE-2020-25686、CVE-2020-25687)

エグゼクティブサマリー

Red Hat は、DNSpooq と名付けられた複数の問題が dnsmasq 内に存在することを認識しています。Dnsmasq は、プライベートネットワークや仮想化環境向けの DNS および DHCP などのネットワークサービスを提供する軽量なツールです。該当の問題は、dnsmasq によって提供される DNS (Domain Name System) サービスに存在します。dnsmasq クライアントシステムをある程度コントロールできるリモート攻撃者は、これを利用してユーザーを不適切なサイトにリダイレクトしたり、dnsmasq をホストしているマシン上でコードを実行したりできる可能性があります。

このうち、2 つの不具合 (CVE-2020-25681 および CVE-2020-25682) は、dnsmasq マシン上でコードをリモートで実行できることから、重大度が「重要な影響」と評価されています。CVE-2020-25683、CVE-2020-25684、CVE-2020-25685、CVE-2020-25686、および CVE-2020-25687 の重大度は「中程度の影響」と評価されています。

CVE-2020-25681、CVE-2020-25682、CVE-2020-25683、および CVE-2020-25687 では、DNSSEC がコンパイルされ、dnsmasq 設定で有効になっている必要があります。そのため、デフォルト以外の設定を使用する場合は、以下のバージョンの Red Hat 製品が影響を受けます。

• Red Hat Enterprise Linux 8

CVE-2020-25684、CVE-2020-25685、および CVE-2020-25686 によって DNS キャッシュへの攻撃が可能になり、被害を受けたユーザーは不適切なサイトにリダイレクトされる可能性があります。以下のバージョンの Red Hat 製品が影響を受けます。

• Red Hat Enterprise Linux 6

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 8

以下の Red Hat 製品は、Red Hat Enterprise Linux チャンネルから dnsmasq を取得するため、影響を受ける可能性があります。基礎になる Red Hat Enterprise Linux の dnsmasq パッケージが最新であることを確認し、詳細は libvirt のユースケースを参照するようにしてください。

• Red Hat OpenStack Platform 10

• Red Hat OpenStack Platform 13

• Red Hat Virtualization 4.3

• Red Hat Virtualization 4.4

• Red Hat OpenShift Container Platform 3.11

現在ご使用のシステムにこの不具合による脆弱性が存在するかどうかを判断するには、以下の「診断」セクションを参照してください。

テクニカルサマリー

dnsmasq の 7 つの問題は、2 つのグループに分類されます。

• dnsmasq が受信する DNS の返答を以前転送されたクエリーと一致する方法に存在する不具合 (CVE-2020-25684、CVE-2020-25685、および CVE-2020-25686)。

• 検証用の DNSSEC データを準備するコードのバッファーオーバーフローで構成される不具合 (CVE-2020-25681、CVE-2020-25682、CVE-2020-25683、および CVE-2020-25687)。

攻撃者が 2 つ目のグループの脆弱性を悪用するには、利用できる dnsmasq クライアントが必要となります。または、クライアントが一連の DNS クエリーを攻撃者が管理するドメインの dnsmasq に送信するための別の方法が必要になります。

最初のグループに分類された不具合は、主に DNS キャッシュポイズニング攻撃の実行を容易にするために使用されます。この攻撃は、dnsmasq を DNS サーバーとして使用するすべてのクライアントに影響し、攻撃を受けたエントリーの名前解決が不適切に行われます。不具合を連鎖させると、最短で数分後に攻撃が可能になります。

2 つ目のグループに分類された不具合では、DNSSEC を dnsmasq で有効にする必要があり、改ざんされた応答を転送されたクエリーに送信することで、DNSSEC データが検証される前に不具合が発生する可能性があります。

脆弱性によって、悪用の結果や影響は異なります。CVE-2020-25681 および CVE-2020-25682 は、ホストマシン上でコードがリモートで実行される可能性があるため、重大度は「重要な影響」と評価されました。CVE-2020-25683 および CVE-2020-25687 は、結果的に dnsmasq サービスがクラッシュするのみであるため、「中程度の影響」と評価されました。

dnsmasq はユーザーによって起動されませんが、libvert による自動実行が可能であるため、DNS サービスをゲスト仮想マシンに提供できることに注意してください。さらに、DNS をシステムに提供するために dnsmasq を使用するよう NetworkManager を設定することができます。

不具合の詳細は、「背景情報」を参照してください。

軽減策

CVE-2020-25684、CVE-2020-25685、および CVE-2020-25686 の影響は、dnsmasq キャッシュを無効にすると軽減することができます。これには、dnsmasq の呼び出し時に `--cache-size=0` を追加するか、dnsmasq 設定ファイル (デフォルトでは /etc/dnsmasq.conf) に `cache-size=0` の行を追加します。

Red Hat Enterprise Linux 8.3 と libvirt を virt:rhel モジュールで使用する場合、`virsh net-edit <network-name>` を使用し、https://libvirt.org/formatnetwork.html#elementsNamespaces を参照して、推奨オプション `cache-size=0` を追加します。

Red Hat Enterprise Linux 8.3 よりも古いバージョンを使用している場合は、libvirt によって生成された dnsmasq 設定をカスタマイズする方法はありません。dnsmasq を NetworkManager で実行している場合は、/etc/NetworkManager/dnsmasq.d/ に新しいファイルを作成し、`cache-size=0` を追加します。

いずれの場合も、キャッシュを無効にすることで、すべてのDNS クエリーがアップストリームサーバーに転送されるため、環境のパフォーマンスが低下する可能性があります。システムの環境に適する軽減策を判断してから、軽減策を適用してください。

CVE-2020-25681、CVE-2020-25682、CVE-2020-25683、および CVE-2020-25687 を軽減する唯一の既知の方法は、DNSSEC を完全に無効にすることです。これには、コマンドラインオプション `--dnssec` を削除するか、`dnssec` オプションを dnsmasq 設定ファイルから削除します。

dnsmasq の更新が利用可能になり次第、適用することが推奨されます。

技術情報

CVE-2020-25681

ヒープベースのバッファーオーバーフローは、DNSSEC データで検証される前の RRSet がソートされる方法で発見されました。ネットワーク上の攻撃者が DNS の返答を改ざん (有効として許可するなどして) できる場合、この不具合を悪用して任意データでヒープメモリーセグメントのバッファーオーバーフローを引き起こし、マシン上でコードを実行する可能性があります。

CVE-2020-25682

バッファーオーバーフローの脆弱性は、DNSSEC データで検証される前に dnsmasq が DNS パケットから名前を抽出する方法で発見されました。ネットワーク上の攻撃者が有効な DNS の返答を作成できる場合、この不具合を悪用して任意データでヒープに割り当てられたメモリーのバッファーオーバーフローを引き起こし、マシン上でコードを実行する可能性があります。この不具合は、rfc1035.c:extract_name() 関数に存在します。この関数は、バッファーで MAXDNAME*2 バイト利用できると仮定して、名前が示すメモリーにデータを書き込みます。しかし、コード実行パスによっては、ベースバッファーからオフセットが extract_name() に渡される可能性があり、実際にはバッファーに書き込めるバイト数が減らされる可能性があります。

CVE-2020-25683

ヒープベースのバッファーオーバーフローは、DNSSEC が有効な場合に受信した DNS エントリーを検証する前に dnsmasq で発見されました。リモートの攻撃者が有効な DNS の返答を作成できる場合、この不具合を悪用してヒープに割り当てられたメモリーでオーバーフローを引き起こす可能性があります。この不具合は、rfc1035.c:extract_name() の長さがチェックされないことが原因です。これを悪用すると、値が負のサイズの get_rdata() で memcpy() を実行し、dnsmasq がクラッシュすることで、サービス拒否 (DoS) が発生する可能性があります。

CVE-2020-25684

転送されたクエリーから返答を取得するとき、返答の宛先アドレス/ポートが保留中の転送されたクエリーによって使用される場合は dnsmasq によって forward.c:reply_query() がチェックされます。しかし、アドレス/ポートを使用して転送されたクエリーを取得しないため、ネットワーク上の攻撃者が返答を改ざんし、それが dnsmasq によって許可されるまでの試行回数を大幅に削減することが可能になります。この問題は、指定されるクエリーの属性をすべて使用して返答に一致する必要がある RFC5452 とは対照的です。この不具合により、攻撃者は DNS キャッシュポイズニング攻撃を実行することができます。CVE-2020-25685 または CVE-2020-25686 とともに悪用すると、攻撃の成功がより容易になります。

CVE-2020-25685

転送されたクエリーから返答を取得するとき、dnsmasq はクエリー名の脆弱なハッシュのみを使用して、返答と一致する転送されたクエリーである forward.c:reply_query() をチェックします。ハッシュが脆弱であるため (DNSSEC を使用せずに dnsmasq がコンパイルされた場合は CRC32、使用した場合は SHA-1)、パス外の攻撃者は同じハッシュを持つ異なるドメインを複数検出することが可能になります。よって、返答を改ざんし、それが dnsmasq によって許可されるまでの試行回数を大幅に削減することが可能になります。この問題は、返答の一致に使用しなければならないクエリーの属性の 1 つがクエリー名であることを指定する RFC5452 とは対照的です。この不具合を悪用すると、DNS キャッシュポイズニング攻撃の実行が可能になります。CVE-2020-25684 とともに悪用すると、攻撃の成功がより容易になります。

CVE-2020-25686

dnsmasq はクエリーの受信時に、名前が同じ既存の保留中リクエストをチェックせずに、新しいリクエストを転送します。デフォルトでは、最大 150 個の保留中のクエリーをアップストリームサーバーに送信できるため、同じ名前を持つクエリーは最大で 150 個になります。この不具合では、ネットワーク上のパス外の攻撃者が返答を改ざんし、それが dnsmasq によって許可されるまでの試行回数を大幅に削減することが可能になります。この問題は、RFC5452 の「Birthday Attacks」のセクションで言及されています。CVE-2020-25684 とともに悪用すると、攻撃の成功がより容易になります。

CVE-2020-25687

ヒープベースのバッファーオーバーフローは、DNSSEC が有効な場合に受信した DNS エントリーを検証する前に dnsmasq で発見されました。この不具合により、リモートの攻撃者が有効な DNS の応答を作成できる場合にヒープに割り当てられたメモリーでオーバーフローを発生させることができます。この不具合は、rfc1035.c:extract_name() の長さがチェックされないことが原因です。これを悪用すると、値が負のサイズの sort_rrset() で memcpy() を実行し、dnsmasq がクラッシュすることで、サービス拒否 (DoS) が発生する可能性があります。

背景情報

DNS (Domain Name System) は、主にドメイン名 (例: www.example.com) を IP アドレス (例: 127.0.0.1、2001:DB8::1) に変換するために使用されます。DNS は分散システムであり、ドメインや変換をすべて認識する単一ノードはありません。1 つの名前を解決するには、要求された名前を認識するネームサーバーに到達するまで、複数のサーバーから複数のクエリーおよび応答が必要になる可能性があります。このプロセス全体が DNS 解決プロセスと呼ばれます。

DNS には複数のセキュリティー制限があります。特に、関係するサーバーや他の外部攻撃者が改ざんされた返答を提供しないようにする保証はありません。主に、DNS の返答やクエリーでランダムな 16 ビット識別子を使用し、外部の攻撃者による通信の乗っ取りを防ぐためにランダムな UDP ソースポートを使用します。DNSSEC は、DNS 上部に層を追加し、DNS データにデータの送信元の認証と整合性の保証を提供するために開発されました。DNSSEC を使用すると、署名は他のシステムで検証が可能な実際の DNS データに関連付けられ、提供される返答がそのドメインの権威サーバーから送信され、不正に改ざんされていないようにします。DNSSEC の検証を適用すると、DNS キャッシュポイズニング攻撃を防ぐことができますが、その採用は現在限定的です。

dnsmasq は、小規模なネットワークにネットワークインフラストラクチャーを提供する軽量ツールで、特に DNS および DHCP サービルを提供します。dnsmasq の DNS サービスは主にフォワーダーとして使用され、クライアントから DNS クエリーを取得し、事前設定されたアップストリーム DNS サーバーに転送します。さらに、返答をキャッシュすることで、次回同じまたは別のクライアントによって同じクエリーが行われたときに、再度アップストリームサーバーに問い合わせをせずに返答を即座に返せるようにします。DNSSEC の検証を実行するように設定することもできます。

dnsmasq クライアントをある程度コントロールできる攻撃者が CVE-2020-25684、CVE-2020-25685、および CVE-2020-25686 を悪用すると、DNS の返答を改ざんし、事前設定されたアップストリーム DNS サーバーから送信されたものであるとして dnsmasq を受け入れさせることが可能になります。キャッシュが有効である場合 (デフォルトの動作)、これらの不正な返答はキャッシュに保存され、他のクライアントにも提供されるため、悪意のあるサイトにリダイレクトされる可能性があります。この問題は DNS キャッシュポイズニング攻撃と呼ばれます。これにより、16ビットの識別子と、特定の DNS クエリーに使用される特定の UDP ポートが的中するまでの試行回数が大幅に減少します。攻撃が決定論的ではなく、正しい値の組み合わせを推測するのにある程度の時間を必要とすることを考えると、攻撃者が選択したドメインに対して多数の DNS クエリーの実行を開始するには dnsmasq クライアントが必要になります (たとえば、被害を受けたユーザーが DNS 解決プロセスが発生する悪意のある Web サイトにブラウザーでアクセスした場合、攻撃者がクライアントシステムを制御できるか、不正アクセスできる場合)。

dnsmasq が DNSSEC を使用するように設定されると、CVE-2020-25681、CVE-2020-25682、CVE-2020-25683、および CVE-2020-25687 に対して脆弱になります。dnsmasq クライアントをある程度コントロールできるリモートの攻撃者がこの不具合を悪用すると、dnsmasq を実行しているシステムでコードをリモート実行して、クラッシュすることができるため、dnsmasq クライアントで DoS (サービス拒否) が発生し、ドメイン名を解決できなくなります。

製品への影響

Red Hat Enterprise Linux 8

デフォルトでは、dnsmasq systemd サービスは無効になっており、NetworkManager は dnsmasq systemd サービスを使用するように設定されていません。

Red Hat Enterprise Linux 8 に同梱されたバージョンの dnsmasq は、本記事で発表されたすべての CVE の影響を受けます。しかし、Red Hat Enterprise Linux 8 のデフォルト設定では、DNSSEC が有効でないため、CVE-2020-25681、CVE-2020-25682、CVE-2020-25683、および CVE-2020-25687 の影響を受けません。

Red Hat Enterprise Linux 7 / Red Hat Enterprise Linux 6

デフォルトでは、dnsmasq systemd サービスは無効になっており、NetworkManager は dnsmasq systemd サービスを使用するように設定されていません。

Red Hat Enterprise Linux 6 および 7 に同梱されたバージョンの dnsmasq は、CVE-2020-25684、CVE-2020-25685、および CVE-2020-25686 のみの影響を受けます。

Red Hat Enterprise Linux 6 および 7 では、DNSSEC が dnsmasq パッケージでコンパイルされないため、他の CVE の影響を受けません。

libvirt のユースケース

dnsmasq は、明示的に無効にしない限り、システムリゾルバーをアップストリーム DNS サーバーとして使用して、DNS サービスを libvirt ゲストに提供するために使用されます。ゲストシステムを制御できる攻撃者またはゲストシステムを操って複数の DNS クエリーを攻撃者が制御するドメインに対して実行できる攻撃者は、CVE-2020-25684、CVE-2020-25685、および CVE-2020-25686 を悪用して dnsmasq キャッシュを攻撃し、同じ仮想ネットワークに接続するすべてのゲストに影響を与えることができます。DNSSEC が手動で設定されていなければ、libvirt で使用される dnsmasq は CVE-2020-25681、CVE-2020-25682、CVE-2020-25683、および CVE-2020-25687 に対して脆弱ではありません。

サービスへの影響

Red Hat OpenShift Online、OpenShift Dedicated、Microsoft Azure Red Hat OpenShift を含む OpenShift v3 クラスターすべて:

dnsmasq は OpenShift Dedicated v3 で使用されています。OpenShift v3 クラスターで使用される dnsmasq は、Red Hat Enterprise Linux 7 パッケージに含まれ、v3 クラスターは DNSSEC の不具合 (CVE-2020-25681、CVE-2020-25682、CVE-2020-25683、および CVE-2020-25687) による影響を受けません。

DNSSEC 以外の不具合 (CVE-2020-25684、CVE-2020-25685、および CVE-2020-25686) については、OpenShift 3 サービスは Red Hat Enterprise Linux 7 に含まれるパッケージを使用するため、影響を受けます。各ノードは dnsmasq を使用し、ノードの DNS キャッシュへの攻撃を防止する保護対策はありません。

Red Hat はこの脆弱性を軽減するために、サービスの更新を行います。 dnsmasq を使用している場合、更新がリリースされるまで dnsmasq 脆弱性を悪用したキャッシュポイズニング攻撃からシステムを守るために、dnsmasq の呼び出し時に --cache-size=0 を明示的に設定してください。 サービスが libvert (オープンソースの API) を介して dnsmasq を実行している場合、virsh net-edit <network-name> を使用して cache-size=0 を更新できます。 

OpenShift Dedicated クラスターを含む OpenShift v4 クラスターすべて:

OpenShift Dedicated v4 では、dnsmasq の代わりに DNS operator (CoreDNS を使用) が使用されます。OpenShift v4 クラスターは、dnsmasq の不具合の影響を受けません。v4 では dnsmasq を使用するクラスターが存在しないことが確認されています。

各 CVE の影響を受ける Red Hat の製品

影響を受ける製品の更新

影響のあるバージョンの Red Hat 製品をご使用のお客様は、エラータが入手可能になり次第、該当製品を更新することが強く推奨されます。利用可能な更新を早急に適用し、適切であると思われる軽減策を有効にしてください。

[1] 更新の公開後にアドバイザリー/更新のリンクが追加されます。

[2] Red Hat Enterprise Linux Extended Update Support サブスクリプションとは何ですか?

[3] Advanced mission critical Update Support (AUS) とは何ですか?

[4] Red Hat Enterprise Linux for SAP Solutions サブスクリプションの概要

影響を受ける可能性のある製品およびコンテナー

以下の製品およびコンテナーは、別の製品から影響を受けるパッケージを使用します。 Red Hat のコンテナーは、本問題の影響を直接受けませんが、そのセキュリティーはベースイメージの整合性および更新に依存しています (RHEL パッケージの更新など)。Red Hat は、最新バージョンのコンテナーイメージを使用することを推奨します。Red Hat Container Catalog の一部である Container Health Index を使用すると、常に Red Hat コンテナーのセキュリティー状態を確認できます。

診断

以下の脆弱性検出スクリプトを使用すると、現在ご使用のシステムにこの不具合による脆弱性が存在するかどうかを判断できます。正規のスクリプトであることを確認する場合は、GPG 分離署名 もダウンロードします。検証にGPG 署名を使用する方法 と手順は、カスタマーポータルで確認できます。

よくある質問:

問: プライベートネットワークで DNS を提供するために dnsmasq を使用する場合、システムはこれらの不具合に対して脆弱になりますか。

答: 攻撃には基本的な DNS の保護機能を迂回するための推測が必要となるため、攻撃者はプライベートネットワーク内部から脆弱な dnsmasq インスタンスに大量の DNS クエリーを送信する必要があります。DNS クエリーが発生する状況は、ネットワーク上のシステムを完全に制御できる場合や、ネットワークに接続するユーザーがメールまたは Web サイトを開くように誘導する場合など、複数あります。十分な数の DNS クエリーを送信できれば、プライベートネットワーク上でもこの不具合を悪用することが可能です。

問: システムが libvirt を使用する場合、これらの不具合を利用するとゲストからホストへエスケープできますか。

答: これらの不具合を悪用して攻撃を開始するには、ゲストの 1 つを利用する必要があります。攻撃者がゲストシステムから dnsmasq へ複数の DNS クエリーを開始できる場合、本記事で発表された不具合を悪用してそのキャッシュを攻撃することが可能です。libvirt で使用されるように DNSSEC が dnsmasq で手動設定された場合 (デフォルトではない設定)、ホストマシンでもコードを実行したり、dnsmasq サーバーをクラッシュする可能性があります。

問: dnsmasq パッケージのアップグレード後にシステムが脆弱にならないようにするには、どの手順が必要ですか。

答: 稼働中の dnsmasq のインスタンスをすべて再起動する必要があります。最も簡単な方法は、仮想ホストやゲストを含め、dnsmasq が実行されているすべてのマシンを再起動することです。dnsmasq インスタンスは libvirt や他のシステムコンポーネントによる実行が可能であるため、これらのコンポーネントを再起動する必要があります。リブートせずにこれらのインスタンスを再起動する場合は、コンポーネントごとに異なる手順を行う必要があります。たとえば、dnsmasq を使用するすべての libvirt ネットワークを再起動し、該当する仮想マシンに再接続する必要があります。これは、複雑な手順であり、実稼働で大きな問題が発生する可能性があるため、それぞれの環境に合わせて個別にテストする必要があります。

問: dnsmasq がシステムにインストールされていても、実行されていない (または有効になっていない) 場合は、軽減策や更新を適用する必要はありますか。

答: dnsmasq パッケージがシステムにインストールされていれば、後に dnsmasq を有効にした場合に、これらの不具合に対して脆弱になったり、脆弱になるリスクがあります。該当の軽減策を適用し、dnsmasq パッケージをできるだけ早く更新することが推奨されます。

謝辞

Red Hat はこの脆弱性を報告した Moshe Kol 氏および Shlomi Oberman 氏 (JSOF) に感謝いたします。

参考資料

JSOF による DNSpooq に関する記事

GPG を使用して Product Security の署名済みコンテンツを検証する方法