In Eclipse Jetty, versions 9.4.27.v20200227 to 9.4.29.v20200521, in case of too large response headers, Jetty throws an exception to produce
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 9.4.30.v20200611
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- 1 proof of concept on GitHub
Summary
In Eclipse Jetty, versions 9.4.27.v20200227 to 9.4.29.v20200521, 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.). 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).
Timeline
- CVE published
- Record last updated
- EPSS reached 10%
FIRST estimates at least a 10% chance of exploitation in the next 30 days
Affected versions
- The Eclipse Foundation Eclipse Jetty
9.4.27.v20200227 to 9.4.29.v20200521
- org.eclipse.jetty:jetty-serverMaven
From 9.4.27 · fixed in 9.4.30.v20200611
References 18
bugs.eclipse.org
openwall.com
lists.fedoraproject.org
lists.apache.org
- thread.html/r4bdd3f7bb6820a79f9416b6667d718a06d269018619a75ce4b759318@<commits.pulsar.apache.org>
- thread.html/r521168299e023fb075b57afe33d17ff1d09e8a10e0fd8c775ea0e028@<commits.pulsar.apache.org>
- thread.html/r378e4cdec15e132575aa1dcb6296ffeff2a896745a8991522e266ad4@<commits.pulsar.apache.org>
- thread.html/ra8661fc8c69c647cb06153c1485d48484a833d873f75dfe45937e9de@<commits.pulsar.apache.org>
- thread.html/r81f58591fb4716fb867b36956f30c7c8ad4ab3f23abc952d9d86a2a0@<commits.pulsar.apache.org>
- thread.html/r9a2cfa56d30782a0c17a5deb951a622d1f5c8de48e1c3b578ffc2a84@<commits.pulsar.apache.org>
- thread.html/rbe1f230e87ea947593145d0072d0097ddb0af10fee1161db8ca1546c@<commits.pulsar.apache.org>
- thread.html/r29073905dc9139d0d7a146595694bf57bb9e35e5ec6aa73eb9c8443a@<commits.pulsar.apache.org>
- thread.html/r7fc5f2ed49641ea91c433e3cd0fc3d31c0278c87b82b15c33b881415@<commits.pulsar.apache.org>
- thread.html/rd98cfd012490cb02caa1a11aaa0cc38bff2d43bcce9b20c2f01063dd@<commits.pulsar.apache.org>
- thread.html/rd0e44e8ef71eeaaa3cf3d1b8b41eb25894372e2995ec908ce7624d26@<commits.pulsar.apache.org>
- thread.html/r9584c4304c888f651d214341a939bd264ed30c9e3d0d30fe85097ecf@<commits.pulsar.apache.org>