Use of Potentially Dangerous Function

Draft Base
Structure: Simple
Description

The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.

Common Consequences 1
Scope: Other

Impact: Varies by ContextQuality DegradationUnexpected State

If the function is used incorrectly, then it could result in security problems.

Detection Methods 7
Automated Static Analysis - Binary or BytecodeHigh
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis ``` Cost effective for partial coverage: ``` Binary / Bytecode Quality Analysis Binary / Bytecode simple extractor - strings, ELF readers, etc.
Manual Static Analysis - Binary or BytecodeSOAR Partial
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Dynamic Analysis with Manual Results InterpretationHigh
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Debugger ``` Cost effective for partial coverage: ``` Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious
Manual Static Analysis - Source CodeHigh
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Manual Source Code Review (not inspections) ``` Cost effective for partial coverage: ``` Focused Manual Spotcheck - Focused manual analysis of source
Automated Static Analysis - Source CodeHigh
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer ``` Cost effective for partial coverage: ``` Warning Flags Source Code Quality Analyzer
Automated Static AnalysisSOAR Partial
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Origin Analysis
Architecture or Design ReviewHigh
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Formal Methods / Correct-By-Construction Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Potential Mitigations 1
Phase: 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. [REF-554] [REF-7]
Demonstrative Examples 1

ID : DX-6

The following code attempts to create a local copy of a buffer to perform some manipulations to the data.

Code Example:

Bad
C
c
However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter.
Observed Examples 6
CVE-2007-1470Library has multiple buffer overflows using sprintf() and strcpy()
CVE-2009-3849Buffer overflow using strcat()
CVE-2006-2114Buffer overflow using strcpy()
CVE-2006-0963Buffer overflow using strcpy()
CVE-2011-0712Vulnerable use of strcpy() changed to use safer strlcpy()
CVE-2008-5005Buffer overflow using strcpy()
References 5
Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors
Katrina Tsipenyuk, Brian Chess, and Gary McGraw
NIST Workshop on Software Security Assurance Tools Techniques and MetricsNIST
07-11-2005
ID: REF-6
Security Development Lifecycle (SDL) Banned Function Calls
Michael Howard
ID: REF-554
Writing Secure Code
Michael Howard and David LeBlanc
Microsoft Press
04-12-2002
ID: REF-7
The Art of Software Security Assessment
Mark Dowd, John McDonald, and Justin Schuh
Addison Wesley
2006
ID: REF-62
State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation
Gregory Larsen, E. Kenneth Hong Fong, David A. Wheeler, and Rama S. Moorthy
07-2014
ID: REF-1479
Likelihood of Exploit

High

Applicable Platforms
Languages:
C : UndeterminedC++ : Undetermined
Modes of Introduction
Implementation
Related Weaknesses
Taxonomy Mapping
  • 7 Pernicious Kingdoms
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • Software Fault Patterns
Notes
RelationshipThis weakness is different than Use of Inherently Dangerous Function (Use of Inherently Dangerous Function). Use of Inherently Dangerous Function covers functions with such significant security problems that they can never be guaranteed to be safe. Some functions, if used properly, do not directly pose a security risk, but can introduce a weakness if not called correctly. These are regarded as potentially dangerous. A well-known example is the strcpy() function. When provided with a destination buffer that is larger than its source, strcpy() will not overflow. However, it is so often misused that some developers prohibit strcpy() entirely.