Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of pid@pidster.com designates
 209.85.219.45 as permitted sender)
References: 
 <CAJjyRMccbNSj9F1wZw2vEwLXyLX0rKEpZcGFzn1nB6xVuvt28Q@mail.gmail.com>
 <99C8B2929B39C24493377AC7A121E21FC48F48F2E9@USEA-EXCH8.na.uis.unisys.com>
 <50ACEC37.8040102@ice-sa.com>
From: "Pid *" <pid@pidster.com>
In-Reply-To: <50ACEC37.8040102@ice-sa.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 21 Nov 2012 18:18:48 +0000
Message-ID: <-5150434621011082943@unknownmsgid>
Subject: Re: Need help to understand CVE-2007-0450
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 21 Nov 2012, at 14:59, "Andr=C3=A9 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 wit=
h regard to such URLs.  Make sure neither is enabled.
>
> Just barging in here with my own question : is the above really to be con=
sidered 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 corr=
ect 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 "/scr=
ipts/" proxied to Tomcat.
> This would allow the call to be proxied (because it matches "/scripts", a=
nd 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 p=
roxy 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 Tom=
cat 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