RFC 9267

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

📅 published July 2022, from ietf

Okay bestie, this is RFC 9267 🦋 It's an Independent Submission from July 2022, so it's an Informational doc and not a standards-track thing. It's published under ISSN 2070-1721, and the authors are S. Dashevskyi, D. dos Santos, J. Wetzels, and A. Amri, all from Forescout Technologies 🧚 The header doesn't have any Obsoletes or Updates lines, so this doc doesn't replace or update anything. Pure main character energy, no cap 👑

(Part 1 of 4 🎀)

Abstract ✨

This memo covers common vulnerabilities in how DNS resource records (RRs) get processed, as seen in a bunch of DNS client implementations. These bugs can lead to successful Denial-of-Service and Remote Code Execution attacks on the affected software 😭 Where it applies, it also points out where RFC 1035 gets violated 🙈

Status of This Memo 🌸

This document is not an Internet Standards Track specification. It's published just for informational purposes 🍓

This is a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no claims about how valuable it is for implementation or deployment 💅 Docs the RFC Editor approves for publication aren't candidates for any level of Internet Standard. You can check Section 2 of RFC 7841 for the details ✨

Info about the current status of this doc, any errata, and how to leave feedback is at https://www.rfc-editor.org/info/rfc9267 🫶

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜

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 🎀

Okay so major DNS implementation vulnerabilities became super visible recently, and that put DNS on everyone's radar as a seriously important attack vector 😭 You can read about it in [SIGRED], [SADDNS], and [DNSPOOQ]. The last one is a set of 7 critical issues affecting the DNS forwarder "dnsmasq" 💀

The authors looked at the DNS client implementations in several major TCP/IP protocol stacks and found a bunch of vulnerabilities that share the same implementation flaws (anti-patterns) 🔥 These flaws have to do with processing DNS resource records (RRs) (discussed in [RFC1035]), and they can lead to critical security vulnerabilities 🙈

Even though the flaws can vary from one software project to another, these anti-patterns are highly likely to show up across multiple implementations ✨ Honestly, one of the first "Common Vulnerabilities and Exposures" (CVE) documents tied to one of these anti-patterns, [CVE-2000-0333], goes all the way back to the year 2000 💅 It's not just DNS client implementations either. Any software that processes DNS RRs can be affected, like firewalls, intrusion detection systems, or general-purpose DNS packet dissectors (for example, the DNS dissector in Wireshark; see [CVE-2017-9345]) 🦋 Similar issues can also pop up in DNS-over-HTTPS [RFC8484] and DNS-over-TLS [RFC7858] implementations. Any implementation that deals with the DNS wire format is subject to the considerations in this document, so it's giving "everyone check yourself" 🫶

[DNS-COMPRESSION] and [RFC5625] briefly mention some of these anti-patterns. But the main goal of this memo is to give the technical details behind them so the common mistakes can finally be eradicated 💜

We include general recommendations for mitigating the anti-patterns 🌸 We also suggest that all implementations should drop malicious/malformed DNS replies and (optionally) log them 🙈

2. Compression Pointer and Offset Validation 🧚

[RFC1035] defines the DNS message compression scheme, which can be used to shrink messages. When it's used, an entire domain name or several name labels get swapped out for a (compression) pointer to an earlier occurrence of the same name 🍓

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. That field gives the offset from the beginning of the DNS header to where another domain name or label lives 🦋

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 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 💅

However, [RFC1035] doesn't explicitly say that blindly following compression pointers of any kind can be harmful [DNS-COMPRESSION]. That's because they couldn't have made any assumptions about the various implementations that would follow them 😭

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

Here's pseudocode for a typical example of a broken domain name parsing implementation (Figure 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)

Implementations like this usually have a dedicated function for decompressing domain names (for example, see [CVE-2020-24338] and [CVE-2020-27738]) 🌈 Among other parameters, these functions may take a pointer to the beginning of the first name label within an RR ("name") and a pointer to the beginning of the DNS payload, which serves as the 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 it can be allocated either on the stack or in the heap memory region ✨

So the code in Figure 1 reads the domain name label by label from an RR until it hits the NUL octet ("0x00") that marks the end of a domain name. If the current label length octet ("label_len_octet") is a compression pointer, the code pulls out the compression offset value and uses it to "jump" to another label length octet. If the current label length octet isn't a compression pointer, the label bytes get copied into the name buffer, and the number of bytes copied matches the value of the current label length octet. After the copy, the code moves on to the next label length octet 🦋

The first issue with this implementation is unchecked compression offset values. The second issue is that nothing makes sure a pointer will eventually land on a decompressed domain label. We'll go over both in more detail below 🫶

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

The pseudocode in Figure 1 violates these constraints, because 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" produces 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 offset values like that will most likely cause memory corruption issues and may lead to Denial-of-Service conditions (for example, a Null pointer dereference after "label_len_octet" is set to an invalid address in memory). For more examples, see [CVE-2020-25767], [CVE-2020-24339], and [CVE-2020-24335] 🙈

The pseudocode in Figure 1 also allows jumping from a compression pointer to another compression pointer, and it doesn't limit how many of those jumps can happen. So if the label length octet being parsed is a compression pointer, the code jumps to another label. If that label is a compression pointer too, it jumps again, and so on until it reaches a decompressed label. This can cause unforeseen side effects that end up as security issues 🔥

Check out this DNS packet excerpt 👀

        +----+----+----+----+----+----+----+----+----+----+----+----+
  +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 starts with a DNS header at offset +0x00, and its DNS payload holds several RRs 🧚 The first RR begins at an offset of 12 octets (+0x0c), and its first label length octet is set to "0xc0", which means it's a compression pointer. The compression pointer offset gets computed from the two octets "0xc00c" and comes out to 12 🍓 Since the broken implementation in Figure 1 follows that offset blindly, the pointer jumps right back to the first octet of the first RR (+0x0c) over and over again 😭 The code in Figure 1 gets stuck in an infinite loop because it never leaves the "TRUE" branch of the "while" loop 💀

And it's not only infinite loops. The implementation flaws in Figure 1 also make it possible to build various pointer loops with other nasty effects 🔥 For instance, look at the DNS packet excerpt shown below:

Hmm, the next packet excerpt and the rest of Section 2 continue in part 2 💖

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

okay so with a domain name like that, the implementation in Figure 1 first copies the domain label at offset "0xc0" ("test") 💅 then it fetches the next label length octet, which just happens to be a compression pointer ("0xc0") 🙈. The compression pointer offset gets computed from the two octets "0xc00c" and comes out to 12 octets. So the code jumps right back to offset "0xc0" where "test" lives. It copies "test" again, then jumps back to it again, and again, and again, following that pointer forever 🌀 bestie, that's a loop!!

Figure 1 has zero logic to stop multiple jumps from the same compression pointer, and it doesn't make sure that no more than 255 octets get copied into the name buffer ("name_buffer") 😭 so, in fact:

  • the code keeps writing the label "test" into it, overwriting the name buffer and the stack of the heap metadata. 💀
  • attackers would have a seriously huge amount of freedom when building shell code, since they can make arbitrary copy chains out of different combos of labels and compression pointers. 🔥

So yeah, blindly following compression pointers can lead to Denial-of-Service conditions, which [DNS-COMPRESSION] already pointed out, but it can also lead to successful Remote Code Execution attacks, since there may be other implementation issues hiding in the corresponding code 👑 not a vibe.

Some implementations don't follow [RFC1035], which says:

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 for two functions that check whether a given octet is a compression pointer. Figure 2 is the correct version, and Figure 3 is the incorrect (broken) one 🎀

   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
   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

The correct one (Figure 2) makes sure that the two most significant bits of an octet are both set. The broken one (Figure 3) would count an octet with only one of those two bits set as a compression pointer 🙃 this is most likely an implementation mistake and not an intended violation of [RFC1035], because there's zero benefit to supporting those pointer values. The implementations tied to [CVE-2020-24338] and [CVE-2020-24335] had a broken compression pointer check, kind of like the code in Figure 3 ✨

Now, broken implementations alone don't cause vulnerabilities, ngl. But they can have unforeseen side effects when they're combined with other vulnerabilities 🦋 for example, the first octet of the value "0x4130" might get misread as a label length by a broken implementation. That label length (65) is invalid and bigger than 63 (per [RFC1035]), so a packet with that value should be discarded. BUT the function in Figure 3 will call "0x41" a valid compression pointer, so the packet might sneak right past the validation steps 😱

That could give attackers extra leverage for building payloads and getting around the existing DNS packet validation mechanisms. Not okay!! 🚫

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 where this octet is located must be smaller than the offset where the compression pointer is located. Once an implementation makes sure of that, compression pointer loops can never occur 💖

In small DNS implementations (for example, embedded TCP/IP stacks), support for nested compression pointers (pointers that point to a compressed name) should be discouraged. Honestly there's very little to gain in performance, and the chance of introducing errors like the ones above is super high 🙈

The code that parses domain names should check the offset against not only the bounds of the packet but also its position relative to the compression pointer in question. A compression pointer must not be "followed" more than once. We've seen several implementations that check whether a compression pointer is followed more than a few times, which is a little bit of a flex 😅 A better option may be to make sure the target of a compression pointer is always located before the pointer's own location in the packet 🌸

3. Label and Name Length Validation ✨

[RFC1035] limits name labels to 63 octets, and domain names to 255 octets (meaning label octets and label length octets). Some implementations don't explicitly enforce these limits, and that's a problem 🙃

Check out the function "copy_domain_name()" in Figure 4 below. It's a variant of the "decompress_domain_name()" function from Figure 1, except it doesn't support compressed labels and only copies decompressed labels into the name buffer 🧚

    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

This implementation doesn't explicitly check the value of the label length octet. That value can go all the way up to 255 octets, so a single label can fill the entire name buffer 😬 depending on the target's memory layout, how the name buffer is allocated, and the size of the malformed packet, it's possible to set off various memory corruption issues.

Both Figures 1 and 4 restrict the name buffer to 255 octets, but nothing restricts how many octets actually get copied into it 💀 in this case, a later copy operation (if there's another label in the packet) will write past the name buffer, which lets heap or stack metadata get overwritten in a controlled way.

Similar vulnerable implementations can be found in the code related to [CVE-2020-25110], [CVE-2020-15795], and [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 that's not the case, either an invalid value was provided within the packet, or a value at an invalid position might get interpreted as a domain name length because of other errors in the packet (for example, a misplaced Null-terminator or an invalid compression pointer) 🫶

The number of domain label characters must match the value of the domain label octet. To avoid errors when interpreting the characters of a domain label, developers may consider the recommendations for the preferred domain name syntax outlined in [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) 👑

4. Null-Terminator Placement Validation 💜

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

This issue is closely related to the absence of label and name length checks. For example, the logic behind Figures 1 and 4 will keep copying octets into the name buffer until a NUL octet shows up. That octet could be placed at an arbitrary position within an RR, or it might not be placed at all 🙈

Check out the pseudocode function in Figure 5. It returns the length of a domain name ("name") in octets so it can be used elsewhere (for example, 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 🍓

   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

"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 it also expects names to be explicitly Null-terminated, the return value of "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 of octets copied into those buffers. They may also perform other operations, depending on the implementation specifics 😱

The absence of explicit checks for the placement of the NUL octet may also make controlled memory reads and writes possible. Vulnerable implementations can be found in the code related to [CVE-2020-25107], [CVE-2020-17440], [CVE-2020-24383], and [CVE-2020-27736] 💀

As a general recommendation for mitigating these issues, developers should never trust user data to be Null-terminated 🫶 for example, to fix or mitigate the issue 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 make sure X is not larger than the buffer allocated for the name 💅✨

5. Response Data Length Validation ✨

Okay so, [RFC1035] says every RR has a variable-length string of octets holding the retrieved resource data (RDATA). Think of it like an IP address that matches the domain name someone asked about 🌸. The length of that RDATA field is set by the resource data length field (RDLENGTH), which also lives inside every RR 💖.

Here's the drama: implementations that process RRs may not check whether the RDLENGTH value is valid when they pull out the RDATA. That's a lowkey disaster 💀, because it can lead to out-of-bound read issues, and how bad that gets depends on the specific implementation. We've actually seen Denial-of-Service conditions and information leaks happen 😭.

So the rule is: 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). And the format of RDATA must conform to the TYPE and CLASS fields of the RR 🎀.

If you want to see what this looks like in the wild, check the code relevant to [CVE-2020-25108], [CVE-2020-24336], and [CVE-2020-27009] 🔥.

6. Record Count Validation 🧚

Per [RFC1035], the DNS header has four two-octet fields that tell you how many question records (QDCOUNT), answer records (ANCOUNT), authority records (NSCOUNT), and additional records (ARCOUNT) there are 📦.

Figure 6 shows a recurring anti-pattern for a function that processes DNS RRs, and it's giving "I trusted the header way too much" 🙈. The function "process_dns_records()" pulls out the ANCOUNT value ("num_answers") and a pointer to the DNS data payload ("data_ptr"). Then it loops over the answer records, decrementing "num_answers" after each one, until that value hits zero. To keep things simple, the example assumes there's only one domain name per answer. Inside the loop, the code works out the domain name length ("name_length") and moves the data payload pointer ("data_ptr") forward by "name_length + 1", so the pointer lands on the first answer record. Next, that answer record gets retrieved and processed, and "num_answers" gets decremented ✨.

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

Now the scary part 😱. If the ANCOUNT number pulled from the header ("dns_header->ancount") isn't checked against how much data is actually in the packet, and it's, say, bigger than the number of answer records that really exist, the data pointer ("data_ptr") will read outside the bounds of the packet. That can cause Denial-of-Service conditions 💀.

We used answer records as the example here, but the same logic gets reused for processing other kinds of records too, like the question (QDCOUNT), authority (NSCOUNT), and additional (ARCOUNT) records. These counts have to match the actual data in the packet 🫶. So every record count field needs to be checked before you fully parse the packet's contents. Specifically, Section 6.3 of [RFC5625] recommends that malformed DNS packets should be dropped and (optionally) logged 🍓.

For vulnerable examples, look at the code relevant to [CVE-2020-25109], [CVE-2020-24340], [CVE-2020-24334], and [CVE-2020-27737] 👑.

7. Security Considerations 💀

Okay, security is a whole main character moment and it's discussed throughout this memo 🎭. It covers implementation flaws (anti-patterns) that mess with how DNS RRs get processed. Those flaws lead to bugs like buffer overflows, read-out-of-bounds, and infinite-loop issues 😭. The security impacts are information leaks, Denial-of-Service attacks, and Remote Code Execution attacks. Yes, RCE. Take it seriously bestie 🚨.

This document also lists general recommendations for developers of DNS record parsing functionality. Following them helps prevent these implementation flaws, for example by rigorously checking the data received over the wire before processing it 🛡️💖.

8. IANA Considerations 🌈

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

9. References ⭐

9.1. Normative References

9.2. Informative References 📚

Okay bestie, here's the reading list! These are the extra resources, not the core rules, so it's all context. Some of these are CVEs (security bugs that got logged publicly), and they're worth a look if you want to see how DNS parsing has gone sideways in the wild 💀

[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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

Acknowledgements 🫶

Huge shoutout to Shlomi Oberman, who put so much work into the research that made this document happen 💖

Authors' Addresses 🦋

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


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


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


Amine Amri
Forescout Technologies
John F. Kennedylaan, 2
5612AB Eindhoven
Netherlands
Email: amine.amri@forescout.com
📦 where this page comes from