logo

Use of Potentially Dangerous Function

Draft Base
Structure: Simple
Description

This vulnerability occurs when code calls a function that can be dangerous if misused, but can also be used safely with proper precautions. The risk lies not in the function itself, but in how it's implemented.

Extended Description

Many programming languages and libraries include powerful, low-level functions that offer performance benefits or direct system access. Functions like `strcpy()`, `eval()`, or `system()` are common examples. While they are legitimate tools, they become security risks when developers use them without validating input, managing memory, or understanding their side effects. The core issue is assuming these functions are safe by default, rather than treating them as operations that require explicit safeguards. To mitigate this, developers should first seek safer, modern alternatives provided by the language or framework, such as bounded string copy functions or secure APIs. When a dangerous function must be used, it is critical to implement strict input validation, output encoding, and context-aware sanitization around it. Security is maintained by wrapping these functions with robust checks and limits, never trusting uncontrolled data, and conducting regular code reviews focused on these specific high-risk calls.
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 Metrics • NIST
07-11-2005
https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf
ID: REF-6
Security Development Lifecycle (SDL) Banned Function Calls
Michael Howard
https://learn.microsoft.com/en-us/previous-versions/bb288454(v=msdn.10)?redirectedfrom=MSDN(2023-04-07)
ID: REF-554
Writing Secure Code
Michael Howard and David LeBlanc
Microsoft Press
04-12-2002
https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223
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
https://www.ida.org/-/media/feature/publications/s/st/stateoftheart-resources-soar-for-software-vulnerability-detection-test-and-evaluation/p-5061.ashx(2025-09-05)
ID: REF-1479
Likelihood of Exploit

High

Applicable Platforms
Languages:
C : UndeterminedC++ : Undetermined
Modes of Introduction
Implementation
Related Weaknesses
ChildOf: Use of Prohibited Code (CWE-1177)
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.