Critical Jenkins Server Vulnerability Could Leak Sensitive Information
Ravie Lakshmanan - August 18, 2020
Ravie Lakshmanan - August 18, 2020
[SHOWTOGROUPS=4,20,22]
Для просмотра ссылки Войдиили Зарегистрируйся
Jenkins—a popular open-source automation server software—published an Для просмотра ссылки Войдиили Зарегистрируйся on Monday concerning a critical vulnerability in the Jetty web server that could result in memory corruption and cause confidential information to be disclosed.
Tracked as Для просмотра ссылки Войдиили Зарегистрируйся, the flaw has a CVSS rating of 9.4 and impacts Eclipse Jetty versions 9.4.27.v20200227 to 9.4.29.v20200521—a full-featured tool that provides a Java HTTP server and web container for use in software frameworks.
"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," read the advisory.
"The vulnerability may allow unauthenticated attackers to obtain HTTP response headers that may include sensitive data intended for another user."
The Для просмотра ссылки Войдиили Зарегистрируйся, which impacts Jetty and Jenkins Core, appears to have been introduced in Jetty version 9.4.27, which added a mechanism to handle large HTTP response headers and prevent buffer overflows.
"The issue was in the case of a buffer overflow, we released the header buffer, but did not null the field," Jetty's project head Для просмотра ссылки Войдиили Зарегистрируйся said.
To handle this, Jetty throws an exception to produce an HTTP 431 error, which causes the HTTP response headers to be released to the buffer pool twice, in turn causing memory corruption and information disclosure.
Thus, due to the double release, two threads can acquire the same buffer from the pool at the same time and potentially allow one request to access a response written by the other thread, which may include session identifiers, authentication credentials, and other sensitive information.
Put differently, "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."
In one case, the memory corruption made it possible for clients to move between sessions, thereby having cross-account access, as authentication cookies from one user's response were sent to another user, thereby allowing user A to jump in user B's session.
After the security implications were disclosed, the vulnerability was addressed in Jetty 9.4.30.v20200611 released last month. Jenkins, which bundles Jetty via a command-line interface called Для просмотра ссылки Войдиили Зарегистрируйся, has Для просмотра ссылки Войди или Зарегистрируйся in its utility in Jenkins 2.243 and Jenkins LTS 2.235.5 released yesterday.
It's recommended that Jenkins users update their software to the latest version to mitigate the buffer corruption flaw.
[/SHOWTOGROUPS]
Для просмотра ссылки Войди
Jenkins—a popular open-source automation server software—published an Для просмотра ссылки Войди
Tracked as Для просмотра ссылки Войди
"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," read the advisory.
"The vulnerability may allow unauthenticated attackers to obtain HTTP response headers that may include sensitive data intended for another user."
The Для просмотра ссылки Войди
"The issue was in the case of a buffer overflow, we released the header buffer, but did not null the field," Jetty's project head Для просмотра ссылки Войди
To handle this, Jetty throws an exception to produce an HTTP 431 error, which causes the HTTP response headers to be released to the buffer pool twice, in turn causing memory corruption and information disclosure.
Thus, due to the double release, two threads can acquire the same buffer from the pool at the same time and potentially allow one request to access a response written by the other thread, which may include session identifiers, authentication credentials, and other sensitive information.
Put differently, "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."
In one case, the memory corruption made it possible for clients to move between sessions, thereby having cross-account access, as authentication cookies from one user's response were sent to another user, thereby allowing user A to jump in user B's session.
After the security implications were disclosed, the vulnerability was addressed in Jetty 9.4.30.v20200611 released last month. Jenkins, which bundles Jetty via a command-line interface called Для просмотра ссылки Войди
It's recommended that Jenkins users update their software to the latest version to mitigate the buffer corruption flaw.
[/SHOWTOGROUPS]
