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, with a number of intervening sessions, which had duplicate session id's. The pair of sessions corresponded to the user report of seeing someone else's session data. We're using 4.1.12. 2) I don't believe this is *common* The problem hasn't been duplicated in our app, so I'm not sure I'd call this a common problem, but that's a subjective term. 3) I believe this is a serious vulnerability There should probably be some sort of an alert delivered to tomcat users to let them know of this problem. 4) A simple patch is available It is not necessary to use the head version of tomcat to fix the problem. Simply install your own manager class, which subclasses StandardManager, which has the duplicate session id checking implemented. In other words, a simple patch on an existing tomcat installation can fix this. 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. The head revision now includes such a check, so I believe the problem has been solved. Even the weakest of PRNG's would generate a collision only rarely, so I wouldn't worry about improving its strength. - Glenn -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
