tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Questions on session hijack bug in 6.0.14 (CVE-2007-5333)
Date Tue, 10 Jun 2008 19:43:28 GMT
Hash: SHA1


I have a few questions myself. See inline.

Mark Thomas wrote:
| Annony Mouse wrote:
|> 2.) If (1) is fact, can the exploit  expose ALL Session IDs? Is it
|> dumping all of the data in all the sessions, or 'just' the sessionID
|> map?
| 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.

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. :(

|> 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? If that's the
case, how was the attack carried out in the first place?

|> 5.) Is there anything we can do to limit the scope of this bug with
|> config settings alone? Binding the session to the IP address that it
|> was first initialized with, for instance.
| That should mitigate the issue. Be aware that some ISPs play games with
| IP addresses that mean a user's IP address might not be constant between
| requests.

Note that securityfilter will soon have a filter that performs this
exact function. We're currently testing it ourselves before it even goes
into CVS. I'd be happy to share the code with anyone who wants it.

|> 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...?

- -chris
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message