Use of Inherently Dangerous Function
Weakness ID: 242 (Weakness Base)Status: Draft
+ Description

Description Summary

The program 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.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

+ Likelihood of Exploit

High

+ Demonstrative Examples

Example 1

The excerpt below calls the gets() function in C, which is inherently unsafe.

(Bad Code)
Example Language: C 
char buf[BUFSIZE];
gets(buf);

Example 2

The excerpt below calls the gets() function in C, which is inherently unsafe.

(Bad Code)
Example Language: C 
char buf[24];
printf("Please enter your name and press <Enter>\n");
gets(buf);
...
}

However, the programmer uses the function gets() which is inherently unsafe because it blindly copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition.

+ Potential Mitigations

Ban the use of dangerous function. Use their safe equivalent.

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

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
CanFollowWeakness BaseWeakness Base120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Research Concepts1000
ChildOfWeakness ClassWeakness Class227Failure to Fulfill API Contract ('API Abuse')
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness ClassWeakness Class710Coding Standards Violation
Research Concepts (primary)1000
ChildOfCategoryCategory748CERT C Secure Coding Section 50 - POSIX (POS)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
CanPrecedeWeakness BaseWeakness Base120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Research Concepts1000
+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsDangerous Functions
CERT C Secure CodingPOS33-CDo not use vfork()
+ References
Herbert Schildt. "Herb Schildt's C++ Programming Cookbook". Chapter 5. Working with I/O. McGraw-Hill Osborne Media. 2008-04-28.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 5, "gets and fgets" Page 163. 2nd Edition. Microsoft. 2002.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigitalExternal
added/updated demonstrative examples
2008-07-01Eric DalciCigitalExternal
updated Potential Mitigations
2008-09-08CWE Content TeamMITREInternal
updated Applicable Platforms, Relationships, Other Notes, Taxonomy Mappings, Type, Weakness Ordinalities
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy Mappings
2009-10-29CWE Content TeamMITREInternal
updated Description, Other Notes, References
Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Dangerous Functions
2008-04-11Use of Inherently Dangerous Functions
Back to top