tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: Duplicate session IDs are *common*
Date Fri, 10 Jan 2003 06:32:56 GMT
Schnitzer, Jeff wrote:

> I've already patched the 4.1.12 version we are running with the fix that
> is currently in CVS.  Unfortunately our only notification of when the
> problem occurs is when users notice (which they probably wouldn't unless
> they acquired an administrative session) and choose to inform us.  I
> won't "know" the fix worked without waiting some number of weeks.
> One thing to contemplate is that if you have 100,000 sessions and you
> get 10 new sessions created every second, that's the equivalent of 1
> million inadvertent hack attempts every single second.  Granted that's
> still small compared to the total size of a truly randomly generated
> 128-bit number, but I wouldn't run a banking application on it.

I would check the application too - Craig had a very good point.
Even with java.util.Random it is very unlikely to generate 2 identical 
numbers close enough for 2 current sessions to be swaped.

It's easy to add a log line when a duplicate is detected. One
think is pretty sure - with the patch applied you can't have
duplicated IDs. 

Note that you would need 1 million sessions that are active at the
same time - if a session expires and the id is reused there is no harm.


> Jeff Schnitzer
> -----Original Message-----
> From: Remy Maucherat
> Subject: Re: Duplicate session IDs are *common*
> Date: Thu, 09 Jan 2003 02:57:23 -0800
> 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.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message