Schnitzer, Jeff wrote:
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.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.
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
ManagerBase.class
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
