Description
Jesse McConnell
2020-07-06 13:05:56 EDT
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 |