CWE

Common Weakness Enumeration

A Community-Developed Dictionary of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors Common Weakness Scoring System
Common Weakness Risk Analysis Framework
Home > CWE List > CWE- Individual Dictionary Definition (2.7)  

Presentation Filter:

CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

 
Improper Neutralization 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 neutralize or incorrectly neutralizes 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.

+ Common Consequences
ScopeEffect

Technical Impact: Read files or directories; Read application data

The injected code could access restricted data / files.

Technical Impact: Bypass protection mechanism

In some cases, injectable code controls authentication; this may lead to a remote vulnerability.

Technical Impact: Gain privileges / assume identity

Injected code can access resources that the attacker is directly prevented from accessing.

Technical Impact: Execute unauthorized code or commands

Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.

Technical Impact: Hide activities

Often the actions performed by injected control code are unlogged.

+ 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:

(Attack)
 
add_key(",","); system("/bin/ls");

This would produce the following string in handleConfigAction():

(Result)
 
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
Eval injection in PHP program.
Eval injection in Perl program.
Eval injection in Perl program using an ID that should only contain hyphens and numbers.
Direct code injection into Perl eval function.
Eval injection in Perl program.
Direct code injection into Perl eval function.
Direct code injection into Perl eval function.
MFV. code injection into PHP eval statement using nested constructs that should not be nested.
MFV. code injection into PHP eval statement using nested constructs that should not be nested.
Code injection into Python eval statement from a field in a formatted file.
Eval injection in Python program.
chain: Resultant eval injection. An invalid value prevents initialization of variables, which can be modified by attacker and later injected into PHP eval statement.
Chain: Execution after redirect triggers eval injection.
+ 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 "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). A blacklist is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

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
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class94Improper Control of 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
ChildOfCategoryCategory896SFP Cluster: Tainted Input
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ 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 2007A3Malicious File Execution
OWASP Top Ten 2004A6Injection Flaws
+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 18, "Inline Evaluation", Page 1095.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Externally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01CigitalExternal
updated Time_of_Introduction
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08MITREInternal
updated Applicable_Platforms, Description, Modes_of_Introduction, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12MITREInternal
updated Description, Observed_Examples, Other_Notes, Research_Gaps
2009-05-27MITREInternal
updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Description, Name, References
2010-02-16MITREInternal
updated Potential_Mitigations
2010-06-21MITREInternal
updated Description, Name
2011-06-01MITREInternal
updated Common_Consequences
2012-05-11MITREInternal
updated Common_Consequences, Demonstrative_Examples, References, Relationships
2012-10-30MITREInternal
updated Potential_Mitigations
2013-02-21MITREInternal
updated Observed_Examples
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')
2010-06-21Improper Sanitization of Directives in Dynamically Evaluated Code ('Eval Injection')
Page Last Updated: June 23, 2014