You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Schnitzer, Jeff" <JS...@maxis.com> on 2003/01/09 03:31:14 UTC
Duplicate session IDs are *common*
For whatever reason, be it the seed algorithm or the hashing algorithm
or something else that degenerates the randomness - the duplicate
session ID problem is very, very common.
I discovered this problem because a few of our users suddenly found
themselves with the sessions from administrative accounts. Luckily they
alerted us instead of causing mayhem. There were at least three
separate occasions of this in the last week - that we heard about.
We have also seen this a number of times with other game components -
users suddenly finding themselves logged in as other people.
It probably explains the recent post to tomcat-user included below.
Here at my company this problem caused about as much panic as a wildfire
breaking out in the machine room (read: LOTS). I humbly suggest raising
the level of concern a bit; post a security bulletin, etc.
Jeff Schnitzer
jschnitzer@maxis.com
The Sims Online
> -----Original Message-----
> From: Michael Molloy [mailto:mmolloy@ncycles.com]
> Sent: Wednesday, January 08, 2003 2:13 PM
> To: Tomcat Users List
> Subject: One other freaky thing
>
> Our application is running on a server in Pennsylvania. A user there
> was working as well as a user in Tennessee. The user in Tennessee got
> an error on a page, hit her back key, and the user in Pennsylvania's
> screen showed up on the Tennessee user's screen. The people in
> Tennessee are connected to the Pennsylvania system via a frame relay.
>
> Everything is contained within each user's session, so this should
> never happen. The application has been under development for a year
> now, and this has never happened before.
>
> Some kind of weird bug that we shouldn't worry about, or something
that
> someone else has encountered?
>
> Thanks for any help,
> --Michael Molloy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Duplicate session IDs are *common*
Posted by Eric Rescorla <ek...@rtfm.com>.
Dirk-Willem van Gulik <di...@webweaving.org> writes:
> On 9 Jan 2003, Eric Rescorla wrote:
>
> > Remy Maucherat <re...@apache.org> writes:
> > > - A MD5 hash occurs after getting the SecureRandom. This looks like a
> > > mistake, and decreases the quality of the random a lot, but given the
> > > quality of MD5, that shouldn't be noticeable in the real world.
>
> > I think that the MD5 is pointless but it shouldn't decrease the
> > quality of the randomness to any interesting degree.
>
> It makes the value less predictible.
Not if the initial value came out of SecureRandom in the first
place.
> You propably want to argue -what- sort of randomness you want
>
> - unpredicable session id's
> - a unique session id
> - always a guaranteed different session id.
> - session id with no information.
>
> Pick one, pick two, but if you pick three or more you are going to have a
> hard time.
If you use a cryptographically secure PRNG you can get 1,2,4
and 3 with very high probability. The probability of two
properly randomly generated 128-bit numbers colliding is
negligible.
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Duplicate session IDs are *common*
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 9 Jan 2003, Eric Rescorla wrote:
> Remy Maucherat <re...@apache.org> writes:
> > - A MD5 hash occurs after getting the SecureRandom. This looks like a
> > mistake, and decreases the quality of the random a lot, but given the
> > quality of MD5, that shouldn't be noticeable in the real world.
> I think that the MD5 is pointless but it shouldn't decrease the
> quality of the randomness to any interesting degree.
It makes the value less predictible. But as it adds no information (and
one could argule only looses it if the initial information had more than
128bits of randonm (which is highly unlikely)) it does not change the
'randomness' itself.
You propably want to argue -what- sort of randomness you want
- unpredicable session id's
- a unique session id
- always a guaranteed different session id.
- session id with no information.
Pick one, pick two, but if you pick three or more you are going to have a
hard time.
Dw
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Duplicate session IDs are *common*
Posted by Eric Rescorla <ek...@rtfm.com>.
Remy Maucherat <re...@apache.org> writes:
> - A MD5 hash occurs after getting the SecureRandom. This looks like a
> mistake, and decreases the quality of the random a lot, but given the
> quality of MD5, that shouldn't be noticeable in the real world.
I think that the MD5 is pointless but it shouldn't decrease the
quality of the randomness to any interesting degree.
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Duplicate session IDs are *common*
Posted by Remy Maucherat <re...@apache.org>.
Schnitzer, Jeff wrote:
> For whatever reason, be it the seed algorithm or the hashing algorithm
> or something else that degenerates the randomness - the duplicate
> session ID problem is very, very common.
>
> I discovered this problem because a few of our users suddenly found
> themselves with the sessions from administrative accounts. Luckily they
> alerted us instead of causing mayhem. There were at least three
> separate occasions of this in the last week - that we heard about.
>
> We have also seen this a number of times with other game components -
> users suddenly finding themselves logged in as other people.
>
> It probably explains the recent post to tomcat-user included below.
>
> Here at my company this problem caused about as much panic as a wildfire
> breaking out in the machine room (read: LOTS). I humbly suggest raising
> the level of concern a bit; post a security bulletin, etc.
We have to make sure the problem is real before putting out any
advisory. You should patch the ManagerBase class to the latest version
to see if it helps (compile the latest version, and put it in
$CATALINA_HOME/server/classes/org/apache/catalina/session). A compiled
version is attached to this email if you can't get it easily.
However:
- We did not have any reports before 4.1.18 that the algorithm used was
weak; it was actually believed it was not, and it had been around for a
long time (I do not believe it was touched at all for months).
- A MD5 hash occurs after getting the SecureRandom. This looks like a
mistake, and decreases the quality of the random a lot, but given the
quality of MD5, that shouldn't be noticeable in the real world.
- If collisions *do* actyually happen, then it is a security problem and
the patch to the StandardManager should fix it. However, it would also
indicate that the ids generated can likely be guessed by an attacker, so
we also have to fix the algorithm.
Remy
Re: Duplicate session IDs are *common*
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Craig R. McClanahan wrote:
>
> On Wed, 8 Jan 2003, Aditya wrote:
>
>
>>Date: Wed, 08 Jan 2003 22:36:58 -0800
>>From: Aditya <ad...@grot.org>
>>Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
>>To: Tomcat Developers List <to...@jakarta.apache.org>
>>Subject: Re: Duplicate session IDs are *common*
>>
>>
>>>On Wed, 08 Jan 2003 19:37:28 -0800, Costin Manolache <cm...@yahoo.com> said:
>>>The default is java.security.SecureRandom - and should give enough
>>>randomness. There is a change on head ( that would work with 5.0 -
>>>but it can be backported ) that allow you to use /dev/urandom ( or
>>>another source - it can be a pipe or something like that ).
>>
>>what about "hashing" the random part with System.currentTimeMillis()
>>so that even the vanishingly small probability of a collision is
>>avoided? Or would that be too expensive?
>>
>
>
> The better check is the one that has been implemented -- if whatever
> session id you just calculated (for a new session) is already in use, pick
> another one.
I think that is done in ManagerBase.java
>
>
>>Adi
>
>
> Craig
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Duplicate session IDs are *common*
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 8 Jan 2003, Aditya wrote:
> Date: Wed, 08 Jan 2003 22:36:58 -0800
> From: Aditya <ad...@grot.org>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Re: Duplicate session IDs are *common*
>
> > On Wed, 08 Jan 2003 19:37:28 -0800, Costin Manolache <cm...@yahoo.com> said:
> > The default is java.security.SecureRandom - and should give enough
> > randomness. There is a change on head ( that would work with 5.0 -
> > but it can be backported ) that allow you to use /dev/urandom ( or
> > another source - it can be a pipe or something like that ).
>
> what about "hashing" the random part with System.currentTimeMillis()
> so that even the vanishingly small probability of a collision is
> avoided? Or would that be too expensive?
>
The better check is the one that has been implemented -- if whatever
session id you just calculated (for a new session) is already in use, pick
another one.
> Adi
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Duplicate session IDs are *common*
Posted by Aditya <ad...@grot.org>.
> On Wed, 08 Jan 2003 19:37:28 -0800, Costin Manolache <cm...@yahoo.com> said:
> The default is java.security.SecureRandom - and should give enough
> randomness. There is a change on head ( that would work with 5.0 -
> but it can be backported ) that allow you to use /dev/urandom ( or
> another source - it can be a pipe or something like that ).
what about "hashing" the random part with System.currentTimeMillis()
so that even the vanishingly small probability of a collision is
avoided? Or would that be too expensive?
Adi
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Duplicate session IDs are *common*
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 8 Jan 2003, Costin Manolache wrote:
> Date: Wed, 08 Jan 2003 19:37:28 -0800
> From: Costin Manolache <cm...@yahoo.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Duplicate session IDs are *common*
>
> Schnitzer, Jeff wrote:
>
> > For whatever reason, be it the seed algorithm or the hashing algorithm
> > or something else that degenerates the randomness - the duplicate
> > session ID problem is very, very common.
> >
> > I discovered this problem because a few of our users suddenly found
> > themselves with the sessions from administrative accounts. Luckily they
> > alerted us instead of causing mayhem. There were at least three
> > separate occasions of this in the last week - that we heard about.
> >
> > We have also seen this a number of times with other game components -
> > users suddenly finding themselves logged in as other people.
> >
> > It probably explains the recent post to tomcat-user included below.
> >
> > Here at my company this problem caused about as much panic as a wildfire
> > breaking out in the machine room (read: LOTS). I humbly suggest raising
> > the level of concern a bit; post a security bulletin, etc.
>
> What version of tomcat ? Are you on Linux ? What randomClass are you using ?
> How many sessions are usually generated ?
>
> The default is java.security.SecureRandom - and should give enough
> randomness. There is a change on head ( that would work with 5.0 - but
> it can be backported ) that allow you to use /dev/urandom ( or another
> source - it can be a pipe or something like that ).
>
Even though duplicate session ids are *possible* (because Tomcat doesn't
check for it), the 99.9% cause of this kind of a problem is application
programming errors like using an instance (or static) variable in a
servlet to store per-request state information. That only works if the
servlet never processes more than one request at a time. Based on my
experience, I don't believe this is a *common* problem, but it is a
problem that needs to be addressed.
>
> Costin
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Duplicate session IDs are *common*
Posted by Costin Manolache <cm...@yahoo.com>.
Schnitzer, Jeff wrote:
> For whatever reason, be it the seed algorithm or the hashing algorithm
> or something else that degenerates the randomness - the duplicate
> session ID problem is very, very common.
>
> I discovered this problem because a few of our users suddenly found
> themselves with the sessions from administrative accounts. Luckily they
> alerted us instead of causing mayhem. There were at least three
> separate occasions of this in the last week - that we heard about.
>
> We have also seen this a number of times with other game components -
> users suddenly finding themselves logged in as other people.
>
> It probably explains the recent post to tomcat-user included below.
>
> Here at my company this problem caused about as much panic as a wildfire
> breaking out in the machine room (read: LOTS). I humbly suggest raising
> the level of concern a bit; post a security bulletin, etc.
What version of tomcat ? Are you on Linux ? What randomClass are you using ?
How many sessions are usually generated ?
The default is java.security.SecureRandom - and should give enough
randomness. There is a change on head ( that would work with 5.0 - but
it can be backported ) that allow you to use /dev/urandom ( or another
source - it can be a pipe or something like that ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>