Critical DNS Integer Overflow: How a +1 Nearly Enabled Remote Code Execution

Vulnerability: CWE-190 — Integer Overflow in DNS Record Length Handling
Severity: Critical
File: lib/proxy/dns.c:452
Fixed by: OrbisAI Security Automated Scan + Manual Remediation

Introduction

Sometimes the most dangerous bugs in software aren't dramatic logic errors or missing authentication checks — they're a single arithmetic operation that wraps around in a way nobody anticipated. This post covers exactly that kind of vulnerability: an integer overflow in DNS record processing code that could have handed a remote attacker the keys to the kingdom.

If your application processes DNS responses from external servers — especially SRV records — this class of vulnerability should be on your radar. It's subtle, it's dangerous, and it's the kind of issue that slips through code review because the code looks completely reasonable at first glance.

The Vulnerability Explained

What Is an Integer Overflow?

An integer overflow occurs when an arithmetic operation produces a value that exceeds the maximum value a given integer type can hold. In C, this typically causes the value to wrap around silently — no exception, no crash, no warning. The program just keeps running with a completely wrong number.

For a 32-bit unsigned integer (uint32_t), the maximum value is 4,294,967,295 (or 0xFFFFFFFF). Add 1 to that, and you get 0 — not an error, just zero.

The Vulnerable Code Pattern

The vulnerability existed in lib/proxy/dns.c around line 452. The pattern looked something like this:

// VULNERABLE CODE (simplified for illustration)
uint32_t target_len = get_dns_record_length(response);  // from external input
uint32_t record_len = get_dns_record_data_length(response); // from external input

// +1 for null terminator — looks innocent, right?
char *buffer = malloc(target_len + 1);
memcpy(buffer, dns_record_data, record_len);

This code pattern is extremely common in C. You allocate space for a string plus a null terminator. Developers write this thousands of times without incident. But here's the trap:

What happens when target_len is 0xFFFFFFFF (the maximum value)?

target_len + 1 = 0xFFFFFFFF + 1 = 0x100000000

On a 32-bit integer, that wraps around to 0. So malloc(0) is called. Depending on the platform, malloc(0) either returns NULL or returns a valid pointer to a near-zero-sized allocation. Then memcpy copies potentially hundreds of bytes into that tiny buffer.

The result: a heap buffer overflow.

How Could It Be Exploited?

The attack scenario is straightforward for a threat actor in a position to influence DNS responses:

1. Attacker controls or compromises a DNS server that your application queries (this could be through DNS poisoning, a rogue resolver, or a man-in-the-middle position on an untrusted network).

2. Attacker crafts a malicious SRV record with target_len or record_len values set near 0xFFFFFFFF.

3. Application receives the response and passes the length values directly into the size calculation without validation.

4. malloc(0) or malloc(small_value) is called, returning a tiny or invalid buffer.

5. memcpy copies the full DNS record data into the undersized buffer, overflowing the heap.

6. Heap metadata is corrupted, and with enough control over the overflow content, an attacker can redirect execution flow — achieving Remote Code Execution (RCE).

Normal case:
  target_len = 100
  malloc(100 + 1) = malloc(101)  ✓  Safe allocation

Attack case:
  target_len = 0xFFFFFFFF (4294967295)
  malloc(0xFFFFFFFF + 1) = malloc(0)  ✗  Near-zero allocation!
  memcpy(tiny_buffer, attacker_data, large_size)  💥  HEAP OVERFLOW

Real-World Impact

This vulnerability is particularly dangerous because:

• It's remotely triggerable — no local access required, just network access to influence DNS responses
• It affects a parsing path — DNS is fundamental infrastructure; almost every networked application uses it
• Heap overflows are exploitable — modern exploitation techniques (heap feng shui, tcache poisoning, etc.) make heap overflows reliably exploitable on many platforms
• The overflow content is attacker-controlled — the DNS record data being copied is supplied by the attacker, giving them control over what gets written beyond the buffer boundary

In a worst-case scenario on a vulnerable system, this could lead to full remote code execution with the privileges of the running process.

The Fix

The Core Principle: Validate Before You Calculate

The fix for integer overflow vulnerabilities in C follows a simple but critical principle: never perform arithmetic on untrusted values without first checking for overflow.

There are two main approaches:

Approach 1: Pre-check the value before addition

// SAFE: Check before the addition can overflow
if (target_len > SIZE_MAX - 1) {
    // Handle error: length is too large
    log_error("DNS record length too large: %u", target_len);
    return DNS_PARSE_ERROR;
}

char *buffer = malloc(target_len + 1);
if (buffer == NULL) {
    return DNS_ALLOC_ERROR;
}

Approach 2: Use safe integer libraries or compiler builtins

// SAFE: Using GCC/Clang built-in overflow detection
size_t alloc_size;
if (__builtin_add_overflow(target_len, 1, &alloc_size)) {
    log_error("Integer overflow in DNS record allocation");
    return DNS_PARSE_ERROR;
}

char *buffer = malloc(alloc_size);
if (buffer == NULL) {
    return DNS_ALLOC_ERROR;
}

Approach 3: Cap input values at a reasonable maximum

// SAFE: Enforce a maximum record length from the start
#define MAX_DNS_RECORD_LEN 65535  // DNS protocol limit

if (target_len > MAX_DNS_RECORD_LEN || record_len > MAX_DNS_RECORD_LEN) {
    log_error("DNS record length exceeds protocol maximum");
    return DNS_PARSE_ERROR;
}

// Now this addition is provably safe
char *buffer = malloc(target_len + 1);

Approach 4: Also validate that the copy size matches the allocation

Even after fixing the allocation size, you should ensure the copy doesn't exceed the buffer:

// SAFE: Full defense-in-depth approach
if (target_len > MAX_DNS_RECORD_LEN) {
    return DNS_PARSE_ERROR;
}

size_t alloc_size = target_len + 1;  // Safe because target_len <= 65535
char *buffer = malloc(alloc_size);
if (buffer == NULL) {
    return DNS_ALLOC_ERROR;
}

// Ensure we don't copy more than we allocated
if (record_len >= alloc_size) {
    free(buffer);
    return DNS_PARSE_ERROR;
}

memcpy(buffer, dns_record_data, record_len);
buffer[record_len] = '\0';  // Safe null termination

Why This Fix Works

The fix addresses the root cause by ensuring that the arithmetic operation can never produce an unexpected result. By validating inputs before using them in size calculations:

1. Values that would cause overflow are rejected early
2. The malloc call always receives a meaningful, correct size
3. The memcpy operation is bounded by the actual allocated size
4. The program fails safely with an error rather than silently corrupting memory

Prevention & Best Practices

1. Treat All External Data as Hostile

DNS responses, network packets, file contents, user input — any data that originates outside your process boundary is untrusted. Always validate lengths, sizes, and counts before using them in arithmetic or memory operations.

// Rule of thumb: validate BEFORE use, not after
uint32_t len = parse_external_length(data);

// ✗ Bad: use first, maybe check later
char *buf = malloc(len + 1);

// ✓ Good: validate first, then use
if (len > MAX_SAFE_LENGTH) return ERROR;
char *buf = malloc(len + 1);  // Now safe

2. Use size_t for Memory Sizes

Always use size_t (not int, uint32_t, or unsigned int) for variables that represent memory sizes or allocation amounts. size_t is guaranteed to be the natural word size of the platform and matches what malloc expects.

// ✗ Potentially problematic
uint32_t len = external_value;
malloc(len + 1);

// ✓ Better
size_t len = (size_t)external_value;
if (len > MAX_ALLOWED) return ERROR;
malloc(len + 1);

3. Know Your Protocol Limits

DNS has well-defined limits in the RFCs. SRV record fields have maximum values. Use these as your validation bounds:

• DNS labels: max 63 bytes
• DNS names: max 255 bytes
• DNS record data: max 65535 bytes (limited by 16-bit RDLENGTH field)

Encoding these limits as named constants makes the intent clear and the code self-documenting.

4. Enable Compiler Sanitizers During Development

Modern compilers and sanitizers can catch integer overflows at runtime during testing:

# AddressSanitizer catches heap overflows
gcc -fsanitize=address -g -o myapp myapp.c

# UndefinedBehaviorSanitizer catches integer overflows
gcc -fsanitize=undefined -g -o myapp myapp.c

# Use both together during development/testing
gcc -fsanitize=address,undefined -g -o myapp myapp.c

5. Use Static Analysis Tools

Several tools can detect integer overflow vulnerabilities statically:

• Coverity — commercial static analyzer with strong integer overflow detection
• CodeQL — GitHub's semantic code analysis engine (free for open source)
• Clang Static Analyzer — built into the LLVM toolchain
• Flawfinder / RATS — lightweight C/C++ security scanners
• PVS-Studio — commercial analyzer with CWE mapping

6. Consider Safer Abstractions

If you're writing new code, consider whether you can use safer abstractions:

• Rust — ownership model and integer overflow checks (in debug mode) prevent many of these issues by default
• C++ with bounds-checked containers — std::vector, std::string handle sizing internally
• Safe C libraries — libraries like safec provide bounds-checked versions of string functions

7. Security Standards and References

This vulnerability maps to well-documented security weaknesses:

• CWE-190: Integer Overflow or Wraparound — cwe.mitre.org/data/definitions/190
• CWE-122: Heap-based Buffer Overflow — cwe.mitre.org/data/definitions/122
• OWASP: Buffer Overflow Attack — owasp.org/www-community/attacks/Buffer_overflow_attack
• CERT C Coding Standard: INT30-C (Ensure unsigned integer operations do not wrap), MEM35-C (Allocate sufficient memory for an object)

A Note on the Mismatch Between Vulnerability Reports

Careful readers may notice that the original vulnerability report in the context also mentioned a separate issue: OAuth tokens and API keys stored in plaintext on the filesystem (in plugins/auth-oauth2/src/store.ts). This is a real and serious vulnerability in its own right — credentials should always be encrypted at rest, and available cryptographic primitives like PBKDF2 should be used for key derivation.

However, the actual PR fix addressed the DNS integer overflow in lib/proxy/dns.c. This serves as a reminder: always verify that security fixes actually address the reported vulnerability, and that a single PR doesn't inadvertently leave other reported issues unresolved. Both issues deserve fixes — neither should be lost in the noise.

Conclusion

The integer overflow in DNS record length handling is a textbook example of why security in C requires constant vigilance. The vulnerable code pattern — malloc(external_len + 1) — looks completely normal. It's the kind of code that passes casual code review without a second glance. Yet under the right conditions, it creates a heap overflow exploitable for remote code execution.

Key takeaways:

• ✅ Always validate external length values before using them in arithmetic or allocation
• ✅ Check for overflow before it happens, not after
• ✅ Use protocol-defined maximums as hard bounds on input values
• ✅ Enable sanitizers during development and testing to catch these issues early
• ✅ Use static analysis as part of your CI/CD pipeline
• ✅ Defense in depth: validate inputs, check allocation success, and bound copy operations

The best security vulnerabilities to fix are the ones you find before an attacker does. Automated scanning, rigorous code review, and a security-conscious development culture are your best defenses against this class of subtle but critical bugs.

This vulnerability was identified and fixed by OrbisAI Security. Stay secure, validate your inputs, and never trust data from the network.