CWE-234 describes a low level version of missing input: if too few arguments are sent to a function, the function will still pop the expected number of arguments from the stack. A function that takes a variable number of arguments can also exhaust the list.
It is listed for any language and technology, but the stack behavior it describes points at C style calling conventions.
How it happens
Picture a function declared to take three arguments, called with two. The caller pushes two values. The function reads three. The third read comes from whatever was already on the stack, which is not a value the programmer chose.
Variable argument functions have the same shape. A format routine that expects arguments for each directive will keep reading if the caller supplied fewer.
In networked software the same pattern appears one level up, where a parser expects a field and the request does not contain it. MITRE's observed examples are of that kind:
- CVE-2004-0276: a server could be crashed with an HTTP request that had a sequence of percent characters and a missing Host field.
- CVE-2002-1488: a chat client crashed on a PART message with a missing channel, or a channel the user was not in.
- CVE-2002-1169: a proxy crashed on an HTTP request with missing HTTP version numbers.
- CVE-2000-0521: a web server disclosed CGI source code through an HTTP request without the version number.
What an attacker gains
MITRE lists two consequences. The first is potential arbitrary code execution with the privileges of the vulnerable program if the function parameter list is exhausted. The second is availability: a program could fail if it needs more arguments than are available. The examples above were crashes, plus one source disclosure.
How to find it
The record lists no detection methods. Practical checks:
- Send protocol messages with each required field removed.
- Turn on compiler warnings for argument count and format mismatches.
- Fuzz the parsing layer.
How to fix it
MITRE gives two mitigations.
- Build and compilation: a proper build process combats the issue.
- Implementation: forward declare all functions. This is the recommended solution. With every function declared before use, the compiler raises an error if too few arguments are sent.
For the protocol level cases, also validate that required fields exist before reading them.
A closer look at the stack behavior
The stack level case deserves a second look, because the failure is quiet. The compiler is not involved at call time, and the callee has no way to ask how many arguments were really pushed. It trusts its own declaration. That is why MITRE's recommended fix works at build time: if every function is forward declared before use, the compiler knows the expected argument count at every call site and refuses to build a call that does not match.
The protocol examples show the same trust problem one layer up. Each of the four CVEs above involves a message with something absent, such as a Host field, a channel name or a version number. The receiving code was written for the complete case and read the missing piece anyway.
A simple rule covers both layers: nothing may be read until it has been confirmed to exist. For function calls, let the compiler confirm it. For messages, let the parser confirm it, and reject the message when it fails.
Quick check
What does MITRE recommend as the main fix?
Forward declare all functions, so the compiler reports a call with too few arguments.
What is the worst case consequence?
Arbitrary code execution with the privileges of the vulnerable program if the parameter list is exhausted.
