Remote Code Evaluation (Execution) Vulnerability

What is the Remote Code Evaluation Vulnerability?

Remote Code Evaluation is a vulnerability that can be exploited if user input is injected into a File or a String and executed (evaluated) by the programming language's parser. Usually this behavior is not intended by the developer of the web application. A Remote Code Evaluation can lead to a full compromise of the vulnerable web application and also web server. It is important to note that almost every programming language has code evaluation functions.

Remote Code Evaluation Explanation and Example

A code evaluation can occur if you allow user input inside functions that are evaluating code in the respective programming language. This can be implemented on purpose, for example to access mathematical functions of the programming language to create a calculator,  or accidentally because user controlled input is not expected from the developer inside those functions. It is generally not advised to do so. In fact it is considered to be a bad practise to use code evaluation.

Example of Code Evaluation Exploitation

You want to have dynamically generated variable names for every user and store its registration date. This is how it could be done in PHP:

eval("\$$user = '$regdate');

Since the username is generally user controlled input an attacker can generate a name like this:

x = 'y';phpinfo();//

The resulting php code would now look like this:

$x = 'y';phpinfo();// = '2016';

As you can see the variable is now called x and has the value y. After the attacker was able to assign that value to the variable he is able to start a new command by using the semicolon (;). He can now comment out the rest of the string, so he doesn't get syntax errors. If he executes this code the output of phpinfo will appear on the page. You should keep in mind that this is not only possible in PHP but also in any other language with functions that evaluate input.

Stored Remote Code Evaluation Explanation and Example

Unlike the above example this method does not rely on any specific language function, but on the fact that specific files are parsed by the language's interpreter. An example for this would be a configuration file that is included in a web application. Ideally you should avoid using user input inside files that are executed by an interpreter as this can lead to unwanted and dangerous behavior. This kind of exploit technique is often seen in combination with an upload functionality that does not do the sufficient checks on file types and extensions.

Example of Stored Code Evaluation Exploitation

You develop a web application that has a control panel for every user. The control panel has some user specific settings such as the language variable, that is set depending on a parameter and then stored inside a configuration file. An expected input could be like this:

?language=de

The above will then be reflected as $lan = 'de'; inside the configuration file. Though an attacker could now change the language parameter to something like:

de';phpinfo()//

The above would result in the following code inside the file:

$lan = 'de';phpinfo()//';

And the above will be executed when the configuration file is included in the web application, basically allowing the attackers to execute any command they want.

Impacts of the Remote Code Evaluation Vulnerability

An attacker who is able to execute such a flaw is usually able to execute commands with the privileges of the programming language or the web server. On many languages he can issue system commands, write, delete or read files or connect to databases.

How to Prevent Remote Code Evaluation

As a rule of thumb you should avoid using user input inside evaluated code. The best option would be to not use functions such as eval at all. It is considered to be a bad practise and can more often than not be completely avoided. You should also never let a user edit the content of files that might be parsed by the respective languages. That includes not letting a user decide the name and extensions of files he or she might upload or create in the web application.

What You Should NOT Do to Prevent Remote Code Evaluation

• Sanitize user input; this is most of the time not possible due to the big amount of possible bypasses of restrictions.
• Let a user decide the extension or content of files on the web server and use safe practices for secure file uploads.
• Pass any user controlled input inside evaluation functions or callbacks.
• Try to blacklist special chars or function names. Exactly as sanitizing this is almost impossible to safely implement.

Vulnerability Classification and Severity Table