Executing arbitrary source instructions from an untrusted source can lead to malicious code execution.
Many modern languages allow dynamic interpretation of source instructions. This ability can be used when the programmer needs to perform user supplied instructions on data but would rather utilize the underlying language constructs instead of implementing code to interpret the user input. The user supplied instructions are expected to be innocent operations such as small calculations on active user objects, modification of the state of user objects, etc. However, if a programmer is not careful, a user may specify operations outside of the programmer's intentions.
Example: A classic example application that may allow underlying programming constructs to be specified by the user is a calculator. The following ASP code accepts basic mathematical operations from the user to be computed and returned:
...
strUserOp = Request.Form('operation')
strResult = Eval(strUserOp)
...
operation
parameter is "8 + 7 * 2". The strResult
variable returns with a value of 22. However, if a user were to specify other valid language operations, those operations would not only be executed but executed with the full privilege of the parent process. Arbitrary code execution becomes more dangerous when the underlying language provides access to system resources or allows execution of system commands. For example, if an attacker were to specify operation
as " Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')" a shutdown command would be executed on the host system.
[1] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A1 Injection
[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A2 Injection Flaws
[3] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A3 Malicious File Execution
[4] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A6 Injection Flaws
[5] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3570 CAT I
[6] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 95
[7] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Insecure Interaction - CWE ID 116
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.2
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.3
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.6
[12] Standards Mapping - FIPS200 - (FISMA) SI