You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Annony Mouse <an...@gmail.com> on 2008/06/03 22:15:20 UTC
Questions on session hijack bug in 6.0.14 (CVE-2007-5333)
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Questions on session hijack bug in 6.0.14 (CVE-2007-5333)
Posted by Mark Thomas <ma...@apache.org>.
Annony Mouse wrote:
> Thank you very much for the fast and detailed response. It is very
> reassuring to understand how the attack would actually work, and even
> better that it is more limited in scope than I had feared.
>
>
>
> On 6/3/08, Mark Thomas <ma...@apache.org> wrote:
>
>>> 7.) Communications failure can only mean one thing...
>>>
>
> Oops. Sorry. Star wars quote (accidentally mis-quoted) to lighten the
> tone failed.
> "A communications disruption can mean only one thing: invasion!"
Sorry - I thought there was something about it but couldn't see what it
was. I should have seen that one. In my defence it is late in the UK ;)
> I find the system to work very well indeed, and my thanks to all at
> Tomcat and Apache for this as well. As one post I saw mentioned: if
> Tomcat had a truly significant security flaw, this users group would
> be awash with hundreds of requests for clarification in moments.
>
> Thanks again
You're welcome.
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
Re: Questions on session hijack bug in 6.0.14 (CVE-2007-5333)
Posted by Annony Mouse <an...@gmail.com>.
Thank you very much for the fast and detailed response. It is very
reassuring to understand how the attack would actually work, and even
better that it is more limited in scope than I had feared.
On 6/3/08, Mark Thomas <ma...@apache.org> wrote:
>
> > 7.) Communications failure can only mean one thing...
> >
Oops. Sorry. Star wars quote (accidentally mis-quoted) to lighten the
tone failed.
"A communications disruption can mean only one thing: invasion!"
I find the system to work very well indeed, and my thanks to all at
Tomcat and Apache for this as well. As one post I saw mentioned: if
Tomcat had a truly significant security flaw, this users group would
be awash with hundreds of requests for clarification in moments.
Thanks again
---------------------------------------------------------------------
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
Re: Questions on session hijack bug in 6.0.14 (CVE-2007-5333)
Posted by Mark Thomas <ma...@apache.org>.
Christopher Schultz wrote:
>
> Mark,
>
> Mark Thomas wrote:
> | 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'.
>
> Maybe I'm not reading the OP's reference correctly
> (http://securitytracker.com/alerts/2007/Aug/1018557.html) but it looks
> like the URL provided (in the "exploit") doesn't demonstrate what you
> describe.
You are reading the reference correctly. The example is simple but was
enough to convince the security team that session hijacking was possible.
When it comes to a choice of trying to produce a POC for what we believe to
be the worst case scenario or working on a fix, the fix is usually all we
have time for.
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
Re: Questions on session hijack bug in 6.0.14 (CVE-2007-5333)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
Mark Thomas wrote:
| 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'.
Maybe I'm not reading the OP's reference correctly
(http://securitytracker.com/alerts/2007/Aug/1018557.html) but it looks
like the URL provided (in the "exploit") doesn't demonstrate what you
describe.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhO8x0ACgkQ9CaO5/Lv0PDMcgCeL/A1AIC/uFGlFonqsLeg9Vq2
RbUAn2qNiHgkzEpTFePBhTD0JxcpuX0y
=cpn1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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
Re: Questions on session hijack bug in 6.0.14 (CVE-2007-5333)
Posted by Mark Thomas <ma...@apache.org>.
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
Re: Questions on session hijack bug in 6.0.14 (CVE-2007-5333)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
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...?
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhO2WAACgkQ9CaO5/Lv0PCArgCguHpT41UILNrttSGhthO9CRZZ
fIIAn2euPBcBye/f0psXR0xzaY8r9r1y
=kuUr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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
Re: Questions on session hijack bug in 6.0.14 (CVE-2007-5333)
Posted by Mark Thomas <ma...@apache.org>.
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