This file presents the Vulnerability Anti-Patterns developed in the work "Cluster Crash: Learning from Recent Vulnerabilities in Communication Stacks" (published at ICISSP 20202) which we were not able to include in the paper (caused by page limitations). The Vulnerability Anti-Patterns follow the structure proposed by Naffees at al. in their work "Vulnerability anti-patterns: a timeless way to capture poor software practices (Vulnerabilities)" (Ressource).
In order to explain the Anti-Patterns and give examples, we use three different code examples you will find below.
[1] while (*pkg) {
[2] len = *(pkg +1);
[3] switch (*pkg) {
[4] case NOOP:
[5] len = 1;
[6] break;
[7] case OPTIONA:
[8] memcpy(optiona, pkg+2, len−2);
[9] break;
[10] default :
[11] break;
[12] }
[13] pkg += len ;
[14] }
Listing 1: Example option parsing.
[1] char *start = pkg + optionslength ;
[2] char optiona[4];
[3] while (pkg < start && *pkg) {
[4] if (*pkg == NOOP) {
[5] pkg += 1;
[6] continue;
[7] }
[8] if (pkg + 1 < start)
[9] error (MALFORMED_OPTION);
[10] len = *(pkg + 1);
[11] if (len < 2 || pkg + len > start)
[12] error (MALFORMED_OPTION);
[13] switch (*pkg) {
[14] case OPTIONA:
[15] memcpy( optiona , pkg+2, len −2);
[16] break;
[17] default:
[18] break;
[19] }
[20] pkg += len ;
[21] }
Listing 2: Example option parsing with range checks.
[1] char *parsename (char *pkg, char **name)
[2] {
[3] char *res = malloc(256);
[4] char *pos = res;
[5] int llen;
[6] char *sub;
[7] while ((llen = **name)) {
[8] *name += 1;
[9] if ((llen&0xc0) == 0xc0 ) {
[10] llen = ((llen&0xc0) << 8) + **name;
[11] *name += 1;
[12] sub = pkg+llen ;
[13] sub = parsename (pkg , &sub);
[14] strcpy (pos, sub);
[15] free(sub);
[16] return res ;
[17] }
[18] memcpy(pos, *name, llen);
[19] *name += llen;
[20] pos += llen;
[21] *pos = '.';
[22] pos++;
[23] }
[24] *(pos−1) = '\0';
[25] return res ;
[26] }
Listing 3: Example DNS name parsing.
The following tables show the Vulnerability Anti-Patterns.
Table 1: Anti-Pattern: Assume validity of length / offset field.
| Category | Description |
|---|---|
| General Information | |
| Anti-Pattern Name | Assume validity of length / offset field |
| Also known as | Improper validation of length and offset field(s) |
| CWE Mapping | CWE-130: Improper Handling of Length Parameter Inconsistency |
| CVE Examples | CVE-2020-11912, CVE-2020-17441 |
| Anti-Pattern | |
| Anti-Pattern Example | Consider the example code in Listing 1. In this case, the parser trusts the supplied length input without checking it against the real length of the given input. If an attacker sends a packet which contains a length field with the value of 255 and has option A set, but only contains 64 bytes of data, an out-of-bounds read will happen in line 8. |
| Typical Causes | Lack of input validation, and missing range checks |
| Known Exploitation | |
| Attack Patterns | CAPEC-540 |
Table 2: Anti-Pattern: Assume minimum value of length
| Category | Description |
|---|---|
| General Information | |
| Anti-Pattern Name | Assume minimum value of length |
| Also known as | Improper validation of length and offset field(s) |
| CWE Mapping | CWE-130: Improper Handling of Length Parameter Inconsistency |
| CVE Examples | CVE-2020-13984, CVE-2019-12255 |
| Anti-Pattern | |
| Anti-Pattern Example | Consider again the example code in Listing 1. If an attacker sends a packet which has option A set, and the length field set to 0, an Integer underflow is provoked in line 8. This leads to an out-of-bounds read and write. The cause for this is the implicit assumption that the length will not be smaller than 2. In addition, the code will not terminate. This is the case since the length variable will be set to 0, and the packet pointer will not be changed (line 13). |
| Typical Causes | Lack of input validation, and missing range checks |
| Known Exploitation | |
| Attack Patterns | CAPEC-540 |
Table 3: Anti-Pattern: Assume data is as long as required
| Category | Description |
|---|---|
| General Information | |
| Anti-Pattern Name | Assume data is as long as required |
| Also known as | Improper validation of length and offset field(s) |
| CWE Mapping | CWE-120: Buffer Copy without Checking Size of Input |
| CVE Examples | CVE-2019-12257 |
| Anti-Pattern | |
| Anti-Pattern Example | Let option A be an option that requires a fixed length of 4. The parser in Listing 2 will validate that the option doesn’t overflow (line 11), but at option handling it isn’t checked if the option meets the requirements (line 15). If an attacker sends a packet including an option A with more than 4 bytes, an overflow will occur in line 15. |
| Typical Causes | Missing range checks |
| Known Exploitation | |
| Attack Patterns | CAPEC-540 |
Table 4: Anti-Pattern: Not validating name length
| Category | Description |
|---|---|
| General Information | |
| Anti-Pattern Name | Not validating name length |
| Also known as | Improper validation of label length in DNS name |
| CWE Mapping | CWE-130: Improper Handling of Length Parameter Inconsistency |
| CVE Examples | CVE-2020-17440, CVE-2020-24335, CVE-2020-24339, CVE-2020-24383,CVE-2020-25107, CVE-2020-25110, CVE-2020-17467 |
| Anti-Pattern | |
| Anti-Pattern Example | The code presented in Listing 3 never checks if the length of a label is smaller than the remaining length of the resarray. With this, an attacker can construct a DNS name longer then 256 and cause an out of bound write in res (lines 14 and 18). In addition, the code does not include a check if the labels are smaller than 64 bytes. |
| Typical Causes | Lack of input validation |
| Known Exploitation | |
| Attack Patterns | - |
Table 5: Anti-Pattern: Improper handling of compression pointers
| Category | Description |
|---|---|
| General Information | |
| Anti-Pattern Name | Improper handling of compression pointers |
| Also known as | DNS forward referencing |
| CWE Mapping | CWE-20: Improper Input Validation |
| CVE Examples | CVE-2020-11901, CVE-2020-24339 |
| Anti-Pattern | |
| Anti-Pattern Example | In DNS, the compression is implemented with a pointer to the “prior occurrence of the same name” (RFC 1035). The parser presented in Listing 3 does not validate that the resulting pointer is smaller than the current packages (line 9). With this, an attacker can craft a packet with a DNS name including a compression pointer which points outside the packet. This will lead to an out-of-bounds read in line 7. |
| Typical Causes | Lack of input validation |
| Known Exploitation | |
| Attack Patterns | - |
Table 6: Loops by not fully parsed names referenced by compression pointer
| Category | Description |
|---|---|
| General Information | |
| Anti-Pattern Name | Loops by not fully parsed names referenced by compression pointer |
| Also known as | DNS compression loops |
| CWE Mapping | CWE-20: Improper Input Validatio |
| CVE Examples | CVE-2020-11901, CVE-2020-24338, CVE-2020-7461 |
| Anti-Pattern | |
| Anti-Pattern Example | In addition to the already described Anti-Pattern not to check whether the compression pointer points to a position outside the packet, it is also an Anti-Pattern not to check whether the compression pointer actually points to the beginning of a prior name. The code presented in Listing 3 also does not include this check. If an attacker crafts a packet including a self-referencing compression pointer, an endless recursion would happen in line 13. However, even if self-referencing pointer are checked, an attacker could still craft a packet which includes pointer looping endlessly. This can also leed to an out of bounds write, because the code in line 13 don’t check the length of the referenced name. In contrast to the other Anti-Patterns, this issue requires complex data structures to be able to perform all necessary checks. |
| Typical Causes | Lack of input validation |
| Known Exploitation | |
| Attack Patterns | - |