Probably there was a misunderstanding Andrea.
First of all, are we talking about:
1. the "preliminar" patch, that at least prevents remote exploit by
disallowing malicious code,
or
2. the final patch? In this case, the final patch, is "1." or a patch that,
as I stated before, removes completely OGNL evaluation of user-entered
values?
I think that the conversation should follow two different direction: one for
the immediate future (to solve the vulnerability) and one for the final
decision.
Antonio
2007/7/16, Ing. Andrea Vettori <[EMAIL PROTECTED]>:
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]
