Community
Participate
Working Groups
From a community member: "We recently found an bug in Jetty 9.4.x FileSessionDataStore that could be used to steal logged-in users' sessions without needing to know any session ID. The load(String id) method searches for files such that "name.contains(idWithContext)". Normally idWithContext will be found at the end of the filename, but it will also match if the provided ID is only a prefix of the true session ID. So, someone can just set their cookie to "JSESSIONID=" and get a clone of the most recently modified session. Or they can try "JSESSIONID=node0a" "JSESSIONID=node0b" etc to get various other sessions. This was fixed incidentally in Jetty 9.4.9 by https://github.com/eclipse/jetty.project/issues/2038. However, I couldn't find any information in the release notes or elsewhere about this being a security vulnerability." This has been reproduced by the Jetty team and we'll be seeking to issue a CVE notification. This is a bit more of an odd case since it was resolved about 8 months ago inadvertently but given the nature of the severity if someone were using file-based sessions we feel it is important to proactively notify the community. We have some short-term housekeeping to do and perhaps some additional information to include on this before seeking the actual CVE number which we will follow up on though the normal process.
Discovered and reported by frey Morlan <jeffrey@everlaw.com>
(Copy/Paste burp in last message) Discovered and reported by Jeffrey Morlan <jeffrey@everlaw.com>
I have confirmation that Everlaw the company is additionally open to being named as discoverer. We are working on the proper way to distribute a fix for this issue to the affected versions and once we have that in place we'll update this issue with a bit of information on that and call for the CVE to be granted.
Wayne, best we can find for CWE for this one is: https://cwe.mitre.org/data/definitions/6.html
Wayne, Current steps for remediation on this issue is that we are staging new releases for all affected versions and will announce the issue and steps to resolve this next Monday the 25th. This issue is very severe for a narrow slice of users that have Jetty configured a certain way (not default) so it is important to get the releases out. Can we get the CVE number granted for this so we can work on the messaging and announcements and schedule its release for next Monday?
(In reply to Jesse McConnell from comment #5) > Can we get the CVE number granted for this so we can work on the messaging > and announcements and schedule its release for next Monday? We'll use CVE-2018-12538 I'll hold submitting to Mitre until after I hear from you. In preparation, I'll need a short paragraph describing this issue and the versions affected.
Some of this language should get things started Wayne. FileSessionDataStore Session Hijacking If using the optional Jetty provided FileSessionDataStore for persistent storage of HttpSession details, it is possible for a malicious user to access/hijack other HttpSessions and even delete unmatched HttpSessions present in the FileSystem’s storage for the FileSessionDataStore . The use of partial Session IDs can result in hijacking of an existing HttpSession, as well as the deletion of other HttpSessions that also match this partial SessionID. A partial SessionID of a single byte could be used to access a random users HttpSession with that single byte match, including the deletion of other HttpSessions that match that single byte. A partial SessionID of blank could result in the return of the most recent HttpSession and deletion of all stored HttpSessions. This vulnerability was corrected in Jetty 9.4.9 with a complete overhaul of the FileSessionDataStore with an eye on the performance of large lists of HttpSessions. This vulnerability was not known at the time the 9.4.9 fix was being implemented. CVE Risk: HttpSessions present in the FileSystem’s storage could be hijacked/accessed by an unauthorized user. HttpSessions present in the FileSystem's storage could be deleted by an unauthorized user. Versions Affected: 9.4.0.v20161208 9.4.1.v20170120 9.4.2.v20170220 9.4.3.v20170317 9.4.4.v20170414 9.4.5.v20170502 9.4.6.v20170531 9.4.7.v2017094 9.4.8.v20171121 Configurations Affected: Only configurations using the org.eclipse.jetty.server.session.FileSessionDataStore class are impacted. Users of jetty-distribution / jetty-home with the session-store-file module are also impacted. Remediation: Users/Implementations affected by this issue can upgrade to any version of Jetty 9.4.9.v20180320 or newer. We would strongly encourage upgrading to 9.4.11.v20180605, as it also includes the fixes for the other CVEs reported earlier (maybe list the other ones?). We are actively building out new, patched versions of the above-affected versions of Jetty to correct/backport the FileSessionDataStore from 9.4.8 back to impacted and problematic versions. These will be 9.4.x.v20180619 where x = [0-8]
(In reply to Jesse McConnell from comment #7) > Some of this language should get things started Wayne. Let me know when you're finished ;-) Or do you think that this first paragraph is a good enough summary? -- If using the optional Jetty provided FileSessionDataStore for persistent storage of HttpSession details, it is possible for a malicious user to access/hijack other HttpSessions and even delete unmatched HttpSessions present in the FileSystem’s storage for the FileSessionDataStore . --
works for me
(In reply to Jesse McConnell from comment #9) > works for me I'll push the CVE to Mitre in the next couple of minutes so that you'll be ready for June 25. Note that I have to remove the committer-only check to do this. If you have any concerns, raise them now.
(In reply to Wayne Beaton from comment #10) > I'll push the CVE to Mitre in the next couple of minutes so that you'll be > ready for June 25. Note that I have to remove the committer-only check to do > this. If you have any concerns, raise them now. I'm ok with removing the committer-only checks.
https://github.com/CVEProject/cvelist/pull/637
