All, Our Security Team has composed a response to this issue, which has also been posted to the JRun Forums on this thread:
http://forums.allaire.com/jrun/messageview.cfm?catid=64&threadid=230840 Here is the text of this message: =========== Macromedia has confirmed a problem with duplicate session id's occurring under specific circumstances in JRun 3.0 and JRun 3.1. The bug number to reference is 24049. The problem happens in the specific case when referencing the web application root: http://[machine]/test without a trailing slash. The bug isn't specifically related to the use of default documents (as this url might indicate) but while using and configuring default documents, the URLs typically used will tend to be ones that uncover this bug (if a trailing slash isn't used after the webapp name). When these conditions are met, it is possible to get a session id that was in use by another browser that has since been closed. The workaround is to make sure all URL references such as these have a trailing slash /. Occasionally, a user bookmarking a URL without the trailing slash might unintentionally defeat this workaround. What Macromedia is doing ======================== Macromedia has created a patch for this bug (in both versions) that is currently in the QA test cycle. After we have completed testing, we will release patch sets with instructions and a security bulletin that will detail how to resolve this problem. We hope to have all this posted by the end of the week. Thank you for your patience. Stephen Dupre Security Response Team Macromedia, Inc. Stay up to date on security bulletins by visiting the Security Zone: http://www.allaire.com/security/ Report security related issues to: [EMAIL PROTECTED] =========== -----Original Message----- From: charles arehart [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 9:45 PM To: JRun-Talk Subject: RE: Attn: Sessions getting mixed up - I'd be worried JRun people! Fair point about the jsessionid cookies being non-persistent: I work with multiple application servers and forgot that JRun (among others) uses non-persistent ones. But I thought the other points would still be valid ones in helping clarify the root cause. Of course, by now we do have an admission by Macromedia of some problem. I was just offering some additional means to diagnose the problem. And to be honest, prior to Scott's note of today at 12:30, I still would have been as inclined to work to seek these sort of additional diagnostics for the problem. There have been other times when a problem was indicated by support as a "bug" when it was still not reproducible and therefore not easily solved. In such instances, they could use as much diagnostics as they could get, and that's where I was coming from. I really wasn't meaning to "cloud the issue". Anyway, looks like we're heading for resolution, and that's what matters most. /charlie -----Original Message----- From: Merdinger, Richard [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 10:09 PM To: JRun-Talk Subject: RE: Attn: Sessions getting mixed up - I'd be worried JRun people! Charles, let's not forget the point in the investigation where the JRun Tech Support department indicated that they were able to reproduce it and called it a bug. The testing I did took place in a non-proxied environment, with IIS and JRun running on the local machine. The other client was on the same local subnet. I was able to reproduce the problem without leaving the local machine at all by using a version of IE and a version of Netscape to reproduce the problem.) The jsessionid's are temporary browser cookies, not persistent ones. There is no record of them on the user's hard drive because they are only active for the duration of that the browser is open (that's why it is critical to close all instances of the browser between tests, otherwise, the browser would cache them). I don't mean to be difficult, but I don't want the issue to get clouded. Macromedia identified this behavior as a problem with their software. I quote from the email where I asked to not be charged for the tech support incident: "You will not be charged for this incident as we have found a bug." How much more clear can this get? Richard -----Original Message----- From: charles arehart [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 6:55 PM To: JRun-Talk Subject: RE: Attn: Sessions getting mixed up - I'd be worried JRun people! It would be interesting in the testing to also write out or simply compare the value of the cookie used to track the session, to see if a) it's there or b) it's different than it had been in previous invocations of the test. You may find some pattern (which as other posts have suggested could indicate that the browser is stopping the cookie from being sent along with the request). It's important to consider in evaluating this problem: - what cookie is being presented by the browser to the server. That is what will trigger JRun's recognition of the session. - if it's not there, then JRun will do URL rewriting. In that case, it's just doing what it's supposed to, and the culprit would seem to be the browser for not presenting the cookie. - if it's different than it had been previously, then immediately one should look at the cookie stored in the browser (for IE, on a Win2k machine, it's stored in C:\Documents and Settings\<username>\Cookies as something like <username>@<domainname>.txt .... where <username> is the userid the user is logged into on the server and <domainname> is the domain name of the site being browsed. If the cookie stored on the browser isn't the same as the cookie being reported in the JSP/servlet, then something is happening between the browser and Jrun. It could be a proxy (on the client's machine, or on their ISP if dialing in, or in the network in a corporate site), it could be a problem in the web server (if it's stepping in before passing the request to the browser). - if the cookie being reported is different than it had been on a previous execution of the test, but it's indeed the same cookie found within the browser, then one has to think that something caused a new cookie to be sent to the browser (otherwise it wouldn't be different than the previous run). Again, either the web server or JRun could be at fault there. So I'm just suggesting that sorting out this sort of problem involves identifying any of several moving parts. The theories offered by others about IE (and possible its content filtering) seem reasonable. And the fact that you're finding that URL re-writing is "suddenly" taking place is another strong clue. Having a test of the cookie values is the best diagnostic I could think of. As far as the fact that it seems that a cookie or URL sessionid for "someone else's session" is being sent, it would seem valuable then to track WHICH users end up sharing session ids. This would indeed suggest some other potentially strange problem and tracking which are sharing them may provide even further ammunition to diagnose the problem. /charlie -----Original Message----- From: Merdinger, Richard [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 08, 2001 6:59 PM To: JRun-Talk Subject: RE: Attn: Sessions getting mixed up - I'd be worried JRun people! Hi all: This is a result of the app server *assigning* the same jsessionid to two different client requests. These requests can come from different users on different machines using different browser manufacturers. I've done it, I've reproduced it with a FRESH JRun installation with a FRESH JRun server instance with a FRESH application context. There was one file in the web named index.jsp. All it did was to <%= session.getID() %> (pardon the syntax, I'm in a hurry<g>) Both I and a guy in an adjacent cube would 1. Go to the suspect URL 2. compare the session ID's 3. If they were different, we would close the browser completely and repeat. eventually, we would both see the same jsessionid on the screen. The one telltale symptom was that, even though we were using cookies, the url string was rewritten to include the "?jsessionid=" when the problem arose. I gave the tech folks at JRun support the instructions on how to do it and they reproduced it. It was a confirmed bug by the JRun tech folks, and they stated so in an email. What they did about it, I don't know. I would appreciate them telling us, though. --Rich -----Original Message----- From: michael veit [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 08, 2001 11:59 AM To: JRun-Talk Subject: Re: Attn: Sessions getting mixed up - I'd be worried JRun people! I think I see what you mean - since it JRun is just looking for a cookie to decide whether the session is new or not. gotcha. did u see Rich Merdingers post? I think he is saying that Allaire has knows about the bug..I am trying to confirm with him. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get the mailserver that powers this list at http://www.coolfusion.com Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
