CWE-242: Use of Inherently Dangerous Function
Description
The product calls a function that can never be guaranteed to work safely.
Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account. The gets() function is unsafe because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to gets() and overflow the destination buffer. Similarly, the >> operator is unsafe to use when reading into a statically-allocated character array because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to the >> operator and overflow the destination buffer.
- Abstraction
- BaseA weakness specific enough to point to detection and prevention methods.
- Likelihood of exploit
- High
- Status
- Draft
Common consequences
- Other
Varies by Context
Potential mitigations
- Build and CompilationImplementation
Identify a list of prohibited API functions and prohibit developers from using these functions, providing safer alternatives. In some cases, automatic code analysis tools or the compiler can be instructed to spot use of prohibited functions, such as the banned.h include file from Microsoft's SDL.
- Testing
Use grep or static analysis tools to spot usage of dangerous functions.
Related weaknesses
Parent weaknesses
CAPEC attack patterns that exploit it
CWE 4.20 links no CAPEC attack pattern to this weakness.