Re: [S2] Heads Up: possible DOS problem
I understand...
I'll try to use your patch, hoping I never have legal parameter in
the form of %{something}.
Il giorno 07/lug/07, alle ore 01:11, Musachy Barroso ha scritto:
That could prevent the infinite recursion, but not the remote
exploit, I
would still be able to pass this in:
/[EMAIL PROTECTED]@exit()
as a side note, this problem is not only tied to the tags and tag
attributes
as mentioned before, sometimes I have something like this in my action
mappings:
...
resultsomeUrl.actionid=${id}/result
...
where id is usually a parameter, which could also be exploited.
musachy
On 7/6/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote:
Please take a look at the jira issue.
I've uploaded a possibile nice solution.
I desperately :) need to know if there are some possibile problem to
use this on my site until a better solution is found.
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Hey you! Would you help me to carry the stone? Pink Floyd
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
That could prevent the infinite recursion, but not the remote exploit, I
would still be able to pass this in:
/[EMAIL PROTECTED]@exit()
as a side note, this problem is not only tied to the tags and tag attributes
as mentioned before, sometimes I have something like this in my action
mappings:
...
resultsomeUrl.actionid=${id}/result
...
where id is usually a parameter, which could also be exploited.
musachy
On 7/6/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote:
Please take a look at the jira issue.
I've uploaded a possibile nice solution.
I desperately :) need to know if there are some possibile problem to
use this on my site until a better solution is found.
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Hey you! Would you help me to carry the stone? Pink Floyd
[S2] Heads Up: possible DOS problem
Hi all, Andrea Vettori, in the Struts Users mailing list, probably discovered a possible Denial-Of-Service bug in Struts 2. The cause could be XWork. See: https://issues.apache.org/struts/browse/WW-2030 And: http://www.nabble.com/-S2--App-produces-lot-garbage-IMPORTANT-NEWS-%28I-HOPE%29-tf4026966.html Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
Antonio Petrelli antonio.petrelli at gmail.com writes: Hi all, Andrea Vettori, in the Struts Users mailing list, probably discovered a possible Denial-Of-Service bug in Struts 2. The cause could be XWork. Hi, furthermore I'd like to know if there are other values that can trigger the problem. Since I don't think that normal users of my site use that kind of password, I'm looking for whatever has triggered the problem about once a day on my e-commerce site... I've tried to follow the source of various classes but it's all new to me so I'm a bit lost. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
some simple testing shows that the field value is simply evaluated...
try to put on a struts textfield %{1+1} submit and you'll get 2 on
the field...
Cool but don't think it should be the default behaviour.
What constructs can trigger recursion ?
Il giorno 05/lug/07, alle ore 14:00, Andrea ha scritto:
Antonio Petrelli antonio.petrelli at gmail.com writes:
Hi all,
Andrea Vettori, in the Struts Users mailing list, probably discovered
a possible Denial-Of-Service bug in Struts 2.
The cause could be XWork.
Hi,
furthermore I'd like to know if there are other values that can
trigger the
problem.
Since I don't think that normal users of my site use that kind of
password,
I'm looking for whatever has triggered the problem about once a day
on my
e-commerce site...
I've tried to follow the source of various classes but it's all new
to me so I'm
a bit lost.
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
Possible DoS? Isn't this a remote exploit? Can you call arbitrary methods?
Bob
On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote:
some simple testing shows that the field value is simply evaluated...
try to put on a struts textfield %{1+1} submit and you'll get 2 on
the field...
Cool but don't think it should be the default behaviour.
What constructs can trigger recursion ?
Il giorno 05/lug/07, alle ore 14:00, Andrea ha scritto:
Antonio Petrelli antonio.petrelli at gmail.com writes:
Hi all,
Andrea Vettori, in the Struts Users mailing list, probably discovered
a possible Denial-Of-Service bug in Struts 2.
The cause could be XWork.
Hi,
furthermore I'd like to know if there are other values that can
trigger the
problem.
Since I don't think that normal users of my site use that kind of
password,
I'm looking for whatever has triggered the problem about once a day
on my
e-commerce site...
I've tried to follow the source of various classes but it's all new
to me so I'm
a bit lost.
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
The DoS is because you can trigger an infinite loop.
Please take a look at the jira issue.
Looks like we need to do different things if the value is specified
in the source code or if it's inserted in the field by the user.
http://struts.apache.org/2.0.8/docs/tag-syntax.html
Il giorno 05/lug/07, alle ore 17:47, Bob Lee ha scritto:
Possible DoS? Isn't this a remote exploit? Can you call arbitrary
methods?
Bob
On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote:
some simple testing shows that the field value is simply evaluated...
try to put on a struts textfield %{1+1} submit and you'll get 2 on
the field...
Cool but don't think it should be the default behaviour.
What constructs can trigger recursion ?
Il giorno 05/lug/07, alle ore 14:00, Andrea ha scritto:
Antonio Petrelli antonio.petrelli at gmail.com writes:
Hi all,
Andrea Vettori, in the Struts Users mailing list, probably
discovered
a possible Denial-Of-Service bug in Struts 2.
The cause could be XWork.
Hi,
furthermore I'd like to know if there are other values that can
trigger the
problem.
Since I don't think that normal users of my site use that kind of
password,
I'm looking for whatever has triggered the problem about once a day
on my
e-commerce site...
I've tried to follow the source of various classes but it's all new
to me so I'm
a bit lost.
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
Implementing ParameterNameAware would solve the problem of someone tampering
the parameter name, but not entering %{} in the value. We need to prevent
both.
musachy
On 7/5/07, Musachy Barroso [EMAIL PROTECTED] wrote:
Another workaround is to implement ParameterNameAware, and return false
for parameters like %{...}. I think that ParametersInterceptor needs to
check for values like that, just like it does with the names in
acceptableNames()
musachy
On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote:
The DoS is because you can trigger an infinite loop.
Please take a look at the jira issue.
Looks like we need to do different things if the value is specified
in the source code or if it's inserted in the field by the user.
http://struts.apache.org/2.0.8/docs/tag-syntax.html
Il giorno 05/lug/07, alle ore 17:47, Bob Lee ha scritto:
Possible DoS? Isn't this a remote exploit? Can you call arbitrary
methods?
Bob
On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote:
some simple testing shows that the field value is simply evaluated...
try to put on a struts textfield %{1+1} submit and you'll get 2 on
the field...
Cool but don't think it should be the default behaviour.
What constructs can trigger recursion ?
Il giorno 05/lug/07, alle ore 14:00, Andrea ha scritto:
Antonio Petrelli antonio.petrelli at gmail.com writes:
Hi all,
Andrea Vettori, in the Struts Users mailing list, probably
discovered
a possible Denial-Of-Service bug in Struts 2.
The cause could be XWork.
Hi,
furthermore I'd like to know if there are other values that can
trigger the
problem.
Since I don't think that normal users of my site use that kind of
password,
I'm looking for whatever has triggered the problem about once a day
on my
e-commerce site...
I've tried to follow the source of various classes but it's all new
to me so I'm
a bit lost.
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Hey you! Would you help me to carry the stone? Pink Floyd
--
Hey you! Would you help me to carry the stone? Pink Floyd
Re: [S2] Heads Up: possible DOS problem
Hey Andrea, I think that you discovered the worst bug in the history of Struts (or WebWork, or both) :-) Antonio Don't know if I should be happy or not... :) As you know I have this e-commerce site that's requiring my attention more than a 6 month child... and I even don't know if this is the cause of my garbage problems! We'll see (very sooner I hope). -- Ing. Andrea Vettori Consulente per l'Information Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
Hope it can be fixed ASAP since I think that most of us users don't
use the value parameter on most of their forms.
Do you think that it can be possibile to trigger the infinite loop
using something else than %{something} ???
As you may know I'm faced with the problem of garbage but don't think
my users write OGNL code in my fields :)
Il giorno 05/lug/07, alle ore 18:46, Musachy Barroso ha scritto:
Implementing ParameterNameAware would solve the problem of someone
tampering
the parameter name, but not entering %{} in the value. We need to
prevent
both.
musachy
On 7/5/07, Musachy Barroso [EMAIL PROTECTED] wrote:
Another workaround is to implement ParameterNameAware, and return
false
for parameters like %{...}. I think that ParametersInterceptor
needs to
check for values like that, just like it does with the names in
acceptableNames()
musachy
On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote:
The DoS is because you can trigger an infinite loop.
Please take a look at the jira issue.
Looks like we need to do different things if the value is specified
in the source code or if it's inserted in the field by the user.
http://struts.apache.org/2.0.8/docs/tag-syntax.html
Il giorno 05/lug/07, alle ore 17:47, Bob Lee ha scritto:
Possible DoS? Isn't this a remote exploit? Can you call arbitrary
methods?
Bob
On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote:
some simple testing shows that the field value is simply
evaluated...
try to put on a struts textfield %{1+1} submit and you'll get
2 on
the field...
Cool but don't think it should be the default behaviour.
What constructs can trigger recursion ?
Il giorno 05/lug/07, alle ore 14:00, Andrea ha scritto:
Antonio Petrelli antonio.petrelli at gmail.com writes:
Hi all,
Andrea Vettori, in the Struts Users mailing list, probably
discovered
a possible Denial-Of-Service bug in Struts 2.
The cause could be XWork.
Hi,
furthermore I'd like to know if there are other values
that can
trigger the
problem.
Since I don't think that normal users of my site use that
kind of
password,
I'm looking for whatever has triggered the problem about
once a day
on my
e-commerce site...
I've tried to follow the source of various classes but it's
all new
to me so I'm
a bit lost.
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Hey you! Would you help me to carry the stone? Pink Floyd
--
Hey you! Would you help me to carry the stone? Pink Floyd
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
2007/7/5, Bob Lee [EMAIL PROTECTED]: On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote: The DoS is because you can trigger an infinite loop. My point is, can you execute arbitrary code on the server? If so, a DoS is the least of your worries. It seems that you can, see the comment by Lukasz Racon: https://issues.apache.org/struts/browse/WW-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41371 Hey Andrea, I think that you discovered the worst bug in the history of Struts (or WebWork, or both) :-) Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote: The DoS is because you can trigger an infinite loop. My point is, can you execute arbitrary code on the server? If so, a DoS is the least of your worries. Bob
Re: [S2] Heads Up: possible DOS problem
Another workaround is to implement ParameterNameAware, and return false for
parameters like %{...}. I think that ParametersInterceptor needs to check
for values like that, just like it does with the names in acceptableNames()
musachy
On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote:
The DoS is because you can trigger an infinite loop.
Please take a look at the jira issue.
Looks like we need to do different things if the value is specified
in the source code or if it's inserted in the field by the user.
http://struts.apache.org/2.0.8/docs/tag-syntax.html
Il giorno 05/lug/07, alle ore 17:47, Bob Lee ha scritto:
Possible DoS? Isn't this a remote exploit? Can you call arbitrary
methods?
Bob
On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote:
some simple testing shows that the field value is simply evaluated...
try to put on a struts textfield %{1+1} submit and you'll get 2 on
the field...
Cool but don't think it should be the default behaviour.
What constructs can trigger recursion ?
Il giorno 05/lug/07, alle ore 14:00, Andrea ha scritto:
Antonio Petrelli antonio.petrelli at gmail.com writes:
Hi all,
Andrea Vettori, in the Struts Users mailing list, probably
discovered
a possible Denial-Of-Service bug in Struts 2.
The cause could be XWork.
Hi,
furthermore I'd like to know if there are other values that can
trigger the
problem.
Since I don't think that normal users of my site use that kind of
password,
I'm looking for whatever has triggered the problem about once a day
on my
e-commerce site...
I've tried to follow the source of various classes but it's all new
to me so I'm
a bit lost.
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Hey you! Would you help me to carry the stone? Pink Floyd
Re: [S2] Heads Up: possible DOS problem
2007/7/5, Musachy Barroso [EMAIL PROTECTED]:
Implementing ParameterNameAware would solve the problem of someone tampering
the parameter name, but not entering %{} in the value. We need to prevent
both.
Prevent? I don't think that intercepting the possible malicious values
is a viable solution, there will be always an exploit that can bypass
it.
I think that values passed by the user must not be evaluated as an
OGNL expression, just like EL is not evaluated when entered by the
user.
Antonio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
ww:property value=[EMAIL PROTECTED]@currentTimeMillis()}/ works for me, so I think a remote execution is definitely possible. (Something like Runtime.exec would probably cause a lot of problems) Do we need to filter certain classes/methods? I'm not sure how else we would solve this--this could allow someone to do some nasty stuff. Tom On 7/5/07, Bob Lee [EMAIL PROTECTED] wrote: On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote: The DoS is because you can trigger an infinite loop. My point is, can you execute arbitrary code on the server? If so, a DoS is the least of your worries. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
The thing is that there isn't (that I see) any way to know if a value was
passed by the user. For example on this case, by the time that
TextParseUtils is evaluating the value, that value was assigned to the
action field, and the result is executing already. If you look at the
ParametersInterceptor you will see this:
protected boolean acceptableName(String name) {
if (name.indexOf('=') != -1 || name.indexOf(',') != -1 ||
name.indexOf('#') != -1
|| name.indexOf(':') != -1 || isExcluded(name)) {
return false;
} else {
return true;
}
}
we are doing something similar already, but for the name.
musachy
On 7/5/07, Antonio Petrelli [EMAIL PROTECTED] wrote:
2007/7/5, Musachy Barroso [EMAIL PROTECTED]:
Implementing ParameterNameAware would solve the problem of someone
tampering
the parameter name, but not entering %{} in the value. We need to
prevent
both.
Prevent? I don't think that intercepting the possible malicious values
is a viable solution, there will be always an exploit that can bypass
it.
I think that values passed by the user must not be evaluated as an
OGNL expression, just like EL is not evaluated when entered by the
user.
Antonio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Hey you! Would you help me to carry the stone? Pink Floyd
Re: [S2] Heads Up: possible DOS problem
2007/7/5, Musachy Barroso [EMAIL PROTECTED]: The thing is that there isn't (that I see) any way to know if a value was passed by the user. Just a thing that came up to my mind. I noticed this comment in the issue: https://issues.apache.org/struts/browse/WW-2030#action_41367 Alexis says: I noticed that it didn't happen if you add the value attribute to the tag. No need to set a value to it, its presence acts like a workaround. Does it lie the possible solution? Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
I that case we would have to scape back the strings at some point. muachy On 7/5/07, Antonio Petrelli [EMAIL PROTECTED] wrote: 2007/7/5, Musachy Barroso [EMAIL PROTECTED]: The thing is that there isn't (that I see) any way to know if a value was passed by the user. What about escaping the strings, then? Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: [S2] Heads Up: possible DOS problem
How about [EMAIL PROTECTED](/)}. Seems like that could be the worse attack. ;) Probably best to shutdown the entire thing. Don't let evaluation occur at all on incoming parameter values. -bp Tom Schneider wrote: ww:property value=[EMAIL PROTECTED]@currentTimeMillis()}/ works for me, so I think a remote execution is definitely possible. (Something like Runtime.exec would probably cause a lot of problems) Do we need to filter certain classes/methods? I'm not sure how else we would solve this--this could allow someone to do some nasty stuff. Tom On 7/5/07, Bob Lee [EMAIL PROTECTED] wrote: On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote: The DoS is because you can trigger an infinite loop. My point is, can you execute arbitrary code on the server? If so, a DoS is the least of your worries. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
2007/7/5, Musachy Barroso [EMAIL PROTECTED]: The thing is that there isn't (that I see) any way to know if a value was passed by the user. What about escaping the strings, then? Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
2007/7/5, Musachy Barroso [EMAIL PROTECTED]:
In the meanwhile I submitted a patch to the issue for those that need a
quick fix (until a real fix is made), parameters that match the regex
.*?%\{.*?\} won't be accepted. This regex is configured as a parameter to
the params Interceptor.
Cool! I think that a quick 2.0.8.1 version of Struts 2 should be prepared ASAP.
Antonio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
Escaping them won't work unless TextParseUtils is changed, for example
assume this is submitted: name=%{name}
we scape %{name} to '%{name}', when TextParseUtils sees the %{...} will
try to expand it (we would have to check for single quotes around %{}).
In the meanwhile I submitted a patch to the issue for those that need a
quick fix (until a real fix is made), parameters that match the regex
.*?%\{.*?\} won't be accepted. This regex is configured as a parameter to
the params Interceptor.
musachy
On 7/5/07, Musachy Barroso [EMAIL PROTECTED] wrote:
I that case we would have to scape back the strings at some point.
muachy
On 7/5/07, Antonio Petrelli [EMAIL PROTECTED] wrote:
2007/7/5, Musachy Barroso [EMAIL PROTECTED]:
The thing is that there isn't (that I see) any way to know if a value
was
passed by the user.
What about escaping the strings, then?
Antonio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Hey you! Would you help me to carry the stone? Pink Floyd
--
Hey you! Would you help me to carry the stone? Pink Floyd
Re: [S2] Heads Up: possible DOS problem
2007/7/5, Musachy Barroso [EMAIL PROTECTED]:
The thing is that there isn't (that I see) any way to know if a
value was
passed by the user.
Just a thing that came up to my mind. I noticed this comment in the
issue:
https://issues.apache.org/struts/browse/WW-2030#action_41367
Alexis says:
I noticed that it didn't happen if you add the value attribute to the
tag. No need to set a value to it, its presence acts like a
workaround.
Does it lie the possible solution?
I confirm that using s:textfield name=xxx value=/ if you enter %
{xxx} as the field value on the browser the infinite loop is not
triggered BUT the expression is still evaluated (i.e. %{1+1} gives 2).
To me it seems that there are TWO different problem. One related to
the infinite loop (and DoS), the other is arbitrary remote execution
with servlet container privileges.
I haven't examinated the source code carefully but I think that there
must be two different solutions
One should prevent ANY future infinite loop using a loop counter or
something else to break out of the loop at a predefined level of
expression complexity. This limit somewhat the expressions you can
use but at least we haven't a possible cause of infinite loop for any
cause in the future. Just write a log line if the limit is reached
and/or let the limit value be configurable.
The other solution should let us use the value parameter as in jsp
EL. Here we are talking of two different things. One is specifing a
value as a parameter to a tag. The value is passed to the tag class
using setter methods so in the tag WE KNOW that the value is passed
by the programmer in the jsp source code. In this case we can and we
should keep the evaluation. The other is when a value is passed to a
action by means of a HTTP parameter. In this case the evaluation
should be turned off.
I am correct ?
P.S.
Please let me know if i should continue writing the same opinions
here AND in the jira issue or it's best to use only one place (and
where) .
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
