Critical Heap Buffer Overflow in SSDP Control Point: How Unbounded String Operations Put Networks at Risk

Severity: Critical | CWE: CWE-120 (Buffer Copy without Checking Size of Input) | File: upnp/src/ssdp/ssdp_ctrlpt.c

Introduction

Buffer overflows are among the oldest and most dangerous vulnerability classes in systems programming — and they keep showing up in production code. This post dives into a critical heap buffer overflow discovered in the SSDP (Simple Service Discovery Protocol) control point implementation of a UPnP library, explains exactly how it could be exploited, and walks through the fix that closes the door on this attack vector.

If you write C or C++ code that processes network data, this one is for you. Even if you don't, understanding why unbounded string operations are dangerous is essential knowledge for any developer who cares about the security of the systems they build.

What Is SSDP and Why Does It Matter?

SSDP (Simple Service Discovery Protocol) is the discovery mechanism at the heart of UPnP (Universal Plug and Play). It's how your smart TV finds your router, how a media server announces itself to clients, and how IoT devices broadcast their capabilities on a local network.

The control point side of SSDP is responsible for sending M-SEARCH requests — essentially asking "who's out there?" — and processing the responses. Because SSDP operates over UDP and accepts responses from any device on the network, it is a natural target for network-based attacks. Malicious or malformed responses are trivial to craft and inject.

The Vulnerability Explained

What Went Wrong

Inside CreateClientRequestPacket(), the code was responsible for building an HTTP-style M-SEARCH request buffer (RqstBuf). The original implementation did this in several stages using a combination of strcpy, strcat, and snprintf into an intermediate TempBuf:

// VULNERABLE CODE (before the fix)
char TempBuf[COMMAND_LEN];
const char *command = "M-SEARCH * HTTP/1.1\r\n";
const char *man = "MAN: \"ssdp:discover\"\r\n";

memset(TempBuf, 0, sizeof(TempBuf));
if (RqstBufSize <= strlen(command))
    return UPNP_E_INTERNAL_ERROR;
strcpy(RqstBuf, command);          // ⚠️ No overflow check after this point

// ... snprintf into TempBuf for the HOST header ...

if (RqstBufSize <= strlen(RqstBuf) + strlen(TempBuf))
    return UPNP_E_BUFFER_TOO_SMALL;
strcat(RqstBuf, TempBuf);          // ⚠️ Race between check and use

if (RqstBufSize <= strlen(RqstBuf) + strlen(man))
    return UPNP_E_BUFFER_TOO_SMALL;
strcat(RqstBuf, man);              // ⚠️ Another unbounded append

// ... and so on for MX header, ST header, etc.

There are several compounding problems here:

1. strcpy without bounds checking — The initial strcpy(RqstBuf, command) checks that RqstBufSize > strlen(command), but this check only validates the first write. All subsequent strcat calls append to a buffer that is being filled incrementally, with each check only loosely validating the current state.

2. TOCTOU-style logic errors — The pattern if (RqstBufSize <= strlen(RqstBuf) + strlen(TempBuf)) return error; strcat(RqstBuf, TempBuf); is fragile. The length check and the write are not atomic, and more importantly, the check uses <= instead of <, meaning a perfectly full buffer passes the check and then overflows by one byte on the strcat.

3. Network-controlled input flows into the buffer — Fields like service type (ST) headers and location URLs come directly from network-received SSDP responses. An attacker on the same network segment can craft a response with an oversized ST field. When this value is concatenated into RqstBuf without strict length enforcement, the buffer overflows onto the heap.

How Could This Be Exploited?

Here's a realistic attack scenario:

1. An attacker connects to the same local network as a device running the vulnerable UPnP control point (common in home networks, hotel Wi-Fi, corporate LANs, or any shared network).
2. The control point broadcasts an SSDP M-SEARCH request.
3. The attacker's machine responds with a crafted SSDP response containing an oversized ST (Service Type) field — for example, a string of several kilobytes instead of the expected short identifier like upnp:rootdevice.
4. The vulnerable code copies this attacker-controlled string into RqstBuf via strcat, writing far beyond the allocated heap buffer.
5. The overflow corrupts adjacent heap metadata or data, potentially enabling:
   - Arbitrary code execution via heap metadata manipulation
   - Denial of service via heap corruption and crash
   - Information disclosure if heap layout can be influenced to leak adjacent memory

Because SSDP uses UDP and requires no authentication, this attack requires no credentials, no prior access, and no user interaction — just network adjacency.

CWE-120: The Classic "Dangerous Function" Problem

This vulnerability is classified under CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'). The C standard library functions strcpy and strcat are considered dangerous precisely because they perform no bounds checking. The destination buffer's size is never consulted — they simply write until they hit a null terminator in the source string.

The CERT C Coding Standard, MISRA C, and virtually every modern secure coding guideline explicitly prohibit the use of strcpy and strcat in code that handles externally-sourced data.

The Fix

What Changed

The fix replaces the fragmented, multi-step string construction approach with a single, offset-tracked snprintf pattern. Here's the corrected code:

// FIXED CODE (after the patch)
size_t offset = 0;

switch (AddressFamily) {
case AF_INET:
    rc = snprintf(RqstBuf,
        RqstBufSize,
        "M-SEARCH * HTTP/1.1\r\n"
        "HOST: %s:%d\r\n"
        "MAN: \"ssdp:discover\"\r\n",
        SSDP_IP,
        SSDP_PORT);
    break;
case AF_INET6:
    rc = snprintf(RqstBuf,
        RqstBufSize,
        "M-SEARCH * HTTP/1.1\r\n"
        "HOST: [%s]:%d\r\n"
        "MAN: \"ssdp:discover\"\r\n",
        SSDP_IPV6_LINKLOCAL,
        SSDP_PORT);
    break;
default:
    return UPNP_E_INVALID_ARGUMENT;
}

if (rc < 0 || (size_t)rc >= RqstBufSize)
    return UPNP_E_INTERNAL_ERROR;
offset = (size_t)rc;

if (Mx > 0) {
    rc = snprintf(RqstBuf + offset,
        RqstBufSize - offset,
        "MX: %d\r\n",
        Mx);
    if (rc < 0 || (size_t)rc >= RqstBufSize - offset)
        return UPNP_E_BUFFER_TOO_SMALL;
    offset += (size_t)rc;
}

Why This Fix Works

Let's break down the security improvements:

1. snprintf Enforces Hard Limits

snprintf(dest, n, ...) will never write more than n bytes (including the null terminator) to the destination buffer. There is no scenario in which it overflows — if the formatted output would exceed the limit, it is truncated and the function returns the number of bytes that would have been written, allowing the caller to detect truncation.

2. Offset Tracking Eliminates Cumulative Errors

Instead of using strlen(RqstBuf) to find the current end of the buffer (which is O(n) and error-prone), the fix maintains an explicit offset variable. Each snprintf call writes to RqstBuf + offset with a remaining capacity of RqstBufSize - offset. This is both more efficient and more correct — there's no possibility of miscounting.

3. Truncation Is Detected and Rejected

After each snprintf, the return value rc is checked:
- rc < 0 → encoding error, return failure
- (size_t)rc >= RqstBufSize - offset → output was truncated (or would have been), return failure

This means the code fails safely rather than silently producing a malformed or truncated buffer that could cause downstream issues.

4. The Intermediate Buffer Is Eliminated

The original code used TempBuf[COMMAND_LEN] as a staging area, introducing an extra potential overflow point. The fix writes directly into RqstBuf with full size awareness, removing an entire class of intermediate buffer issues.

5. Consolidation Reduces Attack Surface

By consolidating the static header lines (M-SEARCH, HOST, MAN) into a single snprintf call, the fix reduces the number of operations that touch the buffer — fewer operations means fewer opportunities for mistakes.

Before vs. After: A Side-by-Side Comparison

Prevention & Best Practices

1. Never Use strcpy or strcat on Untrusted Data

These functions should be treated as deprecated in any security-sensitive context. Modern alternatives include:

• snprintf — for formatted output with size limits
• strlcpy / strlcat — BSD extensions that always null-terminate and respect buffer size (not available everywhere, but widely portable)
• strncpy — use with caution; it does not guarantee null termination
• memcpy with explicit length — when you know the exact byte count

2. Use the Offset Pattern for Buffer Construction

When building a buffer incrementally, always track the current write position explicitly:

size_t offset = 0;
size_t remaining = buf_size;

int n = snprintf(buf + offset, remaining, "part one: %s\n", val1);
if (n < 0 || (size_t)n >= remaining) return ERROR;
offset += (size_t)n;
remaining -= (size_t)n;

n = snprintf(buf + offset, remaining, "part two: %s\n", val2);
if (n < 0 || (size_t)n >= remaining) return ERROR;
offset += (size_t)n;

This pattern is clear, efficient, and safe.

3. Treat All Network Data as Hostile

Any data received from the network — regardless of the protocol — must be treated as potentially malicious. For SSDP specifically:
- Validate and cap the length of all response fields before processing
- Use strict length limits on service type strings, location URLs, and other variable-length fields
- Consider allowlisting expected field formats with regex or explicit parsing

4. Enable Compiler and Runtime Protections

While not a substitute for correct code, these defenses raise the cost of exploitation:

• -D_FORTIFY_SOURCE=2 — GCC/Clang compile-time and runtime buffer overflow detection
• Stack canaries (-fstack-protector-strong) — detect stack smashing
• AddressSanitizer (-fsanitize=address) — catch buffer overflows during testing
• Heap hardening — modern allocators (like glibc's) include metadata integrity checks

5. Static Analysis

Tools that can catch this class of vulnerability during development:

• Coverity — industry-standard static analyzer, excellent at buffer overflow detection
• CodeQL — GitHub's semantic code analysis, has specific queries for CWE-120
• Clang Static Analyzer — free, built into LLVM
• Flawfinder / rats — lightweight scanners that flag dangerous C functions

6. Follow Established Secure Coding Standards

• CERT C Coding Standard — Rule STR31-C: "Guarantee that storage for strings has sufficient space for character data and the null terminator"
• OWASP — Buffer Overflow
• CWE-120 — Buffer Copy without Checking Size of Input
• MISRA C 2012 — Rule 21.6 prohibits use of <stdio.h> input functions without bounds; similar restrictions on string functions

Key Takeaways

1. strcpy and strcat are dangerous — they perform no bounds checking and should never be used with data that originates from the network or user input.

2. The "check then use" pattern is fragile — checking strlen before strcat is not sufficient. Use snprintf with explicit size limits instead.

3. Network protocols are attack surfaces — SSDP operates without authentication on local networks. Any device on your Wi-Fi can send crafted SSDP responses. Buffer overflows in SSDP parsers are reachable with zero credentials.

4. The fix is simple and elegant — replacing a tangle of strcpy/strcat calls with offset-tracked snprintf calls eliminates the vulnerability class entirely, not just the specific instance.

5. Defense in depth matters — compiler hardening, runtime sanitizers, and static analysis complement correct code. Use all of them.

Buffer overflows in C have been known since the 1970s and have been responsible for some of the most devastating exploits in computing history — from the Morris Worm to countless remote code execution vulnerabilities in network daemons. The fact that they still appear in modern codebases is a reminder that secure coding requires constant vigilance, good tooling, and a healthy skepticism toward any code that touches a network socket.

Write safe code. Validate your inputs. And when in doubt, use snprintf.

This vulnerability was identified and fixed by OrbisAI Security using automated security scanning and AI-assisted code review.