Dynamic Code Evaluation: Code Injection

Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.

Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the report implements a basic calculator that allows the user to specify commands for execution.

...
user_ops = request->get_form_field( 'operation' ).
CONCATENATE: 'PROGRAM zsample.| FORM calculation. |' INTO code_string,
             calculator_code_begin user_ops calculator_code_end INTO code_string,
			 'ENDFORM.|' INTO code_string.
SPLIT code_string AT '|' INTO TABLE code_table.
GENERATE SUBROUTINE POOL code_table NAME calc_prog.
PERFORM calculation IN PROGRAM calc_prog.
...

The program behaves correctly when the operation parameter is a benign value. However, if an attacker specifies language operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the injected code accesses system resources or executes system commands. For example, if an attacker were to specify "MOVE 'shutdown -h now' to cmd. CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[]." as the value of operation, a shutdown command would be executed on the host system.

Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var userOps:String = String(params["operation"]);
        result = ExternalInterface.call("eval", userOps);
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the result variable is assigned a value of 22. However, if an attacker specifies language operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. In the case of ActionScript, the attacker may utilize this vulnerability to perform a cross-site scripting attack.

Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
    public static object CEval(string sCSCode)
    {
        CodeDomProvider icc = CodeDomProvider.CreateProvider("CSharp"); 
        CompilerParameters cparam = new CompilerParameters();
        cparam.ReferencedAssemblies.Add("system.dll");
        cparam.CompilerOptions = "/t:library";
        cparam.GenerateInMemory = true;

        StringBuilder sb_code = new StringBuilder("");
        sb_code.Append("using System;\n");
        sb_code.Append("namespace Fortify_CodeEval{ \n");
        sb_code.Append("public class FortifyCodeEval{ \n");
        sb_code.Append("public object EvalCode(){\n");
        sb_code.Append(sCSCode + "\n");
        sb_code.Append("} \n");
        sb_code.Append("} \n");
        sb_code.Append("}\n");

        CompilerResults cr = icc.CompileAssemblyFromSource(cparam, sb_code.ToString());
        if (cr.Errors.Count > 0)
        {
            logger.WriteLine("ERROR: " + cr.Errors[0].ErrorText);
            return null;
        }

        System.Reflection.Assembly a = cr.CompiledAssembly;
        object o = a.CreateInstance("Fortify_CodeEval.FortifyCodeEval");

        Type t = o.GetType();
        MethodInfo mi = t.GetMethod("EvalCode");

        object s = mi.Invoke(o, null);
        return s;
    }
...

The program behaves correctly when the sCSCode parameter is a benign value, such as "return 8 + 7 * 2", in which case the 22 is the return value of the function CEval. However, if an attacker specifies language operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. For example, .Net allows invocation of Windows APIs; if an attacker were to specify " return System.Diagnostics.Process.Start(\"shutdown\", \"/s /t 0\");" as the value of operation, a shutdown command would be executed on the host system.

Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
	userOp = form.operation.value;
	calcResult = eval(userOp);
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the calcResult variable is assigned a value of 22. However, if an attacker specifies languages operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. In the case of JavaScript, the attacker may utilize this vulnerability to perform a cross-site scripting attack.

Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: The following code uses input from a UITextField to dynamically change the background color of the content within a WKWebView:

...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView evaluateJavaScript:[NSString stringWithFormat:@"document.body.style.backgroundColor="%@";", _inputTextField.text] completionHandler:nil];
...

The program behaves correctly when the UITextField input is a benign value, such as "blue", in which case the <body> element within webView would be styled to have a blue background. However, if an attacker provides malicious input that is still valid, he or she may be able to execute arbitrary JavaScript code. For example, because JavaScript can access certain types of private information such as cookies, if an attacker were to specify "white";document.body.innerHTML=document.cookie;"" as input to the UITextField, cookie information would be visibly written to the page. Such attacks are even more dangerous when the underlying language provides access to system resources or allows the execution of system commands, as in those scenarios injected code is executed with the full privilege of the parent process.

Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
	$userOps = $_GET['operation'];
	$result = eval($userOps);
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the result variable is assigned a value of 22. However, if an attacker specifies operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even 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 " exec('shutdown -h now')" as the value of operation, a shutdown command would be executed on the host system.

Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
userOps = request.GET['operation']
result = eval(userOps)
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the result variable is assigned a value of 22. However, if an attacker specifies operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even 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 " os.system('shutdown -h now')" as the value of operation, a shutdown command would be executed on the host system.

Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.
Example: In this code injection example, the application implements a basic calculator that allows the user to specify commands for execution.

...
  user_ops = req['operation']
  result = eval(user_ops)
...

The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the result variable is assigned a value of 22. However, if an attacker specifies languages operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. With Ruby this is allowed, and as multiple commands can be run by delimiting the lines with a semi-colon (;), it would also enable being able to run many commands with a simple injection, whilst still not breaking the program.
If an attacker were to submit for the parameter operation "system(\"nc -l 4444 &\");8+7*2", then this would open port 4444 to listen for a connection on the machine, and then would still return the value of 22 to result

Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.

Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example: The following code uses input from a UITextField to dynamically change the background color of the content within a WKWebView:

...
var webView : WKWebView
var inputTextField : UITextField
...
webView.evaluateJavaScript("document.body.style.backgroundColor="\(inputTextField.text)";" completionHandler:nil)
...

The program behaves correctly when the UITextField input is a benign value, such as "blue", in which case the <body> element within webView would be styled to have a blue background. However, if an attacker provides malicious input that is still valid, he or she may be able to execute arbitrary JavaScript code. For example, because JavaScript can access certain types of private information such as cookies, if an attacker were to specify "white";document.body.innerHTML=document.cookie;"" as input to the UITextField, cookie information would be visibly written to the page. Such attacks are even more dangerous when the underlying language provides access to system resources or allows the execution of system commands, as in those scenarios injected code is executed with the full privilege of the parent process.

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)
...

The program's intended behavior holds in an example where the 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.