In the process of documenting potential security vulnerabilities in
our product we have found that one of our releases is using a version
of Tomcat which is susceptible to CVE-2007-5333, a session hi-jacking
attack marked as low severity. Being a released product, we cannot
update the Tomcat instance. We can release a smaller patch however, as
well as suggest configuration changes.
In reading the documentation on the potential exploit we
realized that we need to know more about what is actually exposed, and
how bad the potential exploit really is.
Attempting to implement the exploits provided at Security
Tracker (http://securitytracker.com/alerts/2007/Aug/1018557.html ) I
could not cause any malevolent behavior beyond
- Destroying the value of subsequent cookies on the request.
- Setting an arbitrary expiration and nearly arbitrary path ( forged
path must end with '\' )
I am hoping that the group can a few questions, or
otherwise point me to more specific information. All the searches on
the topic lead to security reporting sites with the same information
as the original CVE, so the whole google option went right out the
window. I have searched the mailing list archives to no avail. So. The
questions:
1.) Is the statement 'A remote user can obtain session information' a
statement of fact ( someone has used this exploit to do this very
thing), or a hypothetical worst case?
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?
3.) Could this affect authenticated sessions over HTTPS?
4.) In the event that a cracker were to obtain a list of all active
Session IDs, to what use would he be able to put them if all access to
the server were through HTTPS, and all actions ( aside from opening
the login page) required the user to be logged in? Assuming the
cracker had login rights?
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.
6.) If not (5), assuming I have a central place where I have access to
the reponse object (all requests flow through this code-point). Could
I check the response (or the request) for instances of the exploit,
and prevent it that way? Since I've not managed to force the SSIDs to
dump, I have no idea: what would I look for?
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.
My current assumptions/guesses are:
1.) Fact
2.) All session IDs / no idea.
3.) Yes. Murphy dictates this be true, of course.
4.) With a session ID the cracker owns the session which was
instantiated by some other validated user, and as such is for all
intents and purposes that user. Unless and until that sessionID is
invalidated, the cracker will BE the stolen user.
5.) Not sure.
6.) Yes, need to find out what to search on though, and repro steps for testing.
7.) Communications failure can only mean one thing...
Any help would be greatly appreciated,
- Apologies for the anonymous posting. I can be reached at annonymouse99~gmail.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
