Antonio,
the recursion solve the problem because after the first "step" you
are exposing to the remote exploit. The first evaluation step is secure.
If you have %{foo} somewhere and you evaluate it if the property foo
does not contain an expression you are safe. If it contains an
expression you are recursive-evaluating and that's the problem.
You can't have a circular-reference (like the one that caused me to
find this big problem) if you disable recursion.
Moreover I think it is always a good coding practice when using
recursion to have a max loop limit to break off the loop if something
goes wrong.
It's the way the patch is implemented (I noticed my fault after
posting the patch) that prevents expression that is not recursive
like "%{foo} %{bar}" to be evaluated. I don't think it's a problem
but we should know that this type of expressions will not be
evaluated after installing the patch.
Maybe Don has addressed this kind of expression in his patch... I'll
take a look at it later.
Il giorno 16/lug/07, alle ore 16:09, Antonio Petrelli ha scritto:
2007/7/16, Ing. Andrea Vettori <[EMAIL PROTECTED]>:
What about expression like "%{foo} %{bar}" that work with the current
version but don't work using the loopCounter patch ?
I don't think we need them but who knows...
I think that recursion is a false problem: it's up to the developer to
control it (I don't think that JSP EL controls it, correct me if I am
wrong). Eventually a log message can be written, but preventing it
is not a
solution, because a particular case (such as circular reference)
will be
always present.
The "real" problem is that a user should not be allowed to execute
such OGNL
code!
Antonio
--
Ing. Andrea Vettori
Consulente per l'Information Technology
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
