In a language where the user can influence the name of a variable at runtime, if the variable names are not controlled, an attacker can read or write to arbitrary variables, or access arbitrary functions.
Extended Description
The resultant vulnerabilities depend on the behavior of the application, both at the crossover point and in any control/data flow that is reachable by the related variables or functions.
Alternate Terms
Dynamic evaluation
Time of Introduction
Implementation
Applicable Platforms
Languages
PHP
Perl
Common Consequences
Scope
Effect
Confidentiality
Integrity
Availability
Technical Impact: Modify application
data; Execute unauthorized code or
commands
An attacker could gain unauthorized access to internal program
variables and execute arbitrary code.
Dynamic variable evaluation in mail program allows
reading and modifying attachments and preferences of other
users.
Potential Mitigations
Phase: Implementation
Strategy: Refactoring
Refactor the code to avoid dynamic variable evaluation whenever
possible.
Phase: Implementation
Strategy: Input Validation
Use only whitelists of acceptable variable or function names.
Phase: Implementation
For function names, ensure that you are only calling functions that
accept the proper number of arguments, to avoid unexpected null
arguments.
Background Details
Many interpreted languages support the use of a "$$varname" construct to
set a variable whose name is specified by the $varname variable. In PHP,
these are referred to as "variable variables." Functions might also be
invoked using similar syntax, such as $$funcname(arg1, arg2).
Weakness Ordinalities
Ordinality
Description
Primary
(where
the weakness exists independent of other weaknesses)
Under-studied, probably under-reported. Few researchers look for this
issue; most public reports are for PHP, although other languages are
affected. This issue is likely to grow in PHP as developers begin to
implement functionality in place of register_globals.
Description
