Pierluigi Paganini
August 18, 2020
A critical vulnerability in Jenkins server software, tracked as CVE-2019-17638, could result in memory corruption and cause confidential information disclosure.
Jenkins is the most popular open source automation server, it is maintained by CloudBees and the Jenkins community. The automation server supports developers build, test and deploy their applications, it has hundreds of thousands of active installations worldwide with more than 1 million users.
“Jenkins bundles Winstone-Jetty, a wrapper around Jetty, to act as HTTP and servlet server when started using java -jar jenkins.war. This is how Jenkins is run when using any of the installers or packages, but not when run using servlet containers such as Tomcat,” reads the advisory published by the company.
“Jenkins 2.224 through 2.242 and LTS 2.222.1 through 2.235.4 bundles Jetty 9.4.27 with the security vulnerability CVE-2019-17638. This vulnerability may allow unauthenticated attackers to obtain HTTP response headers that may include sensitive data intended for another user.”
The vulnerability affects Jetty and Jenkins Core, it was introduced in Jetty version 9.4.27 to handle large HTTP response headers and prevent buffer overflows.
“You were right and it was the change from #4541. The issue was in the case of a buffer overflow, we released the header buffer, but did not null the field. We then threw an exception and the onCompleteFailure handling called release on the class, which again released the buffer (since it was not null). Thus the buffer was put into the pool twice and could be taken out by 2 threads and worked on at the same time. The server would have been unstable from that point on!” explained Jetty’s project head Greg Wilkins.
The Jetty throws an exception to produce an HTTP 431 error, which leads to a double release of the HTTP response headers to the buffer pool, resulting in memory corruption and information disclosure.
Experts explained that due to the double release, two threads can access the same buffer at the same time, this means that one request could potentially access a response written by the other thread. This flaw can cause the exposure of sensitive data, including session identifiers and login credentials.
“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.).” reads the bug description.
Jetty 9.4.30.v20200611 addresses the vulnerability, while the Jenkins software has fixed the flaw in Jenkins 2.243 and Jenkins LTS 2.235.5.
Jenkins users are recommended to update their software to the latest version to solve the issue.
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(SecurityAffairs – hacking, Jenkins)
[adrotate banner=”5″]
[adrotate banner=”13″]
