CWE
Home > CWE List > CWE-95 Individual Dictionary Definition (Draft 9)   View the CWE List

CWE-95 Individual Dictionary Definition (Draft 9)

Insufficient Control of Directives in Dynamically Evaluated Code (aka 'Eval Injection')
Weakness ID
Status: Incomplete

95 (Weakness Base)

Description

Summary

The software allows user-controlled input to be fed directly into a function (e.g. "eval") that dynamically evaluates and executes the input as code, usually in the same interpreted language that the product uses. Direct Dynamic Code Evaluation is prevalent in handler/dispatch procedures that might want to invoke a large number of functions, or set a large number of variables.

Alternate Terms

Direct code injection

Likelihood of Exploit

Medium

Weakness Ordinality

Primary (Weakness exists independent of other weaknesses)

Causal Nature

Explicit (This is an explicit weakness resulting from behavior of the developer)

Potential Mitigations

Refactor your code so that it does not need to use eval() at all.

Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system.

Demonstrative
Examples

edit-config.pl: This CGI script is used to modify settings in a configuration file.

\
                        use CGI qw(:standard);
                        
                        sub config_file_add_key {
                            my ($fname, $key, $arg) = @_;
                        
                             # code to add a field/key to a file goes here
                        }
                        
                        sub config_file_set_key {
                            my ($fname, $key, $arg) = @_;
                        
                            # code to set key to a particular file goes here
                        }
                        
                        sub config_file_delete_key {
                            my ($fname, $key, $arg) = @_;
                        
                            # code to delete key from a particular file goes here
                        }
                        
                        sub handleConfigAction {
                            my ($fname, $action) = @_;
                            my $key = param('key');
                            my $val = param('val');
                        
                            # this is super-efficient code, especially if you have to invoke
                            # any one of dozens of different functions!
                        
                            my $code = "config_file_$action_key(\$fname, \$key, \$val);";
                            eval($code);
                        }
                        
                        $configfile = "/home/cwe/config.txt";
                        print header;
                        if (defined(param('action'))) {
                            handleConfigAction($configfile, param('action'));
                        }
                        else {
                            print "No action specified!\n";    
                        }

The script intends to take the 'action' parameter and invoke one of a variety of functions based on the value of that parameter - config_file_add_key(), config_file_set_key(), or config_file_delete_key(). It could set up a conditional to invoke each function separately, but eval() is a powerful way of doing the same thing in fewer lines of code, especially when a large number of functions or variables are involved. Unfortunately, in this case, the attacker can provide other values in the action parameter, such as: add_key(",","); system("/bin/ls"); This would produce the following string in handleConfigAction(): config_file_add_key(",","); system("/bin/ls"); Any arbitrary Perl code could be added after the attacker has "closed off" the construction of the original function call, in order to prevent parsing errors from causing the malicious eval() to fail before the attacker's payload is activated. This particular manipulation would fail after the system() call, because the "_key(\$fname, \$key, \$val)" portion of the string would cause an error, but this is irrelevant to the attack because the payload has already been activated.

Observed Examples
ReferenceDescription
CVE-2002-1750Direct code injection into Perl eval function.
CVE-2002-1751Direct code injection into Perl eval function.
CVE-2002-1752Direct code injection into Perl eval function.
CVE-2002-1753Direct code injection into Perl eval function.
CVE-2005-1527Direct code injection into Perl eval function.
CVE-2005-2837Direct code injection into Perl eval function.
CVE-2005-1921MFV. code injection into PHP eval statement using nested constructs that should not be nested.
CVE-2005-2498MFV. code injection into PHP eval statement using nested constructs that should not be nested.
CVE-2005-3302Code injection into Python eval statement from a field in a formatted file.
CVE-2001-1471Resultant eval injection. An invalid value prevents initialization of variables, which can be modified by attacker and later injected into PHP eval statement.
Context Notes

This issue is probably under-reported. Most relevant CVEs have been for Perl and PHP, but eval injection applies to most interpreted languages. Javascript eval injection is likely to be heavily under-reported.

This vulnerability is applicable to any interpreted language

Factors: special character errors can play a role in increasing the variety of code that can be injected, although some vulnerabilities do not require special characters at all, e.g. when a single function without arguments can be referenced and a terminator character is not necessary.

Relationships
NatureTypeIDName
ChildOfWeakness ClassWeakness ClassWeakness Class94Code Injection
ChildOfViewView629
Source Taxonomies

PLOVER - Direct Dynamic Code Evaluation ('Eval Injection')

Applicable Platforms

Java

Javascript

Python

Perl

PHP

Related Attack Patterns
CAPEC-IDAttack Pattern Name
35Leverage Executable Code in Nonexecutable Files
Page Last Updated: April 22, 2008