Description: ------------ Some field names, such as: '.(eval(file_get_contents(\"evil.php\"))).'[ cause unexpected behavior (for instance, retrieving and evaluating remote scripts). The 'eval()'-based mechanism used to test for elements in nested arrays takes insufficient precautions to ensure its data has been escaped. Instead, this mechanism should properly parse nested array definitions and use recursion to test their existence. Test script: --------------- <?php // (Submit this form, and the field name will be evaluated as PHP.) require_once( 'HTML/QuickForm.php' ); $form =& new HTML_QuickForm( 'exampleForm', 'get' ); $form->addElement( 'text' ,"'.(eval(file_get_contents(\"evil.php\"))).'[" ,'test' ); $form->addElement( 'submit', 'submit', 'Submit' ); echo $form->toHTML(); ?> Expected result: ---------------- HTML_Quickform always treats field names as either literal strings or a sequence of array indices. Actual result: -------------- Field names are sometimes treated as executable PHP code.

That's cool, but to pass such a name to QuickForm's eval() the cracker needs to already have code-execution rights on your server. And if he does, there is no need to do such stuff via QuickForm. In other words: is there actual privilege escalation here?

No, this is not a vulnerability (except, conceivably, in particularly unusual circumstances). It is merely incorrect (if, admittedly, obscure) behavior.

There was a more real-life example for this in bug #8414, it should indeed be fixed.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.