reference:
- https://www.jenkins.io/security/advisory/2020-08-17/
- https://github.com/advisories/GHSA-x3rh-m7vp-35f2
- https://github.com/eclipse/jetty.project/issues/4936
- https://nvd.nist.gov/vuln/detail/2019-17638
When starting jenkins like this, the jetty that comes with Jenkins is used:
java -jar jenkins.war
Affected version:
- Jenkins 2.224<= version <= 2.242
- Jenkins LTS 2.222.1 version <= 2.235.4
The built-in Jetty of these versions is Jetty 9.4.27 version. There are loopholes.
Specific Jetty affected versions:
Eclipse Jetty, versions 9.4.27.v20200227- 9.4.29.v20200521
Vulnerability details:
Unauthorized attackers can obtain HTTP response headers from Jenkins to other users.
If the response header is too large, Jetty will raise an exception to generate an HTTP 431 error. When this happens, the ByteBuffer containing the HTTP response header will be released back to the ByteBufferPool twice. Due to this dual release, two threads can obtain the same ByteBuffer from the pool, and when thread 1 will use the ByteBuffer to write response1 data, thread 2 will fill response2 data into the ByteBuffer. Then, thread 1 continues to write to the buffer that now contains response2 data. This causes client1 to send request1 and expect a response, thus seeing that response2 may contain sensitive data belonging to client2 (HTTP session ID, authentication credentials, etc.).
Vulnerability reproduction process:
We managed to reproduce the problem by creating an endpoint in which we will explicitly send a response header larger than the configured maximum size (8KB), after which the application will immediately become unresponsive, and all the above errors Will begin to appear.