DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36995.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36995.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
/show_bug.cgi?id=36995
--- Additional Comments From [EMAIL PROTECTED] 2005-10-11 14:01 ---
Created an attachment (id=16657)
-- (http://issues.apache.org/bugzilla/attachment.cgi?id=16657action=view)
A simple test case to check for duplicate session ids.
--
Configure bugmail: http
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36995.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36995.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Friday, January 10, 2003 1:34 PM
Subject: Re: Duplicate session IDs are *common*
Glenn Olander [EMAIL PROTECTED] writes:
I think you may have misunderstood. I'm just pointing out that, from a
user's
perspective, a good solution
Impressive.
Could you make a small modification and run the same test with
20 concurent threads ? I checked the code and we have plenty of
syncs, but you never know.
Interesting - java.util.Random is not synchronized, so it is very likely
that 2 threads calling the method at the same time will
Costin Manolache wrote:
Could you make a small modification and run the same test with
20 concurent threads ? I checked the code and we have plenty of
syncs, but you never know.
OK -- for this I went to the horse's (or maybe I should say, cat's)
mouth with the same result -- collisions still
On Fri, 10 Jan 2003, Phil Steitz wrote:
Except that hash( i++ . secret).i is generally a lot cheaper and easier to
Unfortunately, hashing blows away guaranteed uniqueness (one-way =
not 1-1), so if your last step is a hash, you will need to keep the
Hence the concatenation with 'i'. Or
On Fri, 10 Jan 2003, Costin Manolache wrote:
I find it amazing that 2 people reported beeing hit by meteors (duplicate
session ids ) in the same week.
Make that 3; I've seen this as well; I suspect this is becauce tomcat
saves the sessions across restarts; and then happens to re-generate them
On Sat, 11 Jan 2003, Phil Steitz wrote:
Sorry, missed that. You are correct (also about hashing being a cheap
way to get randomization).
No, no; just unpredictability.
An interesting challenge is how to keep the uniqueness bits either
short enough so that the random bits give strong
on 2003/1/9 10:28 PM, Remy Maucherat [EMAIL PROTECTED] wrote:
I can't reproduce an id collision so far.
Remy
I'm sure you aren't running the same level of concurrency that say a company
like Maxis is running. Duplicate the environment and the problems become
clear.
-jon
--
StudioZ.tv /\
Using a modified version of Tim Funk's Collide.java, I ran the
following dispersion test (using Sun's Linux jdk's 1.3.1_03 and 1.4.1_01):
1. Generate n session id's.
2. For each pair of generated id's, count the number of matching
characters in the two strings (i.e., the number of positions where
I was unable to reproduce a collision too. I took ManagerBase and
converted it to a standalone java program (by stripping out code) to see
if I might get duplicates. But I keep running out of memory near 1
million sessions.
java Collide 1
Generates 1 ids. (Change the number to change
On Thu, 9 Jan 2003, Schnitzer, Jeff wrote:
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
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.
If I leave my browser open and go for lunch and someone else gets my
expired session id, I return and continue browsing, wouldn't that cause
problems?
Here's a follow-up on the bug report I submitted that started this thread.
1) We confirmed the problem is a duplicate session id.
Luckily we were logging session id's. It took a lot of hunting through
access logs, but we did indeed find two sessions which were started a
couple of minutes apart,
Glenn Olander [EMAIL PROTECTED] writes:
5) The strength of the PRNG is largely irrelevant
As a user, I wouldn't trust any solution which lacks a check for
duplicate session id's, regardless of the strength of the PRNG.
This doesn't seem to me to be a plausible position in view
of the fact
Jim Jagielski [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Glenn Olander [EMAIL PROTECTED] writes:
5) The strength of the PRNG is largely irrelevant
As a user, I wouldn't trust any solution which lacks a check for
duplicate session id's, regardless of the strength of the
At 10:42 AM -0800 1/10/03, Eric Rescorla wrote:
Jim Jagielski [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Glenn Olander [EMAIL PROTECTED] writes:
5) The strength of the PRNG is largely irrelevant
As a user, I wouldn't trust any solution which lacks a check for
duplicate
The check will verify that the session id doesn't duplicate another
active session.
If the session expires - it is still possible ( even if extremely unlikely )
that a user will reuse the same browser window and get into someone's else
session.
I think this is as likely as someone using a
Eric Rescorla wrote:
Jim Jagielski [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Glenn Olander [EMAIL PROTECTED] writes:
5) The strength of the PRNG is largely irrelevant
As a user, I wouldn't trust any solution which lacks a check for
duplicate session id's, regardless of
On Fri, 10 Jan 2003, Jim Jagielski wrote:
But it doesn't change the fact that randomness != uniqueness, which is
what Glenn's point was I think.
Just as an example; doing on issue
syncronized count++;
id = count.ipaddr
add port if you must :-)
gives you a
I think you may have misunderstood. I'm just pointing out that, from a
user's
perspective, a good solution requires two elements:
1) a good PRNG, such as secureRandom
2) a uniqueness guarantee
I'm not saying a PRNG is unneeded. I'm just saying a good one like PRNG
is good
enough as long as it
Jim Jagielski [EMAIL PROTECTED] writes:
Of course, as you said, it depends on the range and the timespan.
But it doesn't change the fact that randomness != uniqueness, which is
what Glenn's point was I think.
Perhaps not from a theoretical persective, but from a practical
perspective it does.
Glenn Olander [EMAIL PROTECTED] writes:
I think you may have misunderstood. I'm just pointing out that, from a
user's
perspective, a good solution requires two elements:
1) a good PRNG, such as secureRandom
2) a uniqueness guarantee
I'm not saying a PRNG is unneeded. I'm just saying a
Costin Manolache [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Jim Jagielski [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Glenn Olander [EMAIL PROTECTED] writes:
5) The strength of the PRNG is largely irrelevant
As a user, I wouldn't trust any solution which lacks
I saw another problem that had similar symptoms to
duplicate
session ID's. My application was getting collisions
between different users having the same session ID
using
tomcat 4.0.5. I found that the request headers were
not
being cleared out when they were recycled so that
cookies
from a current
On Fri, 10 Jan 2003, Glenn Olander wrote:
1) a good PRNG, such as secureRandom
Why does it need to be securely random; surely unpredicatable is good
enough ?
2) a uniqueness guarantee
count++ +:+myip+:+myport
is also quite unqiue :-)
DW.
--
To unsubscribe, e-mail:
ID provides a statistical probability of collision so low that
there is no need to explicitly check for uniqueness.
Or just add a syncronized i++ to make sure.
Dw.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
On Fri, 10 Jan 2003, Glenn Olander wrote:
1) a good PRNG, such as secureRandom
Why does it need to be securely random; surely unpredicatable is good
enough ?
Securely random and unpredictable are effectively the same thing.
-Ekr
--
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
ID provides a statistical probability of collision so low that
there is no need to explicitly check for uniqueness.
Or just add a syncronized i++ to make sure.
Yes.
There's nothing wrong with what you propose, but it's sort of
like saying
Securely random and unpredictable are effectively the same thing.
Depends on your definition; one-way-function((count++) + (secret)) is
quite unpredictable; expcet for those knowing the secret. Secure random
generators give you a value which is unpredictable for all. And are a lot
more
On 10 Jan 2003, Eric Rescorla wrote:
There's nothing wrong with what you propose, but it's sort of
like saying maybe I should wear a helmet at all times
because a meteor might drop on my head. Sure, it could happen,
btu it's not the thing I'd worry about.
Except that hash( i++ . secret).i
, but it's sort of
like saying maybe I should wear a helmet at all times
because a meteor might drop on my head. Sure, it could happen,
btu it's not the thing I'd worry about.
I find it amazing that 2 people reported beeing hit by meteors (duplicate
session ids ) in the same week.
You're right
Costin Manolache wrote:
I find it amazing that 2 people reported beeing hit by meteors (duplicate
session ids ) in the same week.
I find it odd that it actually happened ...
You're right - a counter is better than time. It'll duplicate the counter
if tomcat is restarted - so probably
Combining two messages...
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
Securely random and unpredictable are effectively the same thing.
Depends on your definition; one-way-function((count++) + (secret)) is
quite unpredictable; expcet for those knowing the secret. Secure random
(duplicate
session ids ) in the same week.
I do too. Something is wrong but I don't know what it is yet.
However, the solution isn't to add a bandaid, but rather to
examine the code and figure out what's broken.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED
Dirk-Willem van Gulik wrote:
On 10 Jan 2003, Eric Rescorla wrote:
There's nothing wrong with what you propose, but it's sort of
like saying maybe I should wear a helmet at all times
because a meteor might drop on my head. Sure, it could happen,
btu it's not the thing I'd worry about.
Craig R. McClanahan wrote:
On Wed, 8 Jan 2003, Aditya wrote:
Date: Wed, 08 Jan 2003 22:36:58 -0800
From: Aditya [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: Duplicate session IDs are *common*
On Wed, 08 Jan
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
Remy Maucherat [EMAIL PROTECTED] 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
On 9 Jan 2003, Eric Rescorla wrote:
Remy Maucherat [EMAIL PROTECTED] 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
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
On 9 Jan 2003, Eric Rescorla wrote:
Remy Maucherat [EMAIL PROTECTED] 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,
of a truly randomly generated
128-bit number, but I wouldn't run a banking application on it.
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
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
there is no harm.
Costin
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
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
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
On Wed, 8 Jan 2003, Costin Manolache wrote:
Date: Wed, 08 Jan 2003 19:37:28 -0800
From: Costin Manolache [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Duplicate session IDs are *common*
Schnitzer, Jeff wrote:
For whatever
On Wed, 08 Jan 2003 19:37:28 -0800, Costin Manolache [EMAIL PROTECTED] 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
On Wed, 8 Jan 2003, Aditya wrote:
Date: Wed, 08 Jan 2003 22:36:58 -0800
From: Aditya [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: Duplicate session IDs are *common*
On Wed, 08 Jan 2003 19:37:28 -0800
Bill Barker wrote:
Schnitzer, Jeff [EMAIL PROTECTED] writes:
The standard fix for this is to use a cryptographic pseudo-random
number generator, such as Java's SecureRandom. SecureRandom
automatically seeds itself from allegedly random system data.
the probability that two sufficiently long
I can also report that I've seen this happen when the system is under
load. We had a
user log in and gain access to another user's session. I'm sure you can
understand that
makes it a very serious bug for security-sensitive applications, perhaps
even deserving
some kind of security alert
Glenn Olander wrote:
I can also report that I've seen this happen when the system is under
load. We had a
user log in and gain access to another user's session. I'm sure you can
understand that
makes it a very serious bug for security-sensitive applications, perhaps
even deserving
some kind of
fyi, the version he checked in contains a bug. It should append jvmRoute
within
the loop. It should look like this:
String sessionId = generateSessionId();
String jvmRoute = getJvmRoute();
// @todo Move appending of jvmRoute generateSessionId()???
if (jvmRoute != null) {
This looks true by the looks of:
http://cvs.apache.org/viewcvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java?rev=1.15content-type=text/vnd.viewcvs-markup
The while loop is looking for one session ID, and if JVM route is set, a
different session ID is saved.
Bill Barker [EMAIL PROTECTED] writes:
As far as I can tell, ManagerBase could really use your expertise on this.
The current algorithm is really bad :-(
Ok. I've read the current code, which, as you say, is rather complicated.
As far as I can tell, here's how it works:
INITIALIZATION
(1)
Good catch!
I'll apply the patch (if somebody doesn't beat me to it).
- Original Message -
From: Glenn Olander [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, December 30, 2002 8:05 AM
Subject: Re: Duplicate session IDs?
fyi, the version he checked
]
The Sims Online
-Original Message-
From: Tim Funk
Subject: Re: Duplicate session IDs?
Date: Wed, 25 Dec 2002 05:54:27 -0800
Any kind of monotonic increase is bad security. Since everyone can view
the source, everyone knows the algorithm. With enough brute force,
someone can guess session ids
Schnitzer, Jeff [EMAIL PROTECTED] writes:
Yes that's true if the monotonically increasing value is added to the
random number _before_ the hash... and even worse, there is nothing that
guarantees that two numbers won't hash to the same value so we're back
to the duplicate session id problem.
- Original Message -
From: Eric Rescorla [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Sunday, December 29, 2002 10:05 PM
Subject: Re: Duplicate session IDs?
Schnitzer, Jeff [EMAIL PROTECTED] writes:
Yes that's true if the monotonically increasing value
Eric Rescorla wrote:
Schnitzer, Jeff [EMAIL PROTECTED] writes:
Yes that's true if the monotonically increasing value is added to the
random number _before_ the hash... and even worse, there is nothing that
guarantees that two numbers won't hash to the same value so we're back
to the duplicate
Any kind of monotonic increase is bad security. Since everyone can view
the source, everyone knows the algorithm. With enough brute force,
someone can guess session ids.
Lets start in the simple scenario:
first session_id = 1, next session_id = 2, ...
Too simple, yes.
But tomcat digests the
What prevents Tomcat from issuing duplicate session IDs? From the code
in ManagerBase, it doesn't look like anything prevents it - the only
unique value in the ID is a random number. In fact, the code which
would guarantee uniqueness is commented out.
I believe we have seen a problem
was created
when the occurance happens
If there is interest in this - I can throw it into bugzilla so it
doesn't get lost.
-Tim
Schnitzer, Jeff wrote:
What prevents Tomcat from issuing duplicate session IDs? From the code
in ManagerBase, it doesn't look like anything prevents it - the only
unique
on 2002/12/24 5:52 AM, Tim Funk [EMAIL PROTECTED] wrote:
I hope you were joking about the monotonic increase of sessionIds. If
that were done - it would be trivial to steal another's sessionId by
guessing.
How is that?
laskdfowifjwo2i3jofij2oi3jofwjieogih934htwo4i1
be
caused if someone was using Tomcat for a banking application...
Jeff Schnitzer
[EMAIL PROTECTED]
The Sims Online
---
From: Tim Funk
Subject: Re: Duplicate session IDs?
Date: Tue, 24 Dec 2002 05:53:33 -0800
68 matches
Mail list logo
