In Eclipse Jetty 9.4.6.v20170531 to 9.4.36.v20210114 (inclusive), 10.0.0, and 11.0.0 when Jetty handles a request containing multiple Accept headers with a large number of “quality” (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values. References: https://bugs.eclipse.org/bugs/show_bug.cgi?id=571128 https://github.com/eclipse/jetty.project/security/advisories/GHSA-m394-8rww-3jr7
Created jetty tracking bugs for this issue: Affects: fedora-all [bug 1934117]
Fixing commit: https://github.com/eclipse/jetty.project/commit/10e531756b972162eed402c44d0244f7f6b85131 Commit (fix) contained in: jetty-10.0.1, jetty-11.0.1, jetty-9.4.37.v20210219, jetty-9.4.38.v20210224
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.
This vulnerability is out of security support scope for the following products: * Red Hat JBoss Fuse 6 * Red Hat JBoss A-MQ 6 * Red Hat JBoss Fuse Service Works 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-m394-8rww-3jr7
A word on scoring, our scoring is currently 5.3/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L and NVD of 7.5/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H will change to 5.3/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L 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 Low (AC:L) Agree here, the attack complexity is low, although there is the complexity of application configuration making this attack less viable and should only expose the user when using one of the below features, we consider this configuration which we assume is in place for the purposes of the base score * Using the default error page/handler * Exposing StatisticsServlet to network traffic * Application using getLocale API * pre-compressed static content in the DefaultServlet is enabled 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 user does not need to be coerced into performing any action for this flaw, an attacker can expect to be successful if the jetty service is configured with any of the prerequisite mentioned in the AC section 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, there is no loss of confidentiality within the impacted component and nothing is disclosed to the attacker through this attack Integrity None (I:N) Agree here, there is no loss of integrity within the impacted component and no data is altered by the attacker Availability High (A:H) -> Availability Low (A:L) We disagree here, although this is a DoS attack there is not a total, sustained or serious loss of availability in all circumstances, all requests will continue to be handled but the CPU usage will increase, this may result in reduced performance or some interruptions in resource availability but the attacker doesn't have the ability to deny all resources to legitimate users at will.
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 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-27223
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 AMQ 7.8.2 Via RHSA-2021:2689 https://access.redhat.com/errata/RHSA-2021:2689
This issue has been addressed in the following products: Red Hat AMQ 7.9.0 Via RHSA-2021:3700 https://access.redhat.com/errata/RHSA-2021:3700
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: RHAF Camel-K 1.8 Via RHSA-2022:6407 https://access.redhat.com/errata/RHSA-2022:6407