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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
