[xdebug-general] Re: Xdebug Eval is dangerous

From: Darien Hager <darien[@]etelos.com>
Date: Mon, 17 Dec 2007 10:15:24 -0800

Dave Kelsey wrote:
> The IDE doesn't want to have to parse an expression for syntax
> (although if pushed PDT could do that I suppose) and certainly not try
> to determine if an expression contains valid functions or not.
Just thinking out loud here... I may be wrong about some of how PDT and
Xdebug communicate, but...

Suppose that the PDT has some PHP code embedded in it, which defines the
body of a re-usable PHP function that uses the tokenizer extension.
Let's call it "checkEval_12345()" for the moment. This function's name
would be chosen by PDT at the start of a debugging script run in order
to avoid name collisions, and the function body code itself (of known,
tested quality) would be safely eval()'ed into existence.

So now, whenever a conditional breakpoint comes by, PDT can take that
text and submit it as an argument to checkEval_12345(), another eval()
call which we can say is safe with some certainty.

checkEval could use the tokenizer extension to ensure that the passed-in
code is:
A) A single statement
B) Contains no assignment operators
C) Does not have PHP start/end tags, HEREDOC tags, unset, return, exit,
die, print, etc.
D) All referenced variables are defined
E) All variables with method/property accessing are objects and the
property/method exists on ReflectionObject
F) All functions called pass function_exists()
G) Optionally calls only whitelisted functions

On error, safeEval returns a descriptive error string to PDT. With no
error, PDT/xdebug/whomever can assume it is moderately safe to execute
the final evaluation of the user-supplied code.

If this seems like it would be a useful approach, I have some code from
another project which should serve as a starting point and proof-of-concept.
> The best place for this is the PHP interpreter because it can evaluate
> based at the execution point, but because of the PHP.net
> implementation, any attempt to eval something that isn't valid causes
> php to terminate the script.
Philosophical quibble here---while it's bad to terminate the script,
even if that were catchable and preventable, the debugger would be
equally able to cause havok on the application level even if the
interpreter was safe. unset()'ing important variables, calling a
protected method out of order, etc.

Darien Hager
Etelos, Inc.
"Revolutionizing the way applications are developed, distributed and consumed."
[Burdensome Boilerplate]
This e-mail message, including attachments, may contain confidential information for the sole use of the intended recipient(s). If you are not the intended recipient, then this is notice that any use, disclosure, dissemination, distribution or copying is strictly prohibited. If you have received this message in error please contact the sender by reply mail and destroy all copies of the original message. 
Received on Mon Dec 17 2007 - 19:44:03 GMT

This archive was generated by hypermail 2.2.0 : Mon Jun 25 2018 - 06:00:04 BST