Kingdom: Input Validation and Representation

Input validation and representation problems ares caused by metacharacters, alternate encodings and numeric representations. Security problems result from trusting input. The issues include: "Buffer Overflows," "Cross-Site Scripting" attacks, "SQL Injection," and many others.

191 items found
Weaknesses
Abstract
The program uses an improperly bounded format string that includes a %f or %F floating point specifier. Unexpectedly large floating point values will lead the program to write data outside the bounds of allocated memory, which can corrupt data, crash the program, or lead to the execution of malicious code.
Explanation
Buffer overflow is probably the best known form of software security vulnerability. Most software developers know what a buffer overflow vulnerability is, but buffer overflow attacks against both legacy and newly-developed applications are still quite common. Part of the problem is due to the wide variety of ways buffer overflows can occur, and part is due to the error-prone techniques often used to prevent them.

In a classic buffer overflow exploit, the attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function's return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker's data.

Although this type of stack buffer overflow is still common on some platforms and in some development communities, there are a variety of other types of buffer overflow, including heap buffer overflows and off-by-one errors among others. There are a number of excellent books that provide detailed information on how buffer overflow attacks work, including Building Secure Software [1], Writing Secure Code [2], and The Shellcoder's Handbook [3].

At the code level, buffer overflow vulnerabilities usually involve the violation of a programmer's assumptions. Many memory manipulation functions in C and C++ do not perform bounds checking and can easily exceed the allocated bounds of the buffers they operate upon. Even bounded functions, such as strncpy(), can cause vulnerabilities when used incorrectly. The combination of memory manipulation and mistaken assumptions about the size or makeup of a piece of data is the root cause of most buffer overflows.

In this case, an improperly constructed format string causes the program to write beyond the bounds of allocated memory.

Example: The following code overflows buf because, depending on the size of f, the format string specifier "%d %.1f ... " can exceed the amount of allocated memory.


void formatString(int x, float f) {
char buf[40];
sprintf(buf, "%d %.1f ... ", x, f);
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 787
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [12] CWE ID 787
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [2] CWE ID 787
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [1] CWE ID 787
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [1] CWE ID 787
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [1] CWE ID 787
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[20] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[23] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[27] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[40] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[41] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 134
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.internal.cpp.buffer_overflow_format_string_%f_%F
Abstract
The program writes just past the bounds of allocated memory, which could corrupt data, crash the program, or lead to the execution of malicious code.
Explanation
Buffer overflow is probably the best known form of software security vulnerability. Most software developers know what a buffer overflow vulnerability is, but buffer overflow attacks against both legacy and newly-developed applications are still quite common. Part of the problem is due to the wide variety of ways buffer overflows can occur, and part is due to the error-prone techniques often used to prevent them.

In a classic buffer overflow exploit, the attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function's return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker's data.

Although this type of off-by-one error is still common on some platforms and in some development communities, there are a variety of other types of buffer overflow, including stack and heap buffer overflows among others. There are a number of excellent books that provide detailed information on how buffer overflow attacks work, including Building Secure Software [1], Writing Secure Code [2], and The Shellcoder's Handbook [3].

At the code level, buffer overflow vulnerabilities usually involve the violation of a programmer's assumptions. Many memory manipulation functions in C and C++ do not perform bounds checking and can easily exceed the allocated bounds of the buffers they operate upon. Even bounded functions, such as strncpy(), can cause vulnerabilities when used incorrectly. The combination of memory manipulation and mistaken assumptions about the size or makeup of a piece of data is the root cause of most buffer overflows.

Example: The following code contains an off-by-one buffer overflow, which occurs when recv returns the maximum allowed sizeof(buf) bytes read. In this case, the subsequent dereference of buf[nbytes] will write the null byte outside the bounds of allocated memory.


void receive(int socket) {
char buf[MAX];
int nbytes = recv(socket, buf, sizeof(buf), 0);
buf[nbytes] = '\0';
...
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 129, CWE ID 131, CWE ID 193, CWE ID 787, CWE ID 805
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [3] CWE ID 020, [12] CWE ID 787
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [3] CWE ID 020, [2] CWE ID 787
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [1] CWE ID 787, [4] CWE ID 020, [17] CWE ID 119
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [1] CWE ID 787, [4] CWE ID 020, [19] CWE ID 119
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [1] CWE ID 787, [6] CWE ID 020, [17] CWE ID 119
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[20] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1, Rule 18-0-5
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[23] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[27] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[28] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[41] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[42] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 805, Risky Resource Management - CWE ID 129, Risky Resource Management - CWE ID 131
[43] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 131
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3590.1 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3590.1 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3590.1 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[66] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.internal.cpp.buffer_overflow_off_by_one
Abstract
The program uses a signed comparison to check a value that is later treated as unsigned. This could lead the program to write outside the bounds of allocated memory, which could corrupt data, crash the program, or lead to the execution of malicious code.
Explanation
Buffer overflow is probably the best known form of software security vulnerability. Most software developers know what a buffer overflow vulnerability is, but buffer overflow attacks against both legacy and newly-developed applications are still quite common. Part of the problem is due to the wide variety of ways buffer overflows can occur, and part is due to the error-prone techniques often used to prevent them.

In a classic buffer overflow exploit, the attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function's return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker's data.

Although this type of stack buffer overflow is still common on some platforms and in some development communities, there are a variety of other types of buffer overflow, including heap buffer overflows and off-by-one errors among others. There are a number of excellent books that provide detailed information on how buffer overflow attacks work, including Building Secure Software [1], Writing Secure Code [2], and The Shellcoder's Handbook [3].

At the code level, buffer overflow vulnerabilities usually involve the violation of a programmer's assumptions. Many memory manipulation functions in C and C++ do not perform bounds checking and can easily exceed the allocated bounds of the buffers they operate upon. Even bounded functions, such as strncpy(), can cause vulnerabilities when used incorrectly. The combination of memory manipulation and mistaken assumptions about the size or makeup of a piece of data is the root cause of most buffer overflows.

Example: The following code attempts to prevent an off-by-one buffer overflow by checking that the untrusted value read from getInputLength() is less than the size of the destination buffer output. However, because the comparison between len and MAX is signed, if len is negative, it will be become a very large positive number when it is converted to an unsigned argument to memcpy().


void TypeConvert() {
char input[MAX];
char output[MAX];

fillBuffer(input);
int len = getInputLength();

if (len <= MAX) {
memcpy(output, input, len);
}
...
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 195, CWE ID 805
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [17] CWE ID 119
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [19] CWE ID 119
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [17] CWE ID 119
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[20] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[23] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[27] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[40] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 805
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3550 CAT I, APP3590.1 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3550 CAT I, APP3590.1 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3550 CAT I, APP3590.1 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3550 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3550 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3550 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3550 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.internal.cpp.buffer_overflow_signed_comparison
Abstract
The target application uses a version of Apache Struts known to contain a remote command injection vulnerability (CVE-2014-0112 and CVE-2014-0114).
Explanation
The target application uses Apache Struts [1] version 1.x (pre-1.3.10) or 2.x (pre-2.3.16), which contains a remote command injection vulnerability identified as CVE-2014-0112 and CVE-2014-0114. [2, 3, 4, 5] The vulnerability results from insufficient validation performed by the ParametersInterceptor, allowing access to the getClass() method through the class parameter. This could allow an attacker to manipulate the ClassLoader and execute arbitrary Java code using crafted action parameters.
References
[1] Apache Struts Apache Software Foundation
[2] CVE-2014-0112 Mitre
[3] CVE-2014-0114 Mitre
[4] S2-020 Apache Software Foundation
[5] S2-021 Apache Software Foundation
[6] Muñoz, A. Struts2 zero day in the wild HPE Security Fortify Software Security Research
[7] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[8] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[9] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[10] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[11] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[12] Standards Mapping - Common Weakness Enumeration CWE ID 470
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[20] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[21] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[22] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dynamic.xtended_preview.classloader_manipulation_struts
Abstract
User-controlled data is used as a template engine's template, which allows attackers to access the template context and in some cases inject and run malicious code in the browser.
Explanation
Template engines are used to render content using dynamic data. This context data is normally controlled by the user and formatted by the template to generate web pages, emails, and so on. Template engines allow powerful language expressions to be used in templates to render dynamic content, by processing the context data with code constructs such as conditionals, loops, etc. If an attacker can control the template to be rendered, they can inject expressions that expose context data and run malicious code in the browser.

Example 1: The following example shows how a template is retrieved from the URL and used to render information with AngularJS.

function MyController(function($stateParams, $interpolate){
var ctx = { foo : 'bar' };
var interpolated = $interpolate($stateParams.expression);
this.rendered = interpolated(ctx);
...
}


In this case, $stateParams.expression will be taking potentially user-controlled data, and evaluating this as a template to be used with a specified context. This in turn may enable a malicious user to run any code they wish within the browser, retrieving information about the context it's run against, finding additional information about how the application is created, or turning this into a full blown XSS attack.
References
[1] AngularJS Security Guide Google
desc.dataflow.javascript.client_side_template_injection
Abstract
Allowing unvalidated user input to specify the path of a file included in the page can allow attackers to inject malicious code or view sensitive files on the server.
Explanation
Unauthorized include vulnerabilities occur when:

1. Data enters a web application through an untrusted source, most frequently a web request.

2. The data is part of the string specifying the template attribute of a <cfinclude> tag.
Example: The following code uses input from a web form to construct the path to a special file used to format the user's homepage. The programmer has not considered the possibility that an attacker may provide a malicious filename, such as "../../users/wileyh/malicious", which will cause the application to include and execute the contents of a file in the attacker's home directory.


<cfinclude template =
"C:\\custom\\templates\\#Form.username#.cfm">


If an attacker is allowed to specify the file included by the <cfinclude> tag, they may be able to cause the application to include the contents of nearly any file in the server's file system in the current page. This ability can be leveraged in at least two significant ways. If an attacker can write to a location on the server's file system, such as the user's home directory or a common upload directory, then they may be able to cause the application to include a maliciously crafted file in the page, which will be executed by the server. Even without write access to the server's file system, an attacker may often gain access to sensitive or private information by specifying the path of a file on the server.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 94
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[14] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-003300 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cfml.unauthorized_include
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the registry key APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
CALL FUNCTION 'REGISTRY_GET'
EXPORTING
KEY = 'APPHOME'
IMPORTING
VALUE = home.

CONCATENATE home INITCMD INTO cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the registry entry APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the registry, if an attacker can control the value of the registry key APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
btype = request->get_form_field( 'backuptype' )
CONCATENATE `/K 'c:\\util\\rmanDB.bat ` btype `&&c:\\util\\cleanup.bat'` INTO cmd.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE_LONG'
EXPORTING
commandname = cmd_exe
long_params = cmd_string
EXCEPTIONS
no_permission = 1
command_not_found = 2
parameters_too_long = 3
security_risk = 4
OTHERS = 5.
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the function module SXPG_COMMAND_EXECUTE_LONG will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to CALL 'SYSTEM'. After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to CALL 'SYSTEM'. If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
References
[1] SAP OSS notes 677435, 686765, 866732, 854060, 1336776, 1520462, 1530983 and related notes.
desc.dataflow.abap.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code uses input from configuration file to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
var fs:FileStream = new FileStream();
fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
home = String(fs.readObject(home));
var cmd:String = home + INITCMD;
fscommand("exec", cmd);
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the contents of the configuration file configStream to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the file, if an attacker can control that value, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var btype:String = String(params["backuptype"]);
var cmd:String = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\"";
fscommand("exec", cmd);
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the fscommand() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to fscommnd(). After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
fscommand("exec", "make");
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to fscommand(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.actionscript.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
+ btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...


The problem here is that the program does not do any validation on BackupTypeField. Typically the Process.Start() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Process.Start(). After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that gives users access to an interface through which they can update their password on the system. Part of the process for updating passwords in this network environment is to run an update.exe command, as follows:


...
Process.Start("update.exe");
...


The problem here is that the program does not specify an absolute path and fails to clean its environment prior to executing the call to Process.start(). If an attacker can modify the $PATH variable to point to a malicious binary called update.exe and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's update.exe will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.dotnet.command_injection
Abstract
Executing commands that include unvalidated user input can cause an application to act on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, in which an attacker explicitly controls the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.


2. The data is part of a string that is executed as a command by the application.


3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following simple program accepts a filename as a command line argument and displays the contents of the file back to the user. The program is installed setuid root because it is intended for use as a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system.


int main(char* argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}


Because the program runs with root privileges, the call to system() also executes with root privileges. If a user specifies a standard filename, the call works as expected. However, if an attacker passes a string of the form ";rm -rf /", then the call to system() fails to execute cat due to a lack of arguments and then plows on to recursively delete the contents of the root partition.

Example 2: The following code from a privileged program uses the environment variable $APPHOME to determine the application's installation directory and then executes an initialization script in that directory.


...
char* home=getenv("APPHOME");
char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
if (cmd) {
strcpy(cmd,home);
strcat(cmd,INITCMD);
execl(cmd, NULL);
}
...


As in Example 1, the code in this example allows an attacker to execute arbitrary commands with the elevated privilege of the application. In this example, the attacker may modify the environment variable $APPHOME to specify a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, by controlling the environment variable the attacker may fool the application into running malicious code.

The attacker is using the environment variable to control the command that the program invokes, so the effect of the environment is explicit in this example. We will now turn our attention to what can happen when the attacker may change the way the command is interpreted.

Example 3: The following code is from a web-based CGI utility that allows users to change their passwords. The password update process under NIS includes running make in the /var/yp directory. Note that since the program updates password records, it has been installed setuid root.

The program invokes make as follows:


system("cd /var/yp && make &> /dev/null");


Unlike the previous examples, the command in this example is hardcoded, so an attacker cannot control the argument passed to system(). However, since the program does not specify an absolute path for make and does not scrub any environment variables prior to invoking the command, the attacker may modify their $PATH variable to point to a malicious binary named make and execute the CGI script from a shell prompt. And since the program has been installed setuid root, the attacker's version of make now runs with root privileges.

On Windows, additional risks are present.

Example 4: When invoking CreateProcess() either directly or via a call to one of the functions in the _spawn() family, care must be taken when there is a space in an executable or path.


...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...


Because of the way CreateProcess() parses spaces, the first executable the operating system will try to execute is Program.exe, not MyApplication.exe. Therefore, if an attacker is able to install a malicious application called Program.exe on the system, any program that incorrectly calls CreateProcess() using the Program Files directory will run this application instead of the intended one.

The environment plays a powerful role in the execution of system commands within programs. Functions like system(), exec(), and CreateProcess() use the environment of the program that calls them, and therefore attackers have a potential opportunity to influence the behavior of these calls.
desc.dataflow.cpp.command_injection
Abstract
Executing commands without specifying an absolute path can enable an attacker to use the program to execute a malicious binary by changing $PATH or other aspects of the program's execution environment.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls the command.

- An attacker can control parameters to the program.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the second scenario, in which an attacker can change the meaning of the command by changing an environment variable or by inserting a malicious executable early on the search path. Command injection vulnerabilities of this type occur when:

1. An attacker modifies an application's environment.

2. The application executes a command without specifying an absolute path or verifying the binary being executed.



3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: This example demonstrates what can happen when the attacker can change how a command is interpreted. The code is from a web-based CGI utility that allows users to change their passwords. The password update process under NIS includes running make in the /var/yp directory. Note that because the program updates password records, it has been installed setuid root.

The program invokes make as follows:


MOVE "cd /var/yp && make &> /dev/null" to command-line
CALL "CBL_EXEC_RUN_UNIT" USING command-line
length of command-line
run-unit-id
stack-size
flags


The command in this example is hardcoded, so an attacker cannot control the argument passed to CBL_EXEC_RUN_UNIT. However, because the program does not specify an absolute path for make and does not scrub its environment variables prior to invoking the command, the attacker can modify their $PATH variable to point to a malicious binary named make and execute the CGI script from a shell prompt. In addition, because the program has been installed setuid root, the attacker's version of make now runs with root privileges.

Example 2: The following code uses an environment variable to determine the temporary directory that contains the file to print with the pdfprint command.


DISPLAY "TEMP" UPON ENVIRONMENT-NAME
ACCEPT ws-temp-dir FROM ENVIRONMENT-VARIABLE
STRING "pdfprint " DELIMITED SIZE
ws-temp-dir DELIMITED SPACE
"/" DELIMITED SIZE
ws-pdf-filename DELIMITED SPACE
x"00" DELIMITED SIZE
INTO cmd-buffer
CALL "SYSTEM" USING cmd-buffer


Similar to the previous example, the command is hardcoded. However, because the program does not specify an absolute path for pdfprint, the attacker can modify their $PATH variable to point to a malicious binary. Furthermore, while the DELIMITED SPACE phrases prevent embedded spaces in ws-temp-dir and ws-pdf-filename, there could be shell metacharacters (such as &&) embedded in either.
desc.semantic.cobol.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code allows an attacker to specify arbitrary commands via the cmd request parameter.


...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
arguments = "/c #var#"
timeout = "1"
variable="mycmd">
</cfexecute>
...
desc.dataflow.cfml.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker can control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
final cmd = String.fromEnvironment('APPHOME');
await Process.run(cmd);
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.
desc.dataflow.dart.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls the command.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker can control the executed command. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.


2. The data is used as or as part of a string that represents a command the application executes.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example: The following code runs a user-controller command.


cmdName := request.FormValue("Command")
c := exec.Command(cmdName)
c.Run()
desc.dataflow.golang.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
String home = System.getProperty("APPHOME");
String cmd = home + INITCMD;
java.lang.Runtime.getRuntime().exec(cmd);
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\util\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the Runtime.exec() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Runtime.exec(). After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
System.Runtime.getRuntime().exec("make");
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to Runtime.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.

Some think that in the mobile world, classic vulnerabilities, such as command injection, do not make sense -- why would a user attack him or herself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.

Example 4: The following code reads commands to be executed from an Android intent.


...
String[] cmds = this.getIntent().getStringArrayExtra("commands");
Process p = Runtime.getRuntime().exec("su");
DataOutputStream os = new DataOutputStream(p.getOutputStream());
for (String cmd : cmds) {
os.writeBytes(cmd+"\n");
}
os.writeBytes("exit\n");
os.flush();
...


On a rooted device, a malicious application can force a victim application to execute arbitrary commands with super user privileges.
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.java.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.


2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the environment variable APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


var cp = require('child_process');
...
var home = process.env('APPHOME');
var cmd = home + INITCMD;
child = cp.exec(cmd, function(error, stdout, stderr){
...
});
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Since the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
var btype = url.parse(request.url, true)['query']['backuptype'];
if (btype !== undefined){
cmd = "c:\\util\\rmanDB.bat" + btype;
cp.exec(cmd, function(error, stdout, stderr){
...
});
}
...
}
...
http.createServer(listener).listen(8080);


The problem here is that the program does not do any validation on the backuptype parameter read from the user apart from verifying its existence. After the shell is invoked, it may allow for the execution of multiple commands, and due to the nature of the application, it will run with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
require('child_process').exec("make", function(error, stdout, stderr){
...
});
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to child_process.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.javascript.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
$home = $_ENV['APPHOME'];
$cmd = $home . $INITCMD;
system(cmd);
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the Runtime.exec() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Runtime.exec(). After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
$result = shell_exec("make");
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to Runtime.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.php.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example: The following code defines a T-SQL stored procedure that, when called with untrusted data, will execute a system command controlled by an attacker.


...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS

DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path

exec xp_cmdshell @cmd

GO
...
References
[1] xp_cmdshell
desc.dataflow.sql.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
home = os.getenv('APPHOME')
cmd = home.join(INITCMD)
os.system(cmd);
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
btype = req.field('backuptype')
cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
os.system(cmd);
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the Runtime.exec() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Runtime.exec(). After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
result = os.system("make");
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to os.system(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.python.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.


2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. After the shell is invoked via Kernel.spawn, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
system("make")
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to Kernel.system(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.ruby.command_injection
Abstract
Executing commands that include unvalidated user input can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the second scenario, the possibility that an attacker may be able to change the meaning of the command by changing an environment variable or by putting a malicious executable early in the search path. Command injection vulnerabilities of this type occur when:

1. An attacker modifies an application's environment.

2. The application executes a command without specifying an absolute path or verifying the binary being executed.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example: The following code is from a web application that provides an interface through which users can update their password on the system.


def changePassword(username: String, password: String) = Action { request =>
...
s'echo "${password}" | passwd ${username} --stdin'.!
...
}
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.scala.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
Dim cmd
Dim home

home = Environ$("AppHome")
cmd = home & initCmd
Shell cmd, vbNormalFocus
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
$result = shell_exec("make");
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to Runtime.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.vb.command_injection