rfc:remove_preg_replace_eval_modifier

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:remove_preg_replace_eval_modifier [2012/02/05 14:39] nikicrfc:remove_preg_replace_eval_modifier [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 3: Line 3:
   * Date: 2012-02-04   * Date: 2012-02-04
   * Author: Nikita Popov <nikic@php.net>   * Author: Nikita Popov <nikic@php.net>
-  * Status: In Draft+  * Status: Implemented
  
 ===== Summary ===== ===== Summary =====
Line 35: Line 35:
 For example the above example can be used to execute arbitrary PHP code by passing the string For example the above example can be used to execute arbitrary PHP code by passing the string
 ''<h1>{${eval($_GET[php_code])}}</h1>''. The evaluted code in this case would be ''<h1>{${eval($_GET[php_code])}}</h1>''. The evaluted code in this case would be
-''"<h1>" . strtoupper("{${eval($_GET[php_code])}}") . "</h1>"'' and as such execute any PHP code passed in the+''%%"<h1>" . strtoupper("{${eval($_GET[php_code])}}") . "</h1>"%%'' and as such execute any PHP code passed in the
 ''php_code'' GET variable. ''php_code'' GET variable.
  
 An example of a larger project which suffered from such a code injection vulnerability is RoundCube An example of a larger project which suffered from such a code injection vulnerability is RoundCube
-(see [[this changeset|http://trac.roundcube.net/changeset/2148]]).+(see [[http://trac.roundcube.net/changeset/2148|this changeset]]).
  
 === Alternative === === Alternative ===
Line 73: Line 73:
  
 The application of ''addslashes'' on all substituted backreferences not only isn't helping security, but additionally The application of ''addslashes'' on all substituted backreferences not only isn't helping security, but additionally
-also results in unexpected behavior when the input contains quotes.+also results in unexpected behavior when the input contains quotes:
  
-As always both quote types are escaped, but only one of them needs escapingone of the quote types will always be +''addslashes'' always escapes both quote types, but only one of them needs escaping (e.g. in double quoted strings 
-overescaped. E.g. if ''<h1>Hallo 'World'</h1>'' is passed into the above function the result would be +only ''%%"%%'' should be escaped and in single quoted strings only ''''' should be escaped). This will result in one of 
-''<h1>HALLO \'WORLD\'</h1>'' (note the additional backslash).+the quote types to be overescaped. E.g. if ''<h1>Hallo 'World'</h1>'' is passed into the above function the result 
 +would be ''<h1>HALLO \'WORLD\'</h1>'' (note the additional backslashes).
  
-This behavior makes ''/e'' unusable for many applications (or people just use it anyways, without knowing that it +This behavior makes ''/e'' unusable in many cases (or people just use it anyways, without knowing that it is broken).
-is broken).+
  
 ==== Use as obfuscation in exploit scripts ==== ==== Use as obfuscation in exploit scripts ====
Line 90: Line 90:
   * [[http://stackoverflow.com/questions/8813126/decoding-a-weird-and-possibly-malicious-php-code]]   * [[http://stackoverflow.com/questions/8813126/decoding-a-weird-and-possibly-malicious-php-code]]
    
-This obfuscation hides scripts from ''grep'' like searches (as ''preg_replace'' is usually considered a "good"+This obfuscation hides scripts from ''grep''-like searches (as ''preg_replace'' is usually considered a "good"
 function). Additionally - as you can see in the second link - it is possible to obfuscate the use of the ''/e'' function). Additionally - as you can see in the second link - it is possible to obfuscate the use of the ''/e''
-modifier itself, making it even harder to find it's usage.+modifier itself, making it even harder to find.
    
 Obviously the use by exploit scripts is not bad per se (most exploit scripts also use ''echo'' and we better keep Obviously the use by exploit scripts is not bad per se (most exploit scripts also use ''echo'' and we better keep
Line 102: Line 102:
 replaced by a callback there would be no loss in functionality. replaced by a callback there would be no loss in functionality.
  
-The time line for deprecation and removal is subject to discussion.+===== Vote ===== 
 + 
 +The vote ended with 23 in favor and 4 against the proposal. 
 + 
 +===== Current state ===== 
 + 
 +The ''/e'' modifier has been deprecated in trunk in http://svn.php.net/viewvc?view=revision&revision=323862. It will 
 +be removed at some later point in time.
rfc/remove_preg_replace_eval_modifier.1328452796.txt.gz · Last modified: 2017/09/22 13:28 (external edit)