CWE-120 Classic Buffer Overflow: Copying Input Without a Size Check

CWE-120 is what most people picture when they hear "buffer overflow". The product copies an input buffer to an output buffer without checking that the input is smaller than the output. MITRE calls it Buffer Copy without Checking Size of Input, the classic buffer overflow.

It affects memory-unsafe languages, listed by MITRE as C, C++ and assembly. It is one of the oldest bug types in the book, and it still turns up in parsers, network daemons, embedded firmware and command line tools. Anyone who ships or depends on native code can be hit by it.

How it happens

The pattern is a copy where the length is decided by the data, not by the destination. A function such as strcpy, strcat, sprintf or gets keeps writing until it hits the end of the source. If the destination is smaller, the extra bytes land in whatever sits next to it.

// Vulnerable: argv[1] can be any length
int main(int argc, char **argv) {
    char user[32];
    strcpy(user, argv[1]);
    printf("user=%s\n", user);
    return 0;
}

The observed examples on MITRE's page show how many places input can come from. CVE-1999-0046 is a buffer overflow in a local program using a long environment variable. CVE-2000-1094 involves a command with a long argument. CVE-2003-0595 is an attacker replacing a valid cookie value with an extremely long string to overflow the application's buffers.

The record also lists CVE-2002-1337, a good reminder that the bug is not always a plain strcpy. There, a counter was incremented for one comment character but not decremented for the matching one, so the size bookkeeping went wrong and the buffer overflowed.

Whether the buffer lives on the stack or the heap, the root cause is the same: the code never compared the two sizes. The stack and heap forms have their own entries, CWE-121 and CWE-122.

What an attacker gains

MITRE lists two main consequences.

Arbitrary code execution. Buffer overflows can often be used to run code of the attacker's choosing, which is outside the product's implicit security policy. MITRE notes this can subvert any other security service. If the program runs with high privilege, so does the attacker's code.

Denial of service. Overflows generally lead to crashes. Other availability attacks are possible too, including pushing the product into an infinite loop. Even when code execution is not practical, a remote crash in a network service is a real problem.

How to find it

• Static analysis. MITRE says automated tools that use data flow analysis or constraint-based techniques can often find this weakness and keep false positives down. They do not always account for environment details, so use them as one signal.
• Fuzzing. Feed the program large numbers of diverse inputs, including very long ones, and watch for crashes.
• Compiler runtime checks. Build with AddressSanitizer for C and C++ so an overflow stops the run with a report instead of silently corrupting memory.
• Manual review. Useful, but MITRE warns it may not reach good coverage in limited time. Grep for the usual suspects and read each call site.

A quick review starting point is a search for strcpy, strcat, sprintf, gets and scanf("%s") in your own code. Every hit needs an answer to one question: where is the proof the source fits?

How to fix it

The record has no mitigation list, so these steps come from the weakness definition and common practice.

1. Make the destination size part of every copy. Use snprintf, strlcpy where available, or memcpy with a checked length.
2. Check the length of external input before copying, and reject input that is too long instead of silently truncating when truncation would change meaning.
3. Prefer types that track their own length, such as std::string and std::vector in C++.
4. Compile with ASan in test builds and run a fuzzer in CI.
5. Retire gets. It cannot be used safely.

// Fixed: bounded copy, explicit rejection
int main(int argc, char **argv) {
    char user[32];
    if (argc < 2 || strlen(argv[1]) >= sizeof user) {
        fprintf(stderr, "username too long\n");
        return 1;
    }
    memcpy(user, argv[1], strlen(argv[1]) + 1);
    printf("user=%s\n", user);
    return 0;
}

Dependencies matter too

Most classic overflows you meet in production live in third-party code. List what you ship and check it. The free in-browser dependency scan needs no login, keeps your file on your machine, and handles up to 100 dependencies.

Quick check

Sources

• MITRE CWE-120
• Safeguard Gold entry for CWE-120