Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <484EEF75.6050609@apache.org>
Date: Tue, 10 Jun 2008 22:17:41 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Questions on session hijack bug in 6.0.14 (CVE-2007-5333)
References: <6a2e4e5d0806031315s48e7657elcc60e6ee56a2ba91@mail.gmail.com>
 <4845D469.8090900@apache.org> <484ED960.9070508@christopherschultz.net>
In-Reply-To: <484ED960.9070508@christopherschultz.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


Christopher Schultz wrote:
> Mark Thomas wrote:
> | The worst case is that the attacker will obtain the ID for the current
> | session. With this the attacker has access to the session as the current
> | user.
> 
> Who is "the current user"? If the attacker already has the session id,
> there's no need to hit the server to ... obtain the session id, right?
> Knowledge of the id of a session pretty much gives someone the right to
> act as that user. Any (valid) user has easy access to their session id:
> it's either in the URL or in a cookie value.
This attack requires luring a user who is already logged in to a webapp 
running on a vulnerable Tomcat server to a malicious site. With a suitably 
crafted URL, the attacker is able to steal the authentication cookie for 
the user who was lured to the malicious site. It is the user that is lured 
who is the 'current user'.

> If the only way to exploit this is to have foreknowledge of a session
> id, isn't the security question moot? The session id must have been
> leaked previously, right?
> 
> Maybe I'm seriously missing the point. :(
See above.

> |> 3.) Could this affect authenticated sessions over HTTPS?
> |
> | Yes, depending on the authentication used. Eg, if you use FORM the
> | session is vulnerable, if you use CLIENT-CERT it isn't.
> 
> Why is the session protected if CLIENT-CERT is being used? Because the
> attacker presumably does not have the correct client cert?
Yes.

> If that's the
> case, how was the attack carried out in the first place?
Again, see above.

> |> 7.) If this is as big of a deal as it looks like, why is there no more
> |> information available / more questions being posted / the world seems
> |> shockingly quiet about this.
> |
> | I think your worst case assumption re Q2 has lead to an over estimate of
> | the impact of this.
> | It is made worse when an app allows user provided data to find its way
> | unfiltered into cookie content - this shouldn't happen and where it does
> | should be easy to fix.
> 
> Any client can send a bogus cookie, though, right? On the other hand,
> what good is sabotaging your own request...?
They can but that is harder (but not impossible) for an attacker to trick a 
client into doing that. When a request parameter is used in/as the cookie 
value the attack is a lot easier.

Mark


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org