CWE-676 Dangerous Functions: Why strcpy Keeps Biting and What to Use

CWE-676, Use of Potentially Dangerous Function, describes code that calls a function which can be used safely but very easily is not. MITRE lists C and C++ as the affected platforms. If you maintain native code, a parser, a daemon or a library with a C core, this one is yours.

The key word is "potentially." The function is not broken. It just puts the whole burden of correctness on the caller, and callers get tired, rushed and wrong.

How it happens

Think of the classic string functions: strcpy, strcat and sprintf. None of them knows how big the destination buffer is. They copy until they hit a terminator, and the programmer is supposed to have checked the length beforehand. Often nobody did.

MITRE's observed examples read like a pattern. CVE-2007-1470 is a library with multiple buffer overflows using sprintf() and strcpy(). CVE-2009-3849 is a buffer overflow using strcat(). CVE-2006-2114 and CVE-2006-0963 are both buffer overflows using strcpy().

Here is the vulnerable shape. This is an illustration, not code from any of those CVEs.

// Vulnerable: no length check, name can be any size
void greet(const char *name) {
    char buf[32];
    strcpy(buf, name);
    printf("Hello, %s\n", buf);
}

If name is longer than 31 characters, strcpy writes past the end of buf.

What an attacker gains

MITRE's consequence entry for this weakness is deliberately open: impact varies by context, and the record mentions quality degradation and unexpected state. The wording is vague because the function itself decides nothing. What happens depends on how it was misused. In the CVEs above, the misuse was a buffer overflow, which is a memory safety problem with the usual range of outcomes from a crash upward.

How to find it

This is one of the easier weaknesses to hunt, because you can search for the function name.

• Source review. MITRE lists manual source code review as highly cost effective, and focused spot checks of the risky calls as cost effective for partial coverage.
• Static analysis. A scanner can flag every call to a banned function across the tree in seconds.
• Binary and bytecode analysis. When you do not have the source of a library, disassembly plus weakness analysis can show which dangerous imports it uses.
• Dynamic analysis. A debugger or a monitored sandbox can show what happens at runtime when odd input reaches these calls.

How to fix it

MITRE's mitigation is simple and worth adopting as policy: identify a list of prohibited API functions, forbid developers from using them, and provide safer alternatives. It points to the banned.h header from Microsoft's SDL as one way to have the compiler or an analysis tool spot use of prohibited functions.

In practice:

1. Write the banned list down. Start with strcpy, strcat, sprintf and gets.
2. Name the replacement next to each entry, so nobody has to guess.
3. Enforce it in CI so a banned call fails the build.
4. Fix existing calls in priority order, starting with ones that take external input.

The safer version of the earlier example:

// Fixed: bounded write, always terminated
void greet(const char *name) {
    char buf[32];
    snprintf(buf, sizeof buf, "%s", name);
    printf("Hello, %s\n", buf);
}

snprintf takes the buffer size and will not write past it. Remember the same discipline applies to the dependencies you pull in. A library you ship may contain these calls too, and a free scan at gold.safeguard.sh/scan will tell you which known vulnerabilities your dependency list carries. The file stays on your machine and it covers up to 100 dependencies, no login.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE CWE-676
• Safeguard Gold page for CWE-676