tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Questions on session hijack bug in 6.0.14 (CVE-2007-5333)
Date Tue, 03 Jun 2008 23:31:53 GMT

Annony Mouse wrote:
> 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?
I don't recall seeing a specific example of this but it would be prudent to 
assume that this was possible.

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

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

> 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?
I don't see how an attacker can get all the session IDs. Once they have an 
ID, it depends on the authentication method (see answer to 3).

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

> 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?
This is likely to be hard to do in a 100% generic way. If you expect stuff 
in a known format you should be able to look at the cookie header(s) and 
check they appear as you expect. Not sure how reliable this is.
The other, probably more important, thing to is to check any cookie value 
you set that is based in any way on user provided input and make sure that 
input is sanitised.

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

> My current assumptions/guesses are:
> 1.) Fact
Not proven but I agree with your assessment.

> 2.) All session IDs / no idea.
Definitely one session at a time. Each user has to be individually lured to 
a malicious website.

> 3.) Yes. Murphy dictates this be true, of course.
Not quite that bad but in most cases, yes it is true.

> 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.
Yes but, Q5 may offer you a possible solution here.

> 5.) Not sure.
This would work for most users.

> 6.) Yes, need to find out what to search on though, and repro steps for testing.
It is hard to ID malicious requests but easier to ID valid/safe ones. I'd 
approach this from the other direction. Essentially white list your cookie 
formats. Anything you see that does not look exactly as you expect - ditch 
the request.

> 7.) Communications failure can only mean one thing...
I've rechecked my e-mails on this issue and I can't find anything that 
isn't already in the public domain. The reports we receive often include 
simple POCs and statements of what the security researcher believes may be 
possible. Generally, if we agree that it is an issue, we concentrate on 
fixing the root cause rather than trying to figure out a POC for what we 
believe the worst case exploit is. I appreciate that this doesn't give you 
as much info as you'd like but there are only so many hours in the day.

Once an exploit is announced, discussion of the exploit, workarounds and 
possible attack vectors are all welcomed on the users list. We do ask that 
if you find a new exploit or a variation of a public exploit that you email 
the security list to give us a chance to prepare a fix before you announce 
publicly.

> - Apologies for the anonymous posting. I can be reached at annonymouse99~gmail.
No need to apologise.

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


Mime
View raw message