Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 3.2.16

Bug #8123 Some Fieldnames Cause Unexpected Behaviors
Submitted: 2006-07-05 16:54 UTC
From: evan at portlandwebworks dot com Assigned: avb
Status: Closed Package: HTML_QuickForm (version 3.2.6)
PHP Version: 4.3.2 OS: Redhat Linux
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 35 + 28 = ?

 
 [2006-07-05 16:54 UTC] evan at portlandwebworks dot com (Evan Priestley)
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.

Comments

 [2006-07-05 20:54 UTC] avb (Alexey Borzov)
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?
 [2006-07-05 21:06 UTC] evan at portlandwebworks dot com
No, this is not a vulnerability (except, conceivably, in particularly unusual circumstances). It is merely incorrect (if, admittedly, obscure) behavior.
 [2006-10-06 15:52 UTC] avb (Alexey Borzov)
There was a more real-life example for this in bug #8414, it should indeed be fixed.
 [2006-10-07 20:12 UTC] avb (Alexey Borzov)
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.