You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by po...@voyanttech.com on 2003/01/09 11:57:33 UTC
Email Rejected: Unknown or disallowed attachment type

Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <to...@jakarta.apache.org>
Message-ID: <3E...@apache.org>
Date: Thu, 09 Jan 2003 10:53:50 +0100
From: Remy Maucherat <re...@apache.org>
Organization: ASF
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126
MIME-Version: 1.0
To: Tomcat Developers List <to...@jakarta.apache.org>
Subject: Re: Duplicate session IDs are *common*
References: <DF...@jethro.max.ad.ea.com>
In-Reply-To: <DF...@jethro.max.ad.ea.com>
Content-Type: multipart/mixed;
 boundary="------------060506040306030306060400"

--------------060506040306030306060400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------060506040306030306060400
Content-Type: application/octet-stream;
 name="ManagerBase.class"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;

FOR ANTI-VIRUS SECURITY, THIS EMAIL HAS BEEN REJECTED.

REASON:
THIS EMAIL CONTAINED AN ATTACHMENT TYPE OF '.class' WHICH IS NOT PERMITTED.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>