COMMON WEAKNESS ENUMERATIONDraft

CWE-242

Use of Inherently Dangerous Function

The product calls a function that can never be guaranteed to work safely.

Abstraction

Base

Structure

Simple

Likelihood of Exploit

High

Understand the problem

What is the problem?

The product calls a function that can never be guaranteed to work safely.

Extended description

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.

Root cause

How and when does the problem arise?

Lifecycle phase

Implementation

Risk

What does successful exploitation lead to?

Varies by Context

Affected security scopes: Other

Defence

How is it prevented and fixed?

Build and Compilation · Implementation

Defence to apply across several lifecycle phases

Detail
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. [REF-554] [REF-1009] [REF-7]

Testing

Testing and verification approach

Detail
Use grep or static analysis tools to spot usage of dangerous functions.

Verification

How is it detected?

Automated Static Analysis

High
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)