Community
Participate
Working Groups
We are currently tracking an issue that affects a few released versions of Jetty where reportedly under heavy load a response buffer may become corrupted and handled incorrectly. There is an underlying issue that has been identified and resolved here: https://github.com/eclipse/jetty.project/issues/4936 The security implications are as of yet unconfirmed that I am aware of, but at first blush a CVE seems warrented. We'll get a score and description together soon and post to this issue.
We've been researching this further and agree a CVE is needed. Information usually required: CVE Score Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L/E:P/RL:O/RC:C/CR:M/IR:M/AR:M/MAV:N/MAC:H/MC:L Formal Description: In case of too large response headers, Jetty throws an exception to produce an HTTP 431 error. When this happens, the ByteBuffer containing the HTTP response headers is released back to the ByteBufferPool twice. Because of this double release, two threads can acquire the same ByteBuffer from the pool and while thread1 is about to use the ByteBuffer to write response1 data, thread2 fills the ByteBuffer with response2 data. Thread1 then proceeds to write the buffer that now contains response2 data. This results in client1, which issued request1 and expects responses, to see response2 which could contain sensitive data belonging to client2 (HTTP session ids, authentication credentials, etc.). Associated CWEs: CWE-672: Operation on a Resource after Expiration or Release CWE-675: Duplicate Operations on Resource
Additional note: This issue was resolved in Jetty 9.4.30.v20200611
Is the affected version range all versions of Eclipse Jetty before 9.4.30.v20200611? FYI, there is help in the handbook. https://www.eclipse.org/projects/handbook/#vulnerability-cve
Wayne, it is only a recent problem that we added in 9.4.27
9.4.27.v20200227 >=< 9.4.29.v20200521
I've pushed this to the central authority. Pull request: https://github.com/CVEProject/cvelist/pull/4270
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/167468
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/167469
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.bundles/+/167470
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ua/+/167471
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.bundles/+/167470 was merged to [R4_15_maintenance]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=d42db65204bfb1b67d272d7ab199484747c44455
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/167469 was merged to [R4_15_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=a74a6698c9bb4067fac3dbfde60414c8e2c6f43f
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ua/+/167471 was merged to [R4_15_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/?id=fa104dea0e03097baf857d0c2ae1d7a149287cc5
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.bundles/+/167474
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.bundles/+/166840
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.bundles/+/166840 was merged to [R4_15_maintenance]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=570e6ad65f15b79038b220f4230ae15fc724000e
After some community feedback, we believe we need to update the CVE for this as follows: CVE Score Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L/E:P/RL:W/RC:C/CR:X/IR:X/AR:X/MAV:X/MAC:X/MPR:X/MUI:X/MS:X/MC:H/MI:X/MA:X Formal Description: In case of too large response headers, Jetty throws an exception to produce an HTTP 431 error. When this happens, the ByteBuffer containing the HTTP response headers is released back to the ByteBufferPool twice. Because of this double release, two threads can acquire the same ByteBuffer from the pool and while thread1 is about to use the ByteBuffer to write response1 data, thread2 fills the ByteBuffer with other data. Thread1 then proceeds to write the buffer that now contains different data. This results in client1, which issued request1 seeing data from another request or response which could contain sensitive data belonging to client2 (HTTP session ids, authentication credentials, etc.). Work Around: If the Jetty version cannot be upgraded, the vulnerability can be significantly reduced by configuring a responseHeaderSize significantly larger than the requestHeaderSize (12KB responseHeaderSize and 8KB requestHeaderSize).
I've created an update PR. https://github.com/CVEProject/cvelist/pull/4680
