CWE-241 covers a product that does not handle, or handles incorrectly, an element that is not of the expected type. MITRE's example: the code expects a digit from 0 to 9 and receives a letter from A to Z.
How it happens
A function converts text to a number, or a protocol command takes a numeric argument. The author tested with digits. Nobody tested with letters, signs, empty text or control characters.
The result depends on the language. An exception may be thrown and not caught. A conversion may silently return zero. An assertion may fire and abort the process.
MITRE lists two observed examples:
- CVE-1999-1156: an FTP server crash via a PORT command with a non numeric character.
- CVE-2004-0270: an assert error in an anti virus product when a line length was non numeric.
What an attacker gains
The record lists integrity, "varies by context" and an unexpected state. In both examples the visible effect was a crash, which an attacker can repeat.
How to find it
The record lists no detection methods.
- Send letters, symbols, negative numbers and empty values wherever a number is expected.
- Fuzz command and field parsers.
- Search for conversions that are not wrapped in validation or error handling.
How to fix it
MITRE's input validation guidance applies directly:
- Assume all input is malicious.
- Use an "accept known good" strategy: a list of acceptable inputs that strictly conform to the specification. Reject anything else, or transform it into something that does conform.
- Consider every relevant property: length, type, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields and business rules.
- Do not rely only on looking for malformed or malicious input. A denylist misses cases, though it can help spot attacks.
- Decode and canonicalize input before validating it, and make sure the application does not decode the same input twice.
Type confusion at the edges
Type problems tend to hide at the edges of a system, where text becomes data. Command arguments, form fields, headers, file contents and database values all arrive as text. Somewhere a function turns that text into a number, a date or a flag. That conversion is where an unexpected type shows up.
Both observed examples sit at that boundary. An FTP command expected digits and received something else. A virus scanning product read a line length that was not a number and tripped an assertion. In each case the author had written for the normal case.
Put validation at the boundary, once, in one place. Convert text into a typed value there, handle the failure there, and pass only typed, checked values inward. Code deeper in the program should never have to wonder whether a number is really a number.
Quick check
Why prefer an allowlist over a denylist?
A denylist will probably miss at least one bad input, especially as the environment changes. An allowlist accepts only what the specification permits.
