Is session id guaranteed to be unique?

[Glenn O]

I'm tracking down a problem which only occurs rarely, but has the
symptom that when I attach
data to one session, it appears to mistakenly become attached to another
session. It is almost as if
tomcat is generating two sessions which have the same session id.

I'm looking at the tomcat source for createSession() in
ManagerBase.java, and I notice this code is
commented out:

}
/*
synchronized (sessions) {
while (sessions.get(sessionId) != null) // Guarantee
uniqueness
sessionId = generateSessionId();
}
*/
session.setId(sessionId);


Does that mean tomcat could occasionally produce duplicate session id's?

[Turner, John]

I guess that depends on your definition of "guaranteed". I happened to be
researching this very question earlier today, and I ended up at this URL:

http://w6.metronet.com/~wjm/tomcat/2001/Sep/msg00544.html

According to that (though it is over a year old), Tomcat 4 uses
java.security.SecureRandom to generate session ids. The seeding algorithm
is a combination of things, so I guess its possible that there be identical
session ids, but my guess is it would be unbelievably rare.

John

-----Original Message-----
From: Glenn O
To: Tomcat Users List
Sent: 12/28/02 10:48 PM
Subject: Is session id guaranteed to be unique?


I'm tracking down a problem which only occurs rarely, but has the
symptom that when I attach
data to one session, it appears to mistakenly become attached to another

session. It is almost as if
tomcat is generating two sessions which have the same session id.

I'm looking at the tomcat source for createSession() in
ManagerBase.java, and I notice this code is
commented out:

}
/*
synchronized (sessions) {
while (sessions.get(sessionId) != null) // Guarantee
uniqueness
sessionId = generateSessionId();
}
*/
session.setId(sessionId);


Does that mean tomcat could occasionally produce duplicate session id's?






--
To unsubscribe, e-mail:
<mailto:tomcat-user-***@jakarta.apache.org>
For additional commands, e-mail:
<mailto:tomcat-user-***@jakarta.apache.org>

[Glenn Olander]

Yes, it should be rare. We observed it once under heavy system load, but
haven't been
able to reproduce it. For our app however (or any security-sensitive
app), this could have
serious security consequences, so we'd like to ensure it never happens.

Craig, if you're around, I'm guessing the check was removed for
performance reasons?
I verified that there is no check for uniqueness by using my own random
number
generator which always returns the same sequence of bytes.
Any advice on how to enforce uniqueness other than replacing StandardManager
with a manager of our own?

Note that this issue should be independent of the seeding algorithm.
Regardless of
how the seed is derived, it would still be possible for the random
number generator to produce a session id which matches one which is already
in use, thus effectively giving one user access to another user's session.

- Glenn

Post by Turner, John
I guess that depends on your definition of "guaranteed". I happened to be
http://w6.metronet.com/~wjm/tomcat/2001/Sep/msg00544.html
According to that (though it is over a year old), Tomcat 4 uses
java.security.SecureRandom to generate session ids. The seeding algorithm
is a combination of things, so I guess its possible that there be identical
session ids, but my guess is it would be unbelievably rare.
John
-----Original Message-----
From: Glenn O
To: Tomcat Users List
Sent: 12/28/02 10:48 PM
Subject: Is session id guaranteed to be unique?
I'm tracking down a problem which only occurs rarely, but has the
symptom that when I attach
data to one session, it appears to mistakenly become attached to another
session. It is almost as if
tomcat is generating two sessions which have the same session id.
I'm looking at the tomcat source for createSession() in
ManagerBase.java, and I notice this code is
}
/*
synchronized (sessions) {
while (sessions.get(sessionId) != null) // Guarantee
uniqueness
sessionId = generateSessionId();
}
*/
session.setId(sessionId);
Does that mean tomcat could occasionally produce duplicate session id's?

[Tim Funk]

See this thread for more information:

http://marc.theaimsgroup.com/?l=tomcat-dev&m=104072138429223&w=2

Post by Glenn Olander
Yes, it should be rare. We observed it once under heavy system load, but
haven't been
able to reproduce it. For our app however (or any security-sensitive
app), this could have
serious security consequences, so we'd like to ensure it never happens.
Craig, if you're around, I'm guessing the check was removed for
performance reasons?
I verified that there is no check for uniqueness by using my own random
number
generator which always returns the same sequence of bytes.
Any advice on how to enforce uniqueness other than replacing
StandardManager
with a manager of our own?
Note that this issue should be independent of the seeding algorithm.
Regardless of
how the seed is derived, it would still be possible for the random
number generator to produce a session id which matches one which is already
in use, thus effectively giving one user access to another user's session.
- Glenn

Post by Turner, John
I guess that depends on your definition of "guaranteed". I happened to be
http://w6.metronet.com/~wjm/tomcat/2001/Sep/msg00544.html
According to that (though it is over a year old), Tomcat 4 uses
java.security.SecureRandom to generate session ids. The seeding algorithm
is a combination of things, so I guess its possible that there be identical
session ids, but my guess is it would be unbelievably rare.
John
-----Original Message-----
From: Glenn O
To: Tomcat Users List
Sent: 12/28/02 10:48 PM
Subject: Is session id guaranteed to be unique?
I'm tracking down a problem which only occurs rarely, but has the
symptom that when I attach
data to one session, it appears to mistakenly become attached to another
session. It is almost as if
tomcat is generating two sessions which have the same session id.
I'm looking at the tomcat source for createSession() in
ManagerBase.java, and I notice this code is
}
/*
synchronized (sessions) {
while (sessions.get(sessionId) != null) // Guarantee
uniqueness
sessionId = generateSessionId();
}
*/
session.setId(sessionId);
Does that mean tomcat could occasionally produce duplicate session id's?

--

[Jason Pyeron]

should the source not be patched?

how inefficient would collision detection be?
best case it would be a HashSet.contains and the storage for the set

-jason pyeron

On Sun, 29 Dec 2002, Tim Funk wrote:

See this thread for more information:

http://marc.theaimsgroup.com/?l=tomcat-dev&m=104072138429223&w=2

Post by Glenn Olander
Yes, it should be rare. We observed it once under heavy system load, but
haven't been
able to reproduce it. For our app however (or any security-sensitive
app), this could have
serious security consequences, so we'd like to ensure it never happens.
Craig, if you're around, I'm guessing the check was removed for
performance reasons?
I verified that there is no check for uniqueness by using my own random
number
generator which always returns the same sequence of bytes.
Any advice on how to enforce uniqueness other than replacing
StandardManager
with a manager of our own?
Note that this issue should be independent of the seeding algorithm.
Regardless of
how the seed is derived, it would still be possible for the random
number generator to produce a session id which matches one which is already
in use, thus effectively giving one user access to another user's session.
- Glenn

Post by Turner, John
I guess that depends on your definition of "guaranteed". I happened to be
http://w6.metronet.com/~wjm/tomcat/2001/Sep/msg00544.html
According to that (though it is over a year old), Tomcat 4 uses
java.security.SecureRandom to generate session ids. The seeding algorithm
is a combination of things, so I guess its possible that there be identical
session ids, but my guess is it would be unbelievably rare.
John
-----Original Message-----
From: Glenn O
To: Tomcat Users List
Sent: 12/28/02 10:48 PM
Subject: Is session id guaranteed to be unique?
I'm tracking down a problem which only occurs rarely, but has the
symptom that when I attach
data to one session, it appears to mistakenly become attached to another
session. It is almost as if
tomcat is generating two sessions which have the same session id.
I'm looking at the tomcat source for createSession() in
ManagerBase.java, and I notice this code is
}
/*
synchronized (sessions) {
while (sessions.get(sessionId) != null) // Guarantee
uniqueness
sessionId = generateSessionId();
}
*/
session.setId(sessionId);
Does that mean tomcat could occasionally produce duplicate session id's?

--

--
To unsubscribe, e-mail: <mailto:tomcat-user-***@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-***@jakarta.apache.org>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron http://www.pyerotechnics.com -
- Owner & Lead Pyerotechnics Development, Inc. -
- [phone] (c) 500 West University Parkway #1S -
- [phone] (f) Baltimore, Maryland 21210-3253 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and
notify the sender immediately. Any other use of the email by you
is prohibited.

[Bill Barker]

Post by Jason Pyeron
should the source not be patched?

IMHO, the source should be patched. As a result, Tim's patch will be in the
4.1.19 release.

Post by Jason Pyeron
how inefficient would collision detection be?
best case it would be a HashSet.contains and the storage for the set
-jason pyeron
http://marc.theaimsgroup.com/?l=tomcat-dev&m=104072138429223&w=2

Post by Glenn Olander
Yes, it should be rare. We observed it once under heavy system load, but
haven't been
able to reproduce it. For our app however (or any security-sensitive
app), this could have
serious security consequences, so we'd like to ensure it never happens.
Craig, if you're around, I'm guessing the check was removed for
performance reasons?
I verified that there is no check for uniqueness by using my own random
number
generator which always returns the same sequence of bytes.
Any advice on how to enforce uniqueness other than replacing
StandardManager
with a manager of our own?
Note that this issue should be independent of the seeding algorithm.
Regardless of
how the seed is derived, it would still be possible for the random
number generator to produce a session id which matches one which is already
in use, thus effectively giving one user access to another user's session.
- Glenn

Post by Turner, John
I guess that depends on your definition of "guaranteed". I happened to be
http://w6.metronet.com/~wjm/tomcat/2001/Sep/msg00544.html
According to that (though it is over a year old), Tomcat 4 uses
java.security.SecureRandom to generate session ids. The seeding algorithm
is a combination of things, so I guess its possible that there be identical
session ids, but my guess is it would be unbelievably rare.
John
-----Original Message-----
From: Glenn O
To: Tomcat Users List
Sent: 12/28/02 10:48 PM
Subject: Is session id guaranteed to be unique?
I'm tracking down a problem which only occurs rarely, but has the
symptom that when I attach
data to one session, it appears to mistakenly become attached to another
session. It is almost as if
tomcat is generating two sessions which have the same session id.
I'm looking at the tomcat source for createSession() in
ManagerBase.java, and I notice this code is
}
/*
synchronized (sessions) {
while (sessions.get(sessionId) != null) // Guarantee
uniqueness
sessionId = generateSessionId();
}
*/
session.setId(sessionId);
Does that mean tomcat could occasionally produce duplicate session id's?

--

--
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron http://www.pyerotechnics.com -
- Owner & Lead Pyerotechnics Development, Inc. -
- [phone] (c) 500 West University Parkway #1S -
- [phone] (f) Baltimore, Maryland 21210-3253 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and
notify the sender immediately. Any other use of the email by you
is prohibited.

[Jason Pyeron]

Where can we find Tim's patch (post the patch to the list please).

two reasons for this:
to implement it
and to peer review it.

-jp
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron http://www.pyerotechnics.com -
- Owner & Lead Pyerotechnics Development, Inc. -
- [phone] (c) 500 West University Parkway #1S -
- [phone] (f) Baltimore, Maryland 21210-3253 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and
notify the sender immediately. Any other use of the email by you
is prohibited.

Post by Jason Pyeron
should the source not be patched?

IMHO, the source should be patched. As a result, Tim's patch will be in the
4.1.19 release.

Post by Jason Pyeron
how inefficient would collision detection be?
best case it would be a HashSet.contains and the storage for the set
-jason pyeron
http://marc.theaimsgroup.com/?l=tomcat-dev&m=104072138429223&w=2

[Bill Barker]

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=tomcat-***@jakarta.apach
e.org&msgNo=53858

Post by Jason Pyeron
Where can we find Tim's patch (post the patch to the list please).
to implement it
and to peer review it.
-jp
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron http://www.pyerotechnics.com -
- Owner & Lead Pyerotechnics Development, Inc. -
- [phone] (c) 500 West University Parkway #1S -
- [phone] (f) Baltimore, Maryland 21210-3253 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and
notify the sender immediately. Any other use of the email by you
is prohibited.

Post by Jason Pyeron
should the source not be patched?

IMHO, the source should be patched. As a result, Tim's patch will be in the
4.1.19 release.

Post by Jason Pyeron
how inefficient would collision detection be?
best case it would be a HashSet.contains and the storage for the set
-jason pyeron
http://marc.theaimsgroup.com/?l=tomcat-dev&m=104072138429223&w=2

[Glenn Olander]

Thanks. I installed my own Manager with a fix similar to yours and it
seems to solve
the problem (I used a contrived Random class to generate duplicate
session id's).

This certainly sounds like a serious bug to me. If there's a mechanism
in place to
warn tomcat users about security problems, I'd recommend doing so, in
addition
to applying the patch. Speaking of which, I may be wrong, but I don't
think your
patch is quite right. You'll need to append the jvmRoute _before_ doing the
sessions.get() call, and again each time inside the loop. In other
words, I believe
it should look like this:

String sessionId = generateSessionId();
String jvmRoute = getJvmRoute();
// @todo Move appending of jvmRoute generateSessionId()???
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
}

synchronized (sessions) {
while (sessions.get(sessionId) != null){ // Guarantee
uniqueness
log("Found duplicate session id, getting a new one.");
sessionId = generateSessionId();
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
}
}
}

session.setId(sessionId);

return (session);

- Glenn

Post by Tim Funk
http://marc.theaimsgroup.com/?l=tomcat-dev&m=104072138429223&w=2

[Glenn Olander]

Post by Glenn Olander
to applying the patch. Speaking of which, I may be wrong, but I don't
think your
patch is quite right. You'll need to append the jvmRoute _before_ doing the

Never mind, I see you moved the appending into generateSessionId().

- Glenn