Improper Sanitization of Directives in Dynamically Evaluated Code ('Eval Injection')
Weakness ID: 95 (Weakness Base)Status: Incomplete
+ Description

Description Summary

The software receives input from an upstream component, but it does not sanitize or incorrectly sanitizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").

Extended Description

This may allow an attacker to execute arbitrary code, or at least modify what code can be executed.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

Java

Javascript

Python

Perl

PHP

Ruby

Interpreted Languages

+ Modes of Introduction

This weakness is prevalent in handler/dispatch procedures that might want to invoke a large number of functions, or set a large number of variables.

+ Likelihood of Exploit

Medium

+ Demonstrative Examples

Example 1

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

(Bad Code)
Example Language: Perl 
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-2008-5071Eval injection in PHP program.
CVE-2002-1750Eval injection in Perl program.
CVE-2008-5305Eval injection in Perl program using an ID that should only contain hyphens and numbers.
CVE-2002-1752Direct code injection into Perl eval function.
CVE-2002-1753Eval injection in Perl program.
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-2007-1253Eval injection in Python program.
CVE-2001-1471chain: Resultant eval injection. An invalid value prevents initialization of variables, which can be modified by attacker and later injected into PHP eval statement.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

If possible, refactor your code so that it does not need to use eval() at all.

Phase: Implementation

Strategy: Input Validation

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.

Phase: Architecture and Design

Do not rely exclusively on blacklist validation to detect malicious input or to encode output (CWE-184). There are too many ways to encode the same character, so you're likely to miss some variants.

Phase: Implementation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.

Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.

+ Other Notes

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.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class94Failure to Control Generation of Code ('Code Injection')
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory714OWASP Top Ten 2007 Category A3 - Malicious File Execution
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory727OWASP Top Ten 2004 Category A6 - Injection Flaws
Weaknesses in OWASP Top Ten (2004) (primary)711
+ Research Gaps

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.

+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDirect Dynamic Code Evaluation ('Eval Injection')
OWASP Top Ten 2007A3CWE More SpecificMalicious File Execution
OWASP Top Ten 2004A6CWE More SpecificInjection Flaws
+ Related Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.4)
35Leverage Executable Code in Nonexecutable Files
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time of Introduction
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Applicable Platforms, Description, Modes of Introduction, Relationships, Other Notes, Taxonomy Mappings, Weakness Ordinalities
2009-01-12CWE Content TeamMITREInternal
updated Description, Observed Examples, Other Notes, Research Gaps
2009-05-27CWE Content TeamMITREInternal
updated Alternate Terms, Applicable Platforms, Demonstrative Examples, Description, Name, References
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Direct Dynamic Code Evaluation ('Eval Injection')
2009-05-27Insufficient Control of Directives in Dynamically Evaluated Code (aka 'Eval Injection')
Back to top