RFC 9267 - Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9267.html
タイトル : RFC 9267 - ドメイン名システム（DNS）リソースレコード（RR）処理に関連する一般的な実装アンチパターン
翻訳編集 : 自動生成

[要約] RFC 9267は、DNSクライアント実装に関連する一般的な脆弱性を記述し、DoSやRCE攻撃を引き起こす可能性があります。RFC 1035の違反が該当する場合に言及しています。

Independent Submission                                     S. Dashevskyi
Request for Comments: 9267                                 D. dos Santos
Category: Informational                                       J. Wetzels
ISSN: 2070-1721                                                  A. Amri
                                                  Forescout Technologies
                                                               July 2022

Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing

ドメイン名システム（DNS）リソースレコード（RR）処理に関連する一般的な実装アンチパターン

Abstract

概要

This memo describes common vulnerabilities related to Domain Name System (DNS) resource record (RR) processing as seen in several DNS client implementations. These vulnerabilities may lead to successful Denial-of-Service and Remote Code Execution attacks against the affected software. Where applicable, violations of RFC 1035 are mentioned.

このメモは、いくつかのDNSクライアントの実装で見られるように、ドメイン名システム（DNS）リソースレコード（RR）処理に関連する一般的な脆弱性について説明します。これらの脆弱性は、影響を受けるソフトウェアに対するサービス拒否およびリモートコード実行攻撃の成功につながる可能性があります。該当する場合、RFC 1035の違反が言及されています。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9267.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9267で取得できます。

著作権表示

著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。

Table of Contents

   1.  Introduction
   2.  Compression Pointer and Offset Validation
   3.  Label and Name Length Validation
   4.  Null-Terminator Placement Validation
   5.  Response Data Length Validation
   6.  Record Count Validation
   7.  Security Considerations
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

Major vulnerabilities in DNS implementations recently became evident and raised attention to this protocol as an important attack vector, as discussed in [SIGRED], [SADDNS], and [DNSPOOQ], the latter being a set of 7 critical issues affecting the DNS forwarder "dnsmasq".

DNS実装の主要な脆弱性は最近明らかになり、[Sigred]、[Saddns]、および[dnspooq]で議論されているように、重要な攻撃ベクターとしてこのプロトコルに注意を向けました。dnsmasq」。

The authors of this memo have analyzed the DNS client implementations of several major TCP/IP protocol stacks and found a set of vulnerabilities that share common implementation flaws (anti-patterns). These flaws are related to processing DNS resource records (RRs) (discussed in [RFC1035]) and may lead to critical security vulnerabilities.

このメモの著者は、いくつかの主要なTCP/IPプロトコルスタックのDNSクライアント実装を分析し、共通の実装の欠陥（アンチパターン）を共有する一連の脆弱性を見つけました。これらの欠陥は、DNSリソースレコード（RRS）の処理に関連しており（[RFC1035]）、重大なセキュリティの脆弱性につながる可能性があります。

While implementation flaws may differ from one software project to another, these anti-patterns are highly likely to span multiple implementations. In fact, one of the first "Common Vulnerabilities and Exposures" (CVE) documents related to one of the anti-patterns [CVE-2000-0333] dates back to the year 2000. The observations are not limited to DNS client implementations. Any software that processes DNS RRs may be affected, such as firewalls, intrusion detection systems, or general-purpose DNS packet dissectors (e.g., the DNS dissector in Wireshark; see [CVE-2017-9345]). Similar issues may also occur in DNS-over-HTTPS [RFC8484] and DNS-over-TLS [RFC7858] implementations. However, any implementation that deals with the DNS wire format is subject to the considerations discussed in this document.

実装の欠陥はソフトウェアプロジェクトによって異なる場合がありますが、これらのアンチパターンは複数の実装にまたがる可能性が非常に高くなります。実際、アンチパターンの1つ[CVE-2000-0333]に関連する最初の「共通の脆弱性と露出」（CVE）文書の1つは、2000年にさかのぼります。ファイアウォール、侵入検知システム、または汎用DNSパケット分析など、DNS RRSを処理するソフトウェアは、影響を受ける可能性があります（例：WiresharkのDNS分離器; [CVE-2017-9345]を参照）。同様の問題は、DNS-Over-HTTPS [RFC8484]およびDNS-Over-TLS [RFC7858]の実装でも発生する可能性があります。ただし、DNSワイヤ形式を扱う実装は、このドキュメントで説明されている考慮事項の対象となります。

[DNS-COMPRESSION] and [RFC5625] briefly mention some of these anti-patterns, but the main purpose of this memo is to provide technical details behind these anti-patterns, so that the common mistakes can be eradicated.

[DNS-Compression]および[RFC5625]は、これらのアンチパターンの一部に簡単に言及していますが、このメモの主な目的は、これらのアンチパターンの背後に技術的な詳細を提供して、一般的な間違いを根絶することができることです。

We provide general recommendations on mitigating the anti-patterns. We also suggest that all implementations should drop malicious/ malformed DNS replies and (optionally) log them.

アンチパターンの緩和に関する一般的な推奨事項を提供します。また、すべての実装は悪意のある/奇形のDNS応答を削除し、（オプションで）それらを記録することをお勧めします。

2. Compression Pointer and Offset Validation

2. 圧縮ポインターとオフセット検証

[RFC1035] defines the DNS message compression scheme that can be used to reduce the size of messages. When it is used, an entire domain name or several name labels are replaced with a (compression) pointer to a prior occurrence of the same name.

[RFC1035]は、メッセージのサイズを減らすために使用できるDNSメッセージ圧縮スキームを定義します。使用すると、ドメイン名全体またはいくつかの名前のラベルが、同じ名前の事前に発生する（圧縮）ポインターに置き換えられます。

The compression pointer is a combination of two octets: the two most significant bits are set to 1, and the remaining 14 bits are the OFFSET field. This field specifies the offset from the beginning of the DNS header, at which another domain name or label is located:

圧縮ポインターは2つのオクテットの組み合わせです。2つの最も重要なビットは1に設定され、残りの14ビットはオフセットフィールドです。このフィールドは、DNSヘッダーの先頭からオフセットを指定し、別のドメイン名またはラベルが配置されています。

   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   | 1  1|                OFFSET                   |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The message compression scheme explicitly allows a domain name to be represented as one of the following: (1) a sequence of unpacked labels ending with a zero octet, (2) a pointer, or (3) a sequence of labels ending with a pointer.

メッセージ圧縮スキームでは、ドメイン名を次のいずれかとして明示的に表現できます。（1）ゼロオクテットで終わる1つの開梱ラベルのシーケンス、（2）ポインター、または（3）ポインターで終わるラベルのシーケンス。

However, [RFC1035] does not explicitly state that blindly following compression pointers of any kind can be harmful [DNS-COMPRESSION], as we could not have had any assumptions about various implementations that would follow.

ただし、[RFC1035]は、あらゆる種類の圧縮ポインターに盲目的に追跡することは有害である可能性があることを明示的に述べていません[DNS圧縮]。

Yet, any DNS packet parser that attempts to decompress domain names without validating the value of OFFSET is likely susceptible to memory corruption bugs and buffer overruns. These bugs make it easier to perform Denial-of-Service attacks and may result in successful Remote Code Execution attacks.

しかし、オフセットの値を検証せずにドメイン名を解凍しようとするDNSパケットパーサーは、メモリの腐敗バグやバッファーオーバーランの影響を受けやすい可能性があります。これらのバグにより、サービス拒否攻撃を容易にすることができ、リモートコード実行攻撃が成功する可能性があります。

Pseudocode that illustrates a typical example of a broken domain name parsing implementation is shown below (Figure 1):

壊れたドメイン名解析の実装の典型的な例を示す擬似コードを以下に示します（図1）。

    1: decompress_domain_name(*name, *dns_payload) {
    2:
    3:   name_buffer[255];
    4:   copy_offset = 0;
    5:
    6:   label_len_octet = name;
    7:   dest_octet = name_buffer;
    8:
    9:   while (*label_len_octet != 0x00) {
   10:
   11:      if (is_compression_pointer(*label_len_octet)) {
   12:          ptr_offset = get_offset(label_len_octet,
                                           label_len_octet+1);
   13:          label_len_octet = dns_payload + ptr_offset + 1;
   14:      }
   15:
   16:      else {
   17:          length = *label_len_octet;
   18:          copy(dest_octet + copy_offset,
                           label_len_octet+1, *length);
   19:
   20:         copy_offset += length;
   21:          label_len_octet += length + 1;
   22:      }
   23:
   24:   }
   25: }

Figure 1: A Broken Implementation of a Function That Is Used for Decompressing DNS Domain Names (Pseudocode)

図1：DNSドメイン名の減圧に使用される関数の壊れた実装（Pseudocode）

Such implementations typically have a dedicated function for decompressing domain names (for example, see [CVE-2020-24338] and [CVE-2020-27738]). Among other parameters, these functions may accept a pointer to the beginning of the first name label within an RR ("name") and a pointer to the beginning of the DNS payload to be used as a starting point for the compression pointer ("dns_payload"). The destination buffer for the domain name ("name_buffer") is typically limited to 255 bytes as per [RFC1035] and can be allocated either in the stack or in the heap memory region.

このような実装には、通常、ドメイン名を減圧するための専用関数があります（たとえば、[CVE-2020-24338]および[CVE-2020-27738]を参照）。他のパラメーターの中でも、これらの関数は、RR（ "name"）内のファーストネームラベルの開始へのポインターと、圧縮ポインターの出発点として使用されるDNSペイロードの開始へのポインターを受け入れる場合があります（ "dns_payload"）。ドメイン名（ "name_buffer"）の宛先バッファーは、通常[RFC1035]に従って255バイトに制限され、スタックまたはヒープメモリ領域のいずれかで割り当てることができます。

The code of the function in Figure 1 reads the domain name label by label from an RR until it reaches the NUL octet ("0x00") that signifies the end of a domain name. If the current label length octet ("label_len_octet") is a compression pointer, the code extracts the value of the compression offset and uses it to "jump" to another label length octet. If the current label length octet is not a compression pointer, the label bytes will be copied into the name buffer, and the number of bytes copied will correspond to the value of the current label length octet. After the copy operation, the code will move on to the next label length octet.

図1の関数のコードは、ドメイン名の最後を意味するNul Octet（ "0x00"）に到達するまで、RRのラベルでドメイン名ラベルを読み取ります。現在のラベルの長さOctet（ "label_len_octet"）が圧縮ポインターである場合、コードは圧縮オフセットの値を抽出し、それを使用して別のラベル長オクテットに「ジャンプ」します。現在のラベルの長さのオクテットが圧縮ポインターでない場合、ラベルバイトは名前バッファーにコピーされ、コピーされたバイト数は現在のラベル長オクテットの値に対応します。コピー操作の後、コードは次のラベルの長さOctetに移動します。

The first issue with this implementation is due to unchecked compression offset values. The second issue is due to the absence of checks that ensure that a pointer will eventually arrive at a decompressed domain label. We describe these issues in more detail below.

この実装の最初の問題は、非チェックされた圧縮オフセット値によるものです。2番目の問題は、ポインターが最終的に減圧ドメインラベルに到達することを保証するチェックがないためです。これらの問題については、以下で詳しく説明します。

[RFC1035] states that a compression pointer is "a pointer to a prior occurance [sic] of the same name." Also, according to [RFC1035], the maximum size of DNS packets that can be sent over UDP is limited to 512 octets.

[RFC1035]は、圧縮ポインターは「同じ名前の以前の出来事[sic]へのポインター」であると述べています。また、[RFC1035]によると、UDPを介して送信できるDNSパケットの最大サイズは512オクテットに制限されています。

The pseudocode in Figure 1 violates these constraints, as it will accept a compression pointer that forces the code to read outside the bounds of a DNS packet. For instance, a compression pointer set to "0xffff" will produce an offset of 16383 octets, which is most definitely pointing to a label length octet somewhere past the bounds of the original DNS packet. Supplying such offset values will most likely cause memory corruption issues and may lead to Denial-of-Service conditions (e.g., a Null pointer dereference after "label_len_octet" is set to an invalid address in memory). For additional examples, see [CVE-2020-25767], [CVE-2020-24339], and [CVE-2020-24335].

図1の擬似コードは、これらの制約に違反しています。これは、DNSパケットの境界外でコードを強制する圧縮ポインターを受け入れるためです。たとえば、「0xffff」に設定された圧縮ポインターは、16383オクテットのオフセットを生成します。このようなオフセット値を提供すると、メモリの破損の問題を引き起こす可能性が最も高く、サービス拒否条件につながる可能性があります（たとえば、「label_len_octet」の後のヌルポインター逆間は、メモリ内の無効なアドレスに設定されます）。追加の例については、[CVE-2020-25767]、[CVE-2020-24339]、および[CVE-2020-24335]を参照してください。

The pseudocode in Figure 1 allows jumping from a compression pointer to another compression pointer and does not restrict the number of such jumps. That is, if a label length octet that is currently being parsed is a compression pointer, the code will perform a jump to another label, and if that other label is a compression pointer as well, the code will perform another jump, and so forth until it reaches a decompressed label. This may lead to unforeseen side effects that result in security issues.

図1の擬似コードは、圧縮ポインターから別の圧縮ポインターへのジャンプを可能にし、そのようなジャンプの数を制限しません。つまり、現在解析されているラベルの長さのオクテットが圧縮ポインターである場合、コードは別のラベルへのジャンプを実行し、その他のラベルも圧縮ポインターである場合、コードは別のジャンプを実行します。減圧ラベルに達するまで。これは、セキュリティの問題をもたらす予期せぬ副作用につながる可能性があります。

Consider the DNS packet excerpt illustrated below:

以下に示すDNSパケットの抜粋を考えてみましょう。

           +----+----+----+----+----+----+----+----+----+----+----+----+
     +0x00 |    ID   |  FLAGS  | QDCOUNT | ANCOUNT | NSCOUNT | ARCOUNT |
           +----+----+----+----+----+----+----+----+----+----+----+----+
   ->+0x0c |0xc0|0x0c|   TYPE  |  CLASS  |0x04| t  | e  | s  | t  |0x03|
   |       +----+--|-+----+----+----+----+----+----+----+----+----+----+
   | +0x18 | c  | o| | m  |0x00|  TYPE   |  CLASS  | ................  |
   |       +----+--|-+----+----+----+----+----+----+----+----+----+----+
   |               |
   -----------------

The packet begins with a DNS header at offset +0x00, and its DNS payload contains several RRs. The first RR begins at an offset of 12 octets (+0x0c); its first label length octet is set to the value "0xc0", which indicates that it is a compression pointer. The compression pointer offset is computed from the two octets "0xc00c" and is equal to 12. Since the broken implementation in Figure 1 follows this offset value blindly, the pointer will jump back to the first octet of the first RR (+0x0c) over and over again. The code in Figure 1 will enter an infinite-loop state, since it will never leave the "TRUE" branch of the "while" loop.

パケットは、オフセット0x00のDNSヘッダーで始まり、そのDNSペイロードにはいくつかのRRが含まれています。最初のRRは、12オクテット（0x0C）のオフセットから始まります。その最初のラベル長オクテットは、値「0xc0」に設定されており、これが圧縮ポインターであることを示しています。圧縮ポインターオフセットは、2つのオクテット「0xc00c」から計算され、12に等しくなります。図1の壊れた実装はこのオフセット値に盲目的に続くため、ポインターは最初のRR（0x0C）の最初のオクテットに戻り、もう一度。図1のコードは、「while "while loopの「真の」ブランチを決して離れることはないため、無限ループ状態に入ります。

Apart from achieving infinite loops, the implementation flaws in Figure 1 make it possible to achieve various pointer loops that have other undesirable effects. For instance, consider the DNS packet excerpt shown below:

無限ループを達成することとは別に、図1の実装の欠陥により、他の望ましくない効果を持つさまざまなポインターループを実現できます。たとえば、以下に示すDNSパケットの抜粋を考えてみましょう。

           +----+----+----+----+----+----+----+----+----+----+----+----+
     +0x00 |    ID   |  FLAGS  | QDCOUNT | ANCOUNT | NSCOUNT | ARCOUNT |
           +----+----+----+----+----+----+----+----+----+----+----+----+
   ->+0x0c |0x04| t  | e  | s  | t  |0xc0|0x0c| ...................... |
   |       +----+----+----+----+----+----+--|-+----+----+----+----+----+
   |                                        |
   ------------------------------------------

With such a domain name, the implementation in Figure 1 will first copy the domain label at offset "0xc0" ("test"); it will then fetch the next label length octet, which happens to be a compression pointer ("0xc0"). The compression pointer offset is computed from the two octets "0xc00c" and is equal to 12 octets. The code will jump back to offset "0xc0" where the first label "test" is located. The code will again copy the "test" label and then jump back to it, following the compression pointer, over and over again.

このようなドメイン名を使用すると、図1の実装は、最初にオフセット「0xc0」（「テスト」）でドメインラベルをコピーします。次に、次のラベルの長さのオクテットを取得します。これは、たまたま圧縮ポインター（ "0xc0"）です。圧縮ポインターオフセットは、2つのオクテット「0xC00C」から計算され、12オクテットに等しくなります。コードはジャンプして、最初のラベル「テスト」が配置されている「0xc0」をオフセットします。コードは再び「テスト」ラベルをコピーしてから、圧縮ポインターに従って何度も何度も繰り返してジャンプします。

Figure 1 does not contain any logic that restricts multiple jumps from the same compression pointer and does not ensure that no more than 255 octets are copied into the name buffer ("name_buffer"). In fact,

図1には、同じ圧縮ポインターからの複数のジャンプを制限するロジックは含まれておらず、255個以下のオクテットが名前バッファー（ "name_buffer"）にコピーされることを保証しません。実際には、

* the code will continue to write the label "test" into it, overwriting the name buffer and the stack of the heap metadata.

* コードは引き続きラベル「テスト」を書き込み、名前バッファーとヒープメタデータのスタックを上書きします。

* attackers would have a significant degree of freedom in constructing shell code, since they can create arbitrary copy chains with various combinations of labels and compression pointers.

* 攻撃者は、ラベルと圧縮ポインターのさまざまな組み合わせで任意のコピーチェーンを作成できるため、シェルコードの構築にかなりの自由度があります。

Therefore, blindly following compression pointers may lead not only to Denial-of-Service conditions, as pointed out by [DNS-COMPRESSION], but also to successful Remote Code Execution attacks, as there may be other implementation issues present within the corresponding code.

したがって、[DNS-Compression]で指摘されているように、コンプレッションポインターに盲目的に従うことは、対応するコード内に存在する他の実装の問題がある可能性があるため、[DNS-Compression]で指摘されているように、サービス拒否条件だけでなく、リモートコード実行攻撃の成功にもつながる可能性があります。

Some implementations may not follow [RFC1035], which states:

一部の実装は[RFC1035]に従わない場合があります。

   |  The first two bits are ones.  This allows a pointer to be
   |  distinguished from a label, since the label must begin with two
   |  zero bits because labels are restricted to 63 octets or less.
   |  (The 10 and 01 combinations are reserved for future use.)

Figures 2 and 3 show pseudocode that implements two functions that check whether a given octet is a compression pointer; Figure 2 shows a correct implementation, and Figure 3 shows an incorrect (broken) implementation.

図2と3は、特定のオクテットが圧縮ポインターであるかどうかを確認する2つの機能を実装する擬似コードを示しています。図2は正しい実装を示し、図3は誤った（壊れた）実装を示しています。

   1: unsigned char is_compression_pointer(*octet) {
   2:     if ((*octet & 0xc0) == 0xc0)
   3:         return true;
   4:     } else {
   5:         return false;
   6:     }
   7: }

Figure 2: Correct Compression Pointer Check

図2：正しい圧縮ポインターチェック

   1: unsigned char is_compression_pointer(*octet) {
   2:     if (*octet & 0xc0) {
   3:         return true;
   4:     } else {
   5:         return false;
   6:     }
   7: }

Figure 3: Broken Compression Pointer Check

図3：壊れた圧縮ポインターチェック

The correct implementation (Figure 2) ensures that the two most significant bits of an octet are both set, while the broken implementation (Figure 3) would consider an octet with only one of the two bits set to be a compression pointer. This is likely an implementation mistake rather than an intended violation of [RFC1035], because there are no benefits in supporting such compression pointer values. The implementations related to [CVE-2020-24338] and [CVE-2020-24335] had a broken compression pointer check, similar to the code shown in Figure 3.

正しい実装（図2）により、オクテットの2つの最も重要なビットが両方とも設定され、壊れた実装（図3）は、2つのビットのうち1つだけが圧縮ポインターであると考えられます。このような圧縮ポインター値をサポートすることに利点がないため、これはおそらく[RFC1035]の意図した違反ではなく、実装の間違いである可能性があります。[CVE-2020-24338]および[CVE-2020-24335]に関連する実装には、図3に示すコードと同様に、圧縮ポインターチェックが壊れていました。

While incorrect implementations alone do not lead to vulnerabilities, they may have unforeseen side effects when combined with other vulnerabilities. For instance, the first octet of the value "0x4130" may be incorrectly interpreted as a label length by a broken implementation. Such a label length (65) is invalid and is larger than 63 (as per [RFC1035]); a packet that has this value should be discarded. However, the function shown in Figure 3 will consider "0x41" to be a valid compression pointer, and the packet may pass the validation steps.

誤った実装だけでは脆弱性につながるわけではありませんが、他の脆弱性と組み合わせると、予期せぬ副作用があります。たとえば、値「0x4130」の値の最初のオクテットは、壊れた実装によってラベルの長さとして誤って解釈される場合があります。このようなラベルの長さ（65）は無効で、63より大きく（[RFC1035]）。この値を持つパケットを破棄する必要があります。ただし、図3に示す関数は、「0x41」が有効な圧縮ポインターであると考えると、パケットは検証手順を渡すことができます。

This might give attackers additional leverage for constructing payloads and circumventing the existing DNS packet validation mechanisms.

これにより、攻撃者はペイロードを構築し、既存のDNSパケット検証メカニズムを回避するための追加のレバレッジを提供する可能性があります。

The first occurrence of a compression pointer in an RR (an octet with the two highest bits set to 1) must resolve to an octet within a DNS record with a value that is greater than 0 (i.e., it must not be a Null-terminator) and less than 64. The offset at which this octet is located must be smaller than the offset at which the compression pointer is located; once an implementation makes sure of that, compression pointer loops can never occur.

RR（1に設定された2つの最高ビットを備えたオクテット）での圧縮ポインターの最初の発生は、0を超える値を持つDNSレコード内のオクテットに解決する必要があります（つまり、ヌルターミネーターであってはなりません）64未満。このオクテットが配置されているオフセットは、圧縮ポインターが配置されているオフセットよりも小さくなければなりません。実装がそれを確実にすると、圧縮ポインターループが発生することはありません。

In small DNS implementations (e.g., embedded TCP/IP stacks), support for nested compression pointers (pointers that point to a compressed name) should be discouraged: there is very little to be gained in terms of performance versus the high probability of introducing errors such as those discussed above.

小さなDNS実装（埋め込まれたTCP/IPスタックなど）では、ネストされた圧縮ポインター（圧縮名を指すポインター）のサポートは落胆する必要があります。上記のようなものなど。

The code that implements domain name parsing should check the offset with respect to not only the bounds of a packet but also its position with respect to the compression pointer in question. A compression pointer must not be "followed" more than once. We have seen several implementations using a check that ensures that a compression pointer is not followed more than several times. A better alternative may be to ensure that the target of a compression pointer is always located before the location of the pointer in the packet.

ドメイン名の解析を実装するコードは、パケットの境界だけでなく、問題の圧縮ポインターに関する位置に関してもオフセットをチェックする必要があります。圧縮ポインターを複数回「追跡」してはなりません。圧縮ポインターが数回以上従わないことを保証するチェックを使用して、いくつかの実装を見てきました。より良い選択肢は、圧縮ポインターのターゲットが常にパケット内のポインターの位置の前に配置されるようにすることです。

3. Label and Name Length Validation

3. ラベルと名前の長さの検証

[RFC1035] restricts the length of name labels to 63 octets and lengths of domain names to 255 octets (i.e., label octets and label length octets). Some implementations do not explicitly enforce these restrictions.

[RFC1035]は、名前ラベルの長さを63オクテットに制限し、ドメイン名の長さは255オクテット（つまり、ラベルオクテットとラベルの長さのオクテット）に制限します。一部の実装では、これらの制限を明示的に実施していません。

Consider the function "copy_domain_name()" shown in Figure 4 below. The function is a variant of the "decompress_domain_name()" function (Figure 1), with the difference that it does not support compressed labels and only copies decompressed labels into the name buffer.

以下の図4に示す関数「copy_domain_name（）」を考慮してください。この関数は、「decompress_domain_name（）」関数のバリアントであり（図1）、圧縮ラベルをサポートせず、コピーのみを名前バッファーにコピーするという違いがあります。

    1: copy_domain_name(*name, *dns_payload) {
    2:
    3:   name_buffer[255];
    4:   copy_offset = 0;
    5:
    6:   label_len_octet = name;
    7:   dest_octet = name_buffer;
    8:
    9:   while (*label_len_octet != 0x00) {
   10:
   11:      if (is_compression_pointer(*label_len_octet)) {
   12:          length = 2;
   13:          label_len_octet += length + 1;
   14:      }
   15:
   16:      else {
   17:          length = *label_len_octet;
   18:          copy(dest_octet + copy_offset,
                                label_len_octet+1, *length);
   19:
   20:         copy_offset += length;
   21:          label_len_octet += length + 1;
   22:      }
   23:
   24:  }
   25: }

Figure 4: A Broken Implementation of a Function That Is Used for Copying Non-compressed Domain Names

図4：圧縮されていないドメイン名のコピーに使用される関数の壊れた実装

This implementation does not explicitly check for the value of the label length octet: this value can be up to 255 octets, and a single label can fill the name buffer. Depending on the memory layout of the target, how the name buffer is allocated, and the size of the malformed packet, it is possible to trigger various memory corruption issues.

この実装では、ラベルの長さのオクテットの値を明示的にチェックしません。この値は最大255オクテットになり、単一のラベルがバッファーを入力できます。ターゲットのメモリレイアウト、名前バッファーの割り当て方法、および奇形パケットのサイズに応じて、さまざまなメモリ腐敗の問題をトリガーすることができます。

Both Figures 1 and 4 restrict the size of the name buffer to 255 octets; however, there are no restrictions on the actual number of octets that will be copied into this buffer. In this particular case, a subsequent copy operation (if another label is present in the packet) will write past the name buffer, allowing heap or stack metadata to be overwritten in a controlled manner.

図1と4の両方は、名前バッファーのサイズを255オクテットに制限します。ただし、このバッファにコピーされる実際のオクテット数には制限はありません。この特定のケースでは、後続のコピー操作（パケットに別のラベルが存在する場合）が名前バッファーを通過し、ヒープまたはスタックメタデータを制御された方法で上書きできるようにします。

Similar examples of vulnerable implementations can be found in the code relevant to [CVE-2020-25110], [CVE-2020-15795], and [CVE-2020-27009].

脆弱な実装の同様の例は、[CVE-2020-25110]、[CVE-2020-15795]、および[CVE-2020-27009]に関連するコードに記載されています。

As a general recommendation, a domain label length octet must have a value of more than 0 and less than 64 [RFC1035]. If this is not the case, an invalid value has been provided within the packet, or a value at an invalid position might be interpreted as a domain name length due to other errors in the packet (e.g., misplaced Null-terminator or invalid compression pointer).

一般的な推奨事項として、ドメインラベルの長さのオクテットは、0を超えて64未満の値を持たなければなりません[RFC1035]。これが当てはまらない場合、パケット内で無効な値が提供されているか、無効な位置での値がパケット内の他のエラーのためにドメイン名の長さとして解釈される可能性があります（たとえば、誤ったヌルターミネーターまたは無効な圧縮ポインターが）。

The number of domain label characters must correspond to the value of the domain label octet. To avoid possible errors when interpreting the characters of a domain label, developers may consider recommendations for the preferred domain name syntax outlined in [RFC1035].

ドメインラベル文字の数は、ドメインラベルOctetの値に対応する必要があります。ドメインラベルの文字を解釈するときに可能なエラーを回避するために、開発者は[RFC1035]で概説されている優先ドメイン名構文の推奨事項を考慮することができます。

The domain name length must not be more than 255 octets, including the size of decompressed domain names. The NUL octet ("0x00") must be present at the end of the domain name and must be within the maximum name length (255 octets).

ドメイン名の長さは、減圧ドメイン名のサイズを含む255オクテットを超えてはなりません。Nul Octet（ "0x00"）は、ドメイン名の最後に存在する必要があり、最大名の長さ（255オクテット）内でなければなりません。

4. Null-Terminator Placement Validation

4. ヌルターミネーター配置検証

A domain name must end with a NUL ("0x00") octet, as per [RFC1035]. The implementations shown in Figures 1 and 4 assume that this is the case for the RRs that they process; however, names that do not have a NUL octet placed at the proper position within an RR are not discarded.

ドメイン名は、[RFC1035]に従って、NUL（ "0x00"）Octetで終了する必要があります。図1および4に示す実装は、これがRRSが処理する場合であると仮定しています。ただし、RR内の適切な位置にNULオクテットが配置されていない名前は破棄されません。

This issue is closely related to the absence of label and name length checks. For example, the logic behind Figures 1 and 4 will continue to copy octets into the name buffer until a NUL octet is encountered. This octet can be placed at an arbitrary position within an RR or not placed at all.

この問題は、ラベルと名前の長さのチェックがないことと密接に関連しています。たとえば、図1と4の背後にあるロジックは、オクテットに遭遇するまでオクテットを名前にコピーし続けます。このオクテットは、RR内の任意の位置に配置するか、まったく配置できません。

Consider the pseudocode function shown in Figure 5. The function returns the length of a domain name ("name") in octets to be used elsewhere (e.g., to allocate a name buffer of a certain size): for compressed domain names, the function returns 2; for decompressed names, it returns their true length using the "strlen(3)" function.

図5に示す擬似コード関数を考えてみましょう。関数は、他の場所で使用されるオクテットのドメイン名（ "name"）の長さを返します（たとえば、特定のサイズの名前バッファーを割り当てるために）：圧縮ドメイン名の場合、関数は関数です2を返します。減圧名の場合、「strlen（3）」関数を使用して真の長さを返します。

   1: get_name_length(*name) {
   2:
   3:     if (is_compression_pointer(name))
   4:         return 2;
   5:
   6:     name_len = strlen(name) + 1;
   7:     return name_len;
   8: }

Figure 5: A Broken Implementation of a Function That Returns the Length of a Domain Name

図5：ドメイン名の長さを返す関数の壊れた実装

"strlen(3)" is a standard C library function that returns the length of a given sequence of characters terminated by the NUL ("0x00") octet. Since this function also expects names to be explicitly Null-terminated, the return value "strlen(3)" may also be controlled by attackers. Through the value of "name_len", attackers may control the allocation of internal buffers or specify the number by octets copied into these buffers, or they may perform other operations, depending on the implementation specifics.

「Strlen（3）」は、NUL（ "0x00"）Octetによって終了した特定の文字シーケンスの長さを返す標準Cライブラリ関数です。この関数は、名前が明示的にターミネートされることも期待しているため、攻撃者によっても「strlen（3）」の返品値が制御される場合があります。「name_len」の値を通じて、攻撃者は内部バッファの割り当てを制御するか、これらのバッファーにコピーされたオクテットで数値を指定するか、実装の詳細に応じて他の操作を実行する場合があります。

The absence of explicit checks for placement of the NUL octet may also facilitate controlled memory reads and writes. An example of vulnerable implementations can be found in the code relevant to [CVE-2020-25107], [CVE-2020-17440], [CVE-2020-24383], and [CVE-2020-27736].

Nul Octetの配置のための明示的なチェックがないことは、制御されたメモリの読み取りと書き込みを促進する可能性があります。脆弱な実装の例は、[CVE-2020-25107]、[CVE-2020-17440]、[CVE-2020-24383]、および[CVE-2020-27736]に関連するコードに記載されています。

As a general recommendation for mitigating such issues, developers should never trust user data to be Null-terminated. For example, to fix/mitigate the issue shown in the code in Figure 5, developers should use the function "strnlen(3)", which reads at most X characters (the second argument of the function), and ensure that X is not larger than the buffer allocated for the name.

このような問題を軽減するための一般的な推奨事項として、開発者はユーザーデータがヌル終了されたと信頼しないでください。たとえば、図5のコードに示されている問題を修正/軽減するには、開発者は最大のx文字（関数の2番目の引数）で読み取る関数「strnlen（3）」を使用する必要があります。名前に割り当てられたバッファよりも大きい。

5. Response Data Length Validation

5. 応答データの長さの検証

As stated in [RFC1035], every RR contains a variable-length string of octets that contains the retrieved resource data (RDATA) (e.g., an IP address that corresponds to a domain name in question). The length of the RDATA field is regulated by the resource data length field (RDLENGTH), which is also present in an RR.

[RFC1035]に記載されているように、すべてのRRには、取得されたリソースデータ（RDATA）を含む可変長さのオクテットの文字列が含まれています（例えば、問題のドメイン名に対応するIPアドレス）。RDATAフィールドの長さは、RRにも存在するリソースデータの長さフィールド（RDLENGTH）によって規制されています。

Implementations that process RRs may not check for the validity of the RDLENGTH field value when retrieving RDATA. Failing to do so may lead to out-of-bound read issues, whose impact may vary significantly, depending on the implementation specifics. We have observed instances of Denial-of-Service conditions and information leaks.

RRSを処理する実装では、RDATAを取得するときにRDLengthフィールド値の有効性を確認できない場合があります。そうしないと、実装の詳細に応じて、その影響が大きく異なる場合があります。サービス拒否の条件と情報の漏れの事例を観察しました。

Therefore, the value of the data length byte in response DNS records (RDLENGTH) must reflect the number of bytes available in the field that describes the resource (RDATA). The format of RDATA must conform to the TYPE and CLASS fields of the RR.

したがって、応答DNSレコード（rdLength）のデータ長バイトの値は、リソース（RDATA）を記述するフィールドで利用可能なバイト数を反映する必要があります。RDATAの形式は、RRのタイプおよびクラスフィールドに準拠する必要があります。

Examples of vulnerable implementations can be found in the code relevant to [CVE-2020-25108], [CVE-2020-24336], and [CVE-2020-27009].

脆弱な実装の例は、[CVE-2020-25108]、[CVE-2020-24336]、および[CVE-2020-27009]に関連するコードに記載されています。

6. Record Count Validation

6. 記録カウント検証

According to [RFC1035], the DNS header contains four two-octet fields that specify the amount of question records (QDCOUNT), answer records (ANCOUNT), authority records (NSCOUNT), and additional records (ARCOUNT).

[RFC1035]によると、DNSヘッダーには、質問記録（QDCount）、回答記録（Ancount）、Authority Records（NSCount）、および追加レコード（Arcount）を指定する4つの2オクテットフィールドが含まれています。

Figure 6 illustrates a recurring implementation anti-pattern for a function that processes DNS RRs. The function "process_dns_records()" extracts the value of ANCOUNT ("num_answers") and the pointer to the DNS data payload ("data_ptr"). The function processes answer records in a loop, decrementing the "num_answers" value after processing each record until the value of "num_answers" becomes zero. For simplicity, we assume that there is only one domain name per answer. Inside the loop, the code calculates the domain name length ("name_length") and adjusts the data payload pointer ("data_ptr") by the offset that corresponds to "name_length + 1", so that the pointer lands on the first answer record. Next, the answer record is retrieved and processed, and the "num_answers" value is decremented.

図6は、DNS RRを処理する関数の繰り返し実装アンチパターンを示しています。関数「process_dns_records（）」は、ancount（ "num_answers"）の値とDNSデータペイロード（ "data_ptr"）へのポインターを抽出します。関数はループでレコードに応答し、「num_answers」の値がゼロになるまで、各レコードを処理した後に「num_answers」値を減少させます。簡単にするために、回答ごとにドメイン名が1つしかないと想定しています。ループ内で、コードはドメイン名の長さ（ "name_length"）を計算し、「name_length 1」に対応するオフセットでデータペイロードポインター（ "data_ptr"）を調整して、ポインターが最初の回答レコードに着地します。次に、回答レコードが取得および処理され、「num_answers」値が減少します。

    1: process_dns_records(dns_header, ...) {
           // ...
    2:     num_answers = dns_header->ancount
    3:     data_ptr = dns_header->data
    4:
    5:     while (num_answers > 0) {
    6:         name_length = get_name_length(data_ptr);
    7:         data_ptr += name_length + 1;
    8:
    9:         answer = (struct dns_answer_record *)data_ptr;
   10:
   11:         // process the answer record
   12:
   13:         --num_answers;
   14:     }
           // ...
   15: }

Figure 6: A Broken Implementation of a Function That Processes RRs

図6：RRを処理する関数の壊れた実装

If the ANCOUNT number retrieved from the header ("dns_header->ancount") is not checked against the amount of data available in the packet and it is, for example, larger than the number of answer records available, the data pointer ("data_ptr") will read outside the bounds of the packet. This may result in Denial-of-Service conditions.

ヘッダー（ "dns_header-> ancount"）から取得されたancount番号がパケットで利用可能なデータの量に対してチェックされず、たとえば、利用可能な回答レコードの数よりも大きい場合、データポインター（ "data_ptr"）パケットの境界の外で読み取ります。これにより、サービス拒否条件が生じる可能性があります。

In this section, we used an example of processing answer records. However, the same logic is often reused for implementing the processing of other types of records, e.g., the number of question (QDCOUNT), authority (NSCOUNT), and additional (ARCOUNT) records. The specified numbers of these records must correspond to the actual data present within the packet. Therefore, all record count fields must be checked before fully parsing the contents of a packet. Specifically, Section 6.3 of [RFC5625] recommends that such malformed DNS packets should be dropped and (optionally) logged.

このセクションでは、回答レコードの処理例を使用しました。ただし、他のタイプのレコードの処理を実装するために、同じロジックが再利用されることがよくあります。たとえば、質問の数（qdcount）、機関（nscount）、および追加（arcount）レコード。これらのレコードの指定された番号は、パケット内に存在する実際のデータに対応する必要があります。したがって、すべてのレコードカウントフィールドは、パケットの内容を完全に解析する前にチェックする必要があります。具体的には、[RFC5625]のセクション6.3は、そのような奇形のDNSパケットをドロップし、（オプションで）ログに記録することを推奨しています。

Examples of vulnerable implementations can be found in the code relevant to [CVE-2020-25109], [CVE-2020-24340], [CVE-2020-24334], and [CVE-2020-27737].

脆弱な実装の例は、[CVE-2020-25109]、[CVE-2020-24340]、[CVE-2020-24334]、および[CVE-2020-27737]に関連するコードに記載されています。

7. Security Considerations

7. セキュリティに関する考慮事項

Security issues are discussed throughout this memo; it discusses implementation flaws (anti-patterns) that affect the functionality of processing DNS RRs. The presence of such anti-patterns leads to bugs that cause buffer overflows, read-out-of-bounds, and infinite-loop issues. These issues have the following security impacts: information leaks, Denial-of-Service attacks, and Remote Code Execution attacks.

このメモ全体でセキュリティの問題について説明します。DNS RRSの処理機能に影響を与える実装の欠陥（アンチパターン）について説明します。そのようなアンチパターンの存在は、バッファーのオーバーフロー、読み取り、無限ループの問題を引き起こすバグにつながります。これらの問題には、情報リーク、サービス拒否攻撃、およびリモートコード実行攻撃のセキュリティへの影響があります。

This document lists general recommendations for the developers of DNS record parsing functionality that allow those developers to prevent such implementation flaws, e.g., by rigorously checking the data received over the wire before processing it.

このドキュメントには、DNSレコードの解析機能の開発者に関する一般的な推奨事項がリストされています。これらの開発者は、そのような実装の欠陥を防ぐことができます。

8. IANA Considerations

8. IANAの考慮事項

This document has no IANA actions. Please see [RFC6895] for a complete review of the IANA considerations introduced by DNS.

このドキュメントにはIANAアクションがありません。DNSによって導入されたIANAの考慮事項の完全なレビューについては、[RFC6895]を参照してください。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487/RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>

[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <https://www.rfc-editor.org/info/rfc5625>.

[RFC5625] Bellis、R。、「DNS Proxy実装ガイドライン」、BCP 152、RFC 5625、DOI 10.17487/RFC5625、2009年8月、<https://www.rfc-editor.org/info/rfc5625>

9.2. Informative References

9.2. 参考引用

[CVE-2000-0333] Common Vulnerabilities and Exposures, "CVE-2000-0333: A denial-of-service vulnerability in tcpdump, Ethereal, and other sniffer packages via malformed DNS packets", 2000, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0333>.

[CVE-2000-0333]一般的な脆弱性と露出、「CVE-2000-0333：TCPDUMP、ETHEREAL、およびその他のスニファーパッケージのサービス拒否脆弱性」、2000、<https：// cve。mitre.org/cgi-bin/cvename.cgi?name=cve-2000-0333>。

[CVE-2017-9345] Common Vulnerabilities and Exposures, "CVE-2017-9345: An infinite loop in the DNS dissector of Wireshark", 2017, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9345>.

[CVE-2017-9345]一般的な脆弱性と露出、「CVE-2017-9345：WiresharkのDNS分離器の無限ループ」、2017年、<https://cve.mitre.org/cgi-bin/cvename.cgi？name = CVE-2017-9345>。

[CVE-2020-15795] Common Vulnerabilities and Exposures, "CVE-2020-15795: A denial-of-service and remote code execution vulnerability DNS domain name label parsing functionality of Nucleus NET", 2021, <https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2020-15795>.

[CVE-2020-15795]共通の脆弱性と露出、「CVE-2020-15795：サービス拒否およびリモートコード実行脆弱性DNSドメイン名核ネットのラベル解析機能」、2021、<https：// cve。mitre.org/cgi-bin/ cvename.cgi？name = cve-2020-15795>。

[CVE-2020-17440] Common Vulnerabilities and Exposures, "CVE-2020-17440 A denial-of-service vulnerability in the DNS name parsing implementation of uIP", 2020, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17440>.

[CVE-2020-17440]一般的な脆弱性と露出、「CVE-2020-17440 uIPのDNS名の解析の実装のサービス拒否脆弱性」、2020年、<https://cve.mitre.org/cgi-bin/cvename.cgi？name = cve-2020-17440>。

[CVE-2020-24334] Common Vulnerabilities and Exposures, "CVE-2020-24334: An out-of-bounds read and denial-of-service vulnerability in the DNS response parsing functionality of uIP", 2020, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24334>.

[CVE-2020-24334]一般的な脆弱性と露出、「CVE-2020-24334：UIPのDNS応答の解析機能におけるサービスの読み取りとサービス拒否の脆弱性」、2020年、<https：//cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2020-24334>。

[CVE-2020-24335] Common Vulnerabilities and Exposures, "CVE-2020-24335: A memory corruption vulnerability in domain name parsing routines of uIP", 2020, <https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2020-24335>.

[CVE-2020-24335]一般的な脆弱性と露出、「CVE-2020-24335：UIPのドメイン名解析ルーチンの記憶腐敗の脆弱性」、2020、<https://cve.rg/cgi-bin/ cvename.cgi？name = cve-2020-24335>。

[CVE-2020-24336] Common Vulnerabilities and Exposures, "CVE-2020-24336: A buffer overflow vulnerability in the DNS implementation of Contiki and Contiki-NG", 2020, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24336>.

[CVE-2020-24336]一般的な脆弱性と露出、「CVE-2020-24336：contikiおよびcontiki-ngのDNS実装におけるバッファオーバーフローの脆弱性」、2020、<https://cve.mitre.org/cgi-bin/cvename.cgi？name = cve-2020-24336>。

[CVE-2020-24338] Common Vulnerabilities and Exposures, "CVE-2020-24338: A denial-of-service and remote code execution vulnerability in the DNS domain name record decompression functionality of picoTCP", 2020, <https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2020-24338>.

[CVE-2020-24338]一般的な脆弱性と露出、 "CVE-2020-24338：dnsドメイン名の脆弱性脆弱性Picotcp"、<https：// cve.mitre.org/ cgi-bin/ cvename.cgi？name = cve-2020-24338>。

[CVE-2020-24339] Common Vulnerabilities and Exposures, "CVE-2020-24339: An out-of-bounds read and denial-of-service vulnerability in the DNS domain name record decompression functionality of picoTCP", 2020, <https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2020-24339>.

[CVE-2020-24339]一般的な脆弱性と露出、 "CVE-2020-24339：DNSドメイン名の脆弱性の脆弱性とサービスの否定は、PicotCPのレコード減圧機能"、2020、<https：<https：//cve.mitre.org/cgi-bin/ cvename.cgi? name = cve-2020-24339>。

[CVE-2020-24340] Common Vulnerabilities and Exposures, "CVE-2020-24340: An out-of-bounds read and denial-of-service vulnerability in the DNS response parsing functionality of picoTCP", 2020, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24340>.

[CVE-2020-24340]一般的な脆弱性と露出、「CVE-2020-24340：PicotCPのDNS応答の解析機能における拘束外の読み取りとサービスの脆弱性」、2020、<https：//cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2020-24340>。

[CVE-2020-24383] Common Vulnerabilities and Exposures, "CVE-2020-24383: An information leak and denial-of-service vulnerability while parsing mDNS resource records in FNET", 2020, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24383>.

[CVE-2020-24383]一般的な脆弱性と露出、「CVE-2020-24383：FNETのMDNSリソースレコードを解析する際の情報リークとサービスの否定」、2020年、<https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2020-24383>。

[CVE-2020-25107] Common Vulnerabilities and Exposures, "CVE-2020-25107: A denial-of-service and remote code execution vulnerability in the DNS implementation of Ethernut Nut/OS", 2020, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25107>.

[CVE-2020-25107]一般的な脆弱性と露出、「CVE-2020-25107：Ethernut Nut/OSのDNS実装におけるサービス拒否およびリモートコード実行の脆弱性」、2020、<https：// cve。mitre.org/cgi-bin/cvename.cgi?name=cve-2020-25107>。

[CVE-2020-25108] Common Vulnerabilities and Exposures, "CVE-2020-25108: A denial-of-service and remote code execution vulnerability in the DNS implementation of Ethernut Nut/OS", 2020, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25108>.

[CVE-2020-25108]一般的な脆弱性と露出、「CVE-2020-25108：Ethernut Nut/OSのDNS実装におけるサービス拒否およびリモートコード実行の脆弱性」、2020、<https：// cve。mitre.org/cgi-bin/cvename.cgi?name=cve-2020-25108>。

[CVE-2020-25109] Common Vulnerabilities and Exposures, "CVE-2020-25109: A denial-of-service and remote code execution vulnerability in the DNS implementation of Ethernut Nut/OS", 2020, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25109>.

[CVE-2020-25109]一般的な脆弱性と露出、「CVE-2020-25109：Ethernut Nut/OSのDNS実装におけるサービス拒否およびリモートコード実行の脆弱性」、2020、<https：// cve。mitre.org/cgi-bin/cvename.cgi?name=cve-2020-25109>。

[CVE-2020-25110] Common Vulnerabilities and Exposures, "CVE-2020-25110: A denial-of-service and remote code execution vulnerability in the DNS implementation of Ethernut Nut/OS", 2020, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25110>.

[CVE-2020-25110]一般的な脆弱性と露出、「CVE-2020-25110：Ethernut Nut/OSのDNS実装におけるサービス拒否およびリモートコード実行の脆弱性」、2020、<https：// cve。mitre.org/cgi-bin/cvename.cgi?name=cve-2020-25110>。

[CVE-2020-25767] Common Vulnerabilities and Exposures, "CVE-2020-25767: An out-of-bounds read and denial-of-service vulnerability in the DNS name parsing routine of HCC Embedded NicheStack", 2021, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25767>.

[CVE-2020-25767]一般的な脆弱性と露出、 "CVE-2020-25767：HCCエンメッドされたニシュタックのDNS名の解析ルーチンの既知の拒否とサービス拒否の脆弱性"、2021、<https：//cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2020-25767>。

[CVE-2020-27009] Common Vulnerabilities and Exposures, "CVE-2020-27009: A denial-of-service and remote code execution vulnerability DNS domain name record decompression functionality of Nucleus NET", 2021, <https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2020-27009>.

[CVE-2020-27009]一般的な脆弱性と露出、「CVE-2020-27009：サービス拒否およびリモートコード実行脆弱性DNSドメイン名nucleus Netの記録減圧機能」、2021、<https：// cve。mitre.org/cgi-bin/ cvename.cgi？name = cve-2020-27009>。

[CVE-2020-27736] Common Vulnerabilities and Exposures, "CVE-2020-27736: An information leak and denial-of-service vulnerability in the DNS name parsing functionality of Nucleus NET", 2021, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27736>.

[CVE-2020-27736]共通の脆弱性と露出、「CVE-2020-27736：Nucleus NetのDNS名の解析機能における情報リークとサービス拒否の脆弱性」、2021年、<https：//cve.mitre.org/cgi-bin/cvename.cgi？name = cve-2020-27736>。

[CVE-2020-27737] Common Vulnerabilities and Exposures, "CVE-2020-27737: An information leak and denial-of-service vulnerability in the DNS response parsing functionality of Nucleus NET", 2021, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27737>.

[CVE-2020-27737]一般的な脆弱性と露出、「CVE-2020-27737：Nucleus NetのDNS応答機能における情報リークとサービス拒否の脆弱性」、2021年、<https：//cve.mitre.org/cgi-bin/cvename.cgi？name = cve-2020-27737>。

[CVE-2020-27738] Common Vulnerabilities and Exposures, "CVE-2020-27738: A denial-of-service and remote code execution vulnerability DNS domain name record decompression functionality of Nucleus NET", 2021, <https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2020-27738>.

[CVE-2020-27738]共通の脆弱性と露出、「CVE-2020-27738：サービス拒否およびリモートコード実行脆弱性DNSドメイン名nucleus Netのレコード減圧機能」、2021、<https：// cve。mitre.org/cgi-bin/ cvename.cgi？name = cve-2020-27738>。

[DNS-COMPRESSION] Koch, P., "A New Scheme for the Compression of Domain Names", Work in Progress, Internet-Draft, draft-ietf-dnsind-local-compression-05, 30 June 1999, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsind-local-compression-05>.

[DNS-Compression] Koch、P。、「ドメイン名の圧縮のための新しいスキーム」、作業中の作業、インターネットドラフト、ドラフト-ITETF-DNSIND-LOCAL-COPRESSION-05、1999年6月30日、<https：//datatracker.ietf.org/doc/html/draft-ietf-dnsind-local-compression-05>。

[DNSPOOQ] Kol, M. and S. Oberman, "DNSpooq: Cache Poisoning and RCE in Popular DNS Forwarder dnsmasq", JSOF Technical Report, January 2021, <https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq-Technical-WP.pdf>.

[DNSPOOQ] Kol、M。and S. Oberman、「DNSPOOQ：人気のあるDNS Forwarder DNSMASQのキャッシュ中毒とRCE」、JSOFテクニカルレポート、2021年1月、<https://www.jsof-tech.com/wp-content/アップロード/2021/01/DNSPOOQ-TECHNICAL-WP.PDF>。

[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.

[RFC6895] EastLake 3rd、D。、「ドメイン名システム（DNS）IANAの考慮事項」、BCP 42、RFC 6895、DOI 10.17487/RFC6895、2013年4月、<https://www.rfc-editor.org/info/rfc68955>。

[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.

[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「輸送層のセキュリティ上のDNSの仕様」、RFC 7858、doi10.17487/rfc7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。

[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.

[RFC8484] Hoffman、P。and P. McManus、「dns queries over https（doh）（doh）（doh）」、RFC 8484、doi 10.17487/rfc8484、2018年10月、<https://www.rfc-editor.org/info/rfc8484>。

[SADDNS] Man, K., Qian, Z., Wang, Z., Zheng, X., Huang, Y., and H. Duan, "DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels", Proc. 2020 ACM SIGSAC Conference on Computer and Communications Security, CCS '20, DOI 10.1145/3372297.3417280, November 2020, <https://dl.acm.org/doi/pdf/10.1145/3372297.3417280>.

[Saddns] Man、K.、Qian、Z.、Wang、Z.、Zheng、X.、Huang、Y.、およびH. Duan、「DNSキャッシュ中毒攻撃リロード：サイドチャネルによる革命」、Proc。2020 ACM SIGSAC Conference on Computer and Communications Security、CCS '20、DOI 10.1145/3372297.3417280、2020年11月、<https://dl.acm.org/doi/pdf/10.1145/3372297.3417280>

[SIGRED] Common Vulnerabilities and Exposures, "CVE-2020-1350: A remote code execution vulnerability in Windows Domain Name System servers", 2020, <https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2020-1350>.

[Sigred]共通の脆弱性と露出、「CVE-2020-1350：Windowsドメイン名システムサーバーのリモートコード実行脆弱性」、2020年、<https://cve.mitre.org/cgi-bin/ cvename.cgi？name name= CVE-2020-1350>。

Acknowledgements

謝辞

We would like to thank Shlomi Oberman, who has greatly contributed to the research that led to the creation of this document.

この文書の作成につながった研究に大きく貢献したShlomi Obermanに感謝したいと思います。

Authors' Addresses

著者のアドレス

Stanislav Dashevskyi Forescout Technologies John F. Kennedylaan, 2 5612AB Eindhoven Netherlands Email: stanislav.dashevskyi@forescout.com

Stanislav Dashevskyi Forescout Technologies John F. Kennedylaan、2 5612ab Aindhoven Otherlandsメール：stanislav.dashevskyi@forescout.com

Daniel dos Santos Forescout Technologies John F. Kennedylaan, 2 5612AB Eindhoven Netherlands Email: daniel.dossantos@forescout.com

Daniel Dos Santos Forescout Technologies John F. Kennedylaan、2 5612ab Eindhovenオランダメール：daniel.dossantos@forescout.com

Jos Wetzels Forescout Technologies John F. Kennedylaan, 2 5612AB Eindhoven Netherlands Email: jos.wetzels@forescout.com

Jos Wetzels Forescout Technologies John F. Kennedylaan、2 5612ab Eindhovenオランダメール：jos.wetzels@forescout.com

Amine Amri Forescout Technologies John F. Kennedylaan, 2 5612AB Eindhoven Netherlands Email: amine.amri@forescout.com

Amine Amri Forescout Technologies John F. Kennedylaan、2 5612ab Eindhovenオランダメール：amine.amri@forescout.com