Buffer Overflow via strcpy(): How Unsafe String Copies Crash Programs and Compromise Security

Severity: Critical | Language: C | CWE: CWE-121 (Stack-Based Buffer Overflow), CWE-120 (Buffer Copy Without Checking Size of Input)

Introduction

If you've been writing C code for any length of time, you've almost certainly used strcpy(). It's simple, it's fast, and it's been in the standard library since the dawn of Unix. It's also one of the most dangerous functions in the C standard library — so dangerous that Microsoft's Security Development Lifecycle explicitly bans it, and modern compilers will warn you about it by default.

This week, a security audit uncovered five separate calls to strcpy() in src/utils/utils.c and related files, all operating on data read from external configuration files. None of them performed any bounds checking. Any one of them could have been the entry point for a devastating buffer overflow attack.

This post breaks down what went wrong, how an attacker could exploit it, and what the fix looks like — along with actionable advice to help you avoid the same mistake in your own code.

The Vulnerability Explained

What Is a Buffer Overflow?

A buffer overflow occurs when a program writes more data into a fixed-size memory region (a "buffer") than it was allocated to hold. The excess bytes spill into adjacent memory, overwriting whatever happens to live there — which might be other variables, saved return addresses, function pointers, or heap metadata.

In C, strings are null-terminated arrays of characters. When you declare:

char module_id[64];

You've reserved exactly 64 bytes on the stack. If you then do:

strcpy(module_id, user_supplied_string);

...and user_supplied_string contains 200 characters, strcpy() will happily copy all 200 of them, obliterating the 136 bytes that follow module_id on the stack.

What Was the Actual Problem?

The audit identified five calls to strcpy() across utils.c, main.c, and config.c, all sharing the same dangerous pattern:

// VULNERABLE: No bounds checking whatsoever
char color_string[32];
strcpy(color_string, config_get_value("theme_color"));  // What if this is 500 bytes?

char module_id[64];
strcpy(module_id, config_get_value("module_id"));       // Read from external file

char logo_data[256];
strcpy(logo_data, config_get_value("logo_path"));       // Attacker-controlled input

The critical detail here: the source strings are read from external configuration files. This means:

1. A user who can modify the configuration file can trigger the overflow
2. In multi-user environments, a low-privileged user might influence config values
3. If the config file is fetched from a remote source, a network attacker could craft malicious values
4. Malformed or corrupted config files (even accidental ones) can cause crashes

How Could This Be Exploited?

Let's walk through a realistic attack scenario.

Scenario: Privilege Escalation via Malicious Config File

Imagine this application runs as a background service with elevated privileges, reading a configuration file from a user-writable directory (a common pattern in desktop applications and daemons).

Step 1: The attacker identifies that module_id is read from ~/.config/app/settings.conf and copied into a 64-byte stack buffer.

Step 2: The attacker crafts a malicious config file:

# Malicious settings.conf
module_id = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x00\x00\x00\x00[shellcode_address]

Step 3: The overflow overwrites the saved return address on the stack. When the function returns, instead of going back to the legitimate caller, execution jumps to attacker-controlled code.

Step 4: Since the service runs with elevated privileges, the attacker's shellcode executes with those same privileges — full compromise.

Even without a perfectly crafted exploit, an attacker can reliably crash the application (Denial of Service) simply by supplying a string longer than the buffer.

What Memory Gets Overwritten?

The consequences depend on where the overflow occurs:

In this case, the buffers appear to be stack-allocated, making return address overwriting the primary concern.

Why Is strcpy() So Dangerous?

The function signature tells the whole story:

char *strcpy(char *dest, const char *src);

Notice what's missing: any parameter for the size of dest. strcpy() has absolutely no way to know how large the destination buffer is. It copies bytes from src to dest until it hits a null terminator (\0), and that's it. No questions asked. No safety checks. No mercy.

This is a design flaw baked into the function itself — it is architecturally incapable of being safe when the source length is not controlled by the programmer.

The Fix

What Changed

The fix replaced all five strcpy() calls with strncpy() (or equivalent bounded alternatives), adding explicit length limits that prevent writes beyond the destination buffer's size.

Before (Vulnerable):

// utils.c - BEFORE
void apply_theme_config(config_t *cfg) {
    char color_string[32];
    char module_id[64];
    char logo_data[256];

    // DANGEROUS: No bounds checking
    strcpy(color_string, config_get_string(cfg, "theme_color"));
    strcpy(module_id,    config_get_string(cfg, "module_id"));
    strcpy(logo_data,    config_get_string(cfg, "logo_path"));

    // ... use the values
}

After (Fixed):

// utils.c - AFTER
void apply_theme_config(config_t *cfg) {
    char color_string[32];
    char module_id[64];
    char logo_data[256];

    const char *raw_color  = config_get_string(cfg, "theme_color");
    const char *raw_module = config_get_string(cfg, "module_id");
    const char *raw_logo   = config_get_string(cfg, "logo_path");

    // SAFE: Bounded copy with explicit size limits
    strncpy(color_string, raw_color,  sizeof(color_string) - 1);
    strncpy(module_id,    raw_module, sizeof(module_id)    - 1);
    strncpy(logo_data,    raw_logo,   sizeof(logo_data)    - 1);

    // Ensure null termination (strncpy does NOT guarantee this)
    color_string[sizeof(color_string) - 1] = '\0';
    module_id[sizeof(module_id)       - 1] = '\0';
    logo_data[sizeof(logo_data)       - 1] = '\0';

    // ... use the values
}

Why sizeof(buffer) - 1?

The - 1 reserves one byte for the null terminator. strncpy() will copy at most n bytes — but if the source is exactly n bytes long (or longer), it will not append a null terminator. Without the explicit null-termination lines above, you'd have a different bug: an unterminated string that causes reads to run off the end of the buffer.

This is a subtle but important point: strncpy() is safer than strcpy(), but it's not foolproof. You must always null-terminate manually when using it.

Even Better: Use strlcpy() or snprintf()

Many security engineers consider strncpy() itself to be error-prone because of the null-termination gotcha. Where available, prefer:

strlcpy() (BSD/macOS, or via a compatibility library on Linux):

// strlcpy ALWAYS null-terminates and returns the length of src
// so you can detect truncation
size_t written = strlcpy(color_string, raw_color, sizeof(color_string));
if (written >= sizeof(color_string)) {
    // Truncation occurred — handle the error
    log_warning("theme_color value was truncated");
}

snprintf() (universally available, always null-terminates):

// snprintf is a great general-purpose safe string function
int written = snprintf(color_string, sizeof(color_string), "%s", raw_color);
if (written < 0 || (size_t)written >= sizeof(color_string)) {
    // Error or truncation — handle appropriately
}

Microsoft's safe string functions (Windows):

// On Windows, use the _s variants
strcpy_s(color_string, sizeof(color_string), raw_color);

Prevention & Best Practices

1. Ban strcpy(), strcat(), sprintf(), and gets() From Your Codebase

These functions are the "Banned API" list for a reason. Configure your build system to treat them as errors:

# In your Makefile or CMakeLists.txt
CFLAGS += -Wno-deprecated-declarations  # Remove any suppression of deprecation warnings
CFLAGS += -D_FORTIFY_SOURCE=2           # Enable glibc buffer overflow detection

Or use compiler-specific warnings:

gcc -Wall -Wextra -Wformat-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong

2. Always Use sizeof() With the Buffer Variable, Not a Magic Number

// BAD: Magic number — will silently break if buffer size changes
strncpy(dest, src, 63);

// GOOD: sizeof() always reflects the actual allocation
strncpy(dest, src, sizeof(dest) - 1);

3. Validate Input at the Boundary

Before copying config values into fixed-size buffers, validate their length:

const char *raw_value = config_get_string(cfg, "module_id");

if (raw_value == NULL) {
    log_error("module_id is missing from config");
    return CONFIG_ERROR_MISSING;
}

if (strlen(raw_value) >= sizeof(module_id)) {
    log_error("module_id exceeds maximum length of %zu characters", sizeof(module_id) - 1);
    return CONFIG_ERROR_INVALID;
}

strncpy(module_id, raw_value, sizeof(module_id) - 1);
module_id[sizeof(module_id) - 1] = '\0';

4. Enable Stack Protectors and ASLR

Even if a buffer overflow occurs, mitigation technologies can prevent exploitation:

# Stack canaries (detect stack smashing at runtime)
gcc -fstack-protector-strong

# Address Space Layout Randomization (makes it harder to predict target addresses)
# Enable system-wide on Linux:
echo 2 > /proc/sys/kernel/randomize_va_space

# Position-Independent Executable (required for full ASLR benefit)
gcc -fPIE -pie

5. Use Static Analysis Tools

Catch these issues before they reach production:

# Run with AddressSanitizer during development/testing
gcc -fsanitize=address -fsanitize=undefined -g -o app app.c
./app  # ASan will report any buffer overflows at runtime

6. Consider Safer Languages for New Code

If you're starting a new project or can refactor, languages like Rust eliminate this entire class of vulnerability through compile-time memory safety guarantees. Interestingly, this project already has Rust dependencies in src-tauri/Cargo.lock — extending Rust's coverage to the string-handling utilities would prevent this class of bug entirely.

Security Standards & References

• CWE-120: Buffer Copy without Checking Size of Input ("Classic Buffer Overflow")
• CWE-121: Stack-based Buffer Overflow
• CWE-122: Heap-based Buffer Overflow
• OWASP: Buffer Overflow
• CERT C Coding Standard: STR31-C. Guarantee that storage for strings has sufficient space for character data and the null terminator
• Microsoft SDL Banned APIs: Banned.h
• SANS Top 25: CWE/SANS Top 25 Most Dangerous Software Errors

Conclusion

Buffer overflows via strcpy() are one of the oldest vulnerabilities in software security — the Morris Worm exploited one in 1988. Yet here we are, still finding them in production code in 2024. That's not a criticism; it's a reminder that these bugs are easy to write, subtle to spot in code review, and genuinely dangerous in practice.

The key takeaways from this vulnerability:

1. strcpy() is never safe when the source string comes from outside your direct control. Treat it like a loaded weapon.
2. External configuration files are attacker-controlled input in many threat models. Validate and bound-check everything you read from them.
3. strncpy() is safer, but requires explicit null termination. Prefer strlcpy() or snprintf() where possible.
4. Defense in depth matters. Stack protectors, ASLR, and PIE don't prevent the bug, but they significantly raise the bar for exploitation.
5. Automate the detection. Flawfinder can flag every strcpy() call in your codebase in seconds. There's no excuse for not running it in CI.

Security vulnerabilities like this one are fixed one patch at a time — and every developer who understands why strcpy() is dangerous is one more line of defense between attackers and users. Write safe code, review for these patterns, and keep building.

This vulnerability was identified and patched by OrbisAI Security. Automated security scanning caught what manual review missed — a great example of why layered security tooling matters.