In Eclipse Jetty version 9.4.0.RC0 to 9.4.34.v20201102, 10.0.0.alpha0 to 10.0.0.beta2, and 11.0.0.alpha0 to 11.0.0.beta2, if GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, and if an attacker can send a request with a body that is received entirely but not consumed by the application, then a subsequent request on the same connection will see that body prepended to its body. The attacker will not see any data but may inject data into the body of the subsequent request. References: https://bugs.eclipse.org/bugs/show_bug.cgi?id=568892 https://github.com/eclipse/jetty.project/security/advisories/GHSA-86wm-rrjm-8wh8
Created jetty tracking bugs for this issue: Affects: fedora-all [bug 1902827]
RHSSO doesn't ship Jetty at all, just adapters that can be deployed on top of Jetty.
This vulnerability is out of security support scope for the following products: * Red Hat JBoss Fuse 6 * Red Hat JBoss Fuse Service Works 6 * Red Hat JBoss AMQ 6 Please refer to https://access.redhat.com/support/policy/updates/jboss_notes for more details.
External References: https://github.com/eclipse/jetty.project/security/advisories/GHSA-86wm-rrjm-8wh8
Marking Red Hat Camel K as having a low impact, although Camel K distributes jetty artifacts through camel-jetty, camel-jetty itself is not available for use by the application developer, http functionality is provided by camel-k default runtime, Quarkus.
A word on scoring, our scoring is currently 4.8/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L and NVD score of 3.7/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N My take: Exploitability Metrics: Attack Vector Network (AV:N) - Agree here, Jetty is both a HTTP server and client, in the context of this vulnerability it is the server that is affected, the component is commonly bound to the network stack and also commonly a WAN facing service. Attack Complexity High (AC:H) We agree here, the attack complexity is high because there are elements outside of GzipHandler being enabled there are other factors outside the attackers control, these factors are *) The end application doesn't contain any logic to handle connection closure *) The end application doesn't fully consume a gzipped POST request *) There is an element of chance as to if the recycled buffer will be used in such a way to allow an attack, for example differences in network speed, OS buffers and dispatching threads will all have a varying impact, meaning this attack will need to be tailored to each specific target by the attacker Privileges Required None (PR:N) - Agree here, the attacker does not need to be a privileged user eg. no login required to exploit the base flaw. User Interaction None (UI:N) Agree here, a end user does not need to be coerced into performing any action for this flaw. Scope Unchanged (S:U) Agree here, the attacker will not be able to escape the scope of the executing JVM solely due to this flaw Impact Metrics: Confidentiality None (C:N) Agree here, this is a blind attack and relies on a POST request, there is no information the attacker can divulge Integrity Low (I:L) We agree here, if the attacker is able to overcome the attack complexity and predictably exploit the buffer then the contents of other POST requests can be altered meaning data modification is taking place, but given the complexities of the attack the attacker does not have control over the consequences of the modification. Availability Low (A:N -> A:L) We disagree here with the original scoring of None for availability, the attack if successful will in many situations cause an exception when two request bodies are combined, depending on end application handling of these exceptions this could mean interruption to other users of the http service.
This issue has been addressed in the following products: Red Hat AMQ LTS 7.4.6 Via RHSA-2021:0329 https://access.redhat.com/errata/RHSA-2021:0329
This issue has been addressed in the following products: Red Hat AMQ 7.8.1 Via RHSA-2021:0417 https://access.redhat.com/errata/RHSA-2021:0417
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-27218
Statement: In OpenShift Container Platform (OCP), the Hive/Presto/Hadoop components that comprise the OCP Metering stack, ship the vulnerable version of jetty. Since the release of OCP 4.6, the Metering product has been deprecated [1], hence the affected components are marked as wontfix. This may be fixed in the future. [1] https://docs.openshift.com/container-platform/4.6/release_notes/ocp-4-6-release-notes.html#ocp-4-6-metering-operator-deprecated
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.6 Via RHSA-2021:2499 https://access.redhat.com/errata/RHSA-2021:2499
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 3.11 Via RHSA-2021:2517 https://access.redhat.com/errata/RHSA-2021:2517
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.5 Via RHSA-2021:2431 https://access.redhat.com/errata/RHSA-2021:2431
This issue has been addressed in the following products: Red Hat Integration Via RHSA-2021:4767 https://access.redhat.com/errata/RHSA-2021:4767
This issue has been addressed in the following products: Red Hat Fuse 7.10 Via RHSA-2021:5134 https://access.redhat.com/errata/RHSA-2021:5134
This issue has been addressed in the following products: RHINT Camel-K 1.6.4 Via RHSA-2022:1029 https://access.redhat.com/errata/RHSA-2022:1029