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:
/[E
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:
.
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
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 say
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
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
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 n
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
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:
works
for me, so I think a remote execution is definitely possible.
(Someth
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 PROT
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
ParametersIntercepto
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
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
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
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
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 t
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 commen
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
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
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...
Coo
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, Andr
Antonio Petrelli 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.
Sinc
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-tf402696
24 matches
Mail list logo
