CVE-2021-21295

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by Http2MultiplexHandler as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (HttpRequest, HttpContent, etc.) via Http2StreamFrameToHttpObjectCodec and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: HTTP2MultiplexCodec or Http2FrameCodec is used, Http2StreamFrameToHttpObjectCodec is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom ChannelInboundHandler that is put in the ChannelPipeline behind Http2StreamFrameToHttpObjectCodec.

Impact

If a Content-Length header is present in the original HTTP/2 request, the field is not validated by Http2MultiplexHandler as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (HttpRequest, HttpContent, etc.) via Http2StreamFrameToHttpObjectCodec and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.

In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked.

An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. A sample attack request looks like:

POST / HTTP/2
:authority:: externaldomain.com
Content-Length: 4

asdfGET /evilRedirect HTTP/1.1
Host: internaldomain.com

Users are only affected if all of this is true:

• HTTP2MultiplexCodec or Http2FrameCodec is used
• Http2StreamFrameToHttpObjectCodec is used to convert to HTTP/1.1 objects
• These HTTP/1.1 objects are forwarded to another remote peer.

Patches

This has been patched in 4.1.60.Final

Workarounds

The user can do the validation by themselves by implementing a custom ChannelInboundHandler that is put in the ChannelPipeline behind Http2StreamFrameToHttpObjectCodec.

References

Related change to workaround the problem: https://github.com/Netflix/zuul/pull/980

A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack.

Impact

This is a DDOS attack, any http2 server is affected and so you should update as soon as possible.

Patches

This is patched in version 4.1.100.Final.

Workarounds

A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own Http2FrameListener implementation or an ChannelInboundHandler implementation (depending which http2 API is used).

References

• https://www.cve.org/CVERecord?id=CVE-2023-44487
• https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. %package help Summary: Documents for %{name} Buildarch: noarch Requires: man info Provides: %{name}-javadoc = %{version}-%{release} Obsoletes: %{name}-javadoc < %{version}-%{release} %description help Man pages and other related documents for %{name}.

Security Fix(es):

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by Http2MultiplexHandler as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (HttpRequest, HttpContent, etc.) via Http2StreamFrameToHttpObjectCodec and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is True: HTTP2MultiplexCodec or Http2FrameCodec is used, Http2StreamFrameToHttpObjectCodec is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom ChannelInboundHandler that is put in the ChannelPipeline behind Http2StreamFrameToHttpObjectCodec.(CVE-2021-21295)

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.61.Final there is a vulnerability that enables request smuggling. The content-length header is not correctly validated if the request only uses a single Http2HeaderFrame with the endStream set to to True. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1. This is a followup of GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which did miss to fix this one case. This was fixed as part of 4.1.61.Final.(CVE-2021-21409)

Root has patched GHSA-xpw8-rcwv-8f8p in the io.root.io.netty:netty-codec-http2 package for Root:Maven. Multiple fixed versions available.

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by Http2MultiplexHandler as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (HttpRequest, HttpContent, etc.) via Http2StreamFrameToHttpObjectCodec and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: HTTP2MultiplexCodec or Http2FrameCodec is used, Http2StreamFrameToHttpObjectCodec is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom ChannelInboundHandler that is put in the ChannelPipeline behind Http2StreamFrameToHttpObjectCodec.

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by Http2MultiplexHandler as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (HttpRequest, HttpContent, etc.) via Http2StreamFrameToHttpObjectCodec and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: HTTP2MultiplexCodec or Http2FrameCodec is used, Http2StreamFrameToHttpObjectCodec is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom ChannelInboundHandler that is put in the ChannelPipeline behind Http2StreamFrameToHttpObjectCodec.

TuxCare rebuilt 40 io.netty packages to address 16 CVEs. Fixed in 4.1.52.Final-tuxcare.1.

TuxCare rebuilt 6 io.netty packages to address 9 CVEs. Fixed in 4.1.58.Final-tuxcare.1.

TuxCare rebuilt 5 io.netty packages to address 9 CVEs. Fixed in 4.1.48.Final-tuxcare.4.

TuxCare rebuilt 40 io.netty packages to address 26 CVEs. Fixed in 4.1.53.Final-tuxcare.1.

TuxCare rebuilt 6 io.netty packages to address 11 CVEs. Fixed in 4.1.39.Final-tuxcare.1.

TuxCare rebuilt 11 io.netty packages to address 21 CVEs. Fixed in 4.1.51.Final-tuxcare.1.

TuxCare rebuilt 8 io.netty packages to address 11 CVEs. Fixed in 4.1.43.Final-tuxcare.3.

TuxCare rebuilt 10 io.netty packages to address 17 CVEs. Fixed in 4.1.49.Final-tuxcare.6.

TuxCare rebuilt 5 io.netty packages to address 11 CVEs. Fixed in 4.1.42.Final-tuxcare.4.

TuxCare rebuilt 7 io.netty packages to address 16 CVEs. Fixed in 4.1.38.Final-tuxcare.2.

TuxCare rebuilt 7 io.netty packages to address 8 CVEs. Fixed in 4.1.24.Final-tuxcare.3.

TuxCare rebuilt 7 io.netty packages to address 9 CVEs. Fixed in 4.1.23.Final-tuxcare.3.

TuxCare rebuilt 4 io.netty packages to address 5 CVEs. Fixed in 4.1.21.Final-tuxcare.4.

TuxCare rebuilt 4 io.netty packages to address 4 CVEs. Fixed in 4.1.29.Final-tuxcare.5.

In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by Http2MultiplexHandler as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (HttpRequest, HttpContent, etc.) via Http2StreamFrameToHttpObjectCodec and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content- Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: HTTP2MultiplexCodec or Http2FrameCodec is used, Http2StreamFrameToHttpObjectCodec is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom ChannelInboundHandler that is put in the ChannelPipeline behind Http2StreamFrameToHttpObjectCodec (CVE-2021-21295).

In Netty (io.netty:netty-codec-http2) before version 4.1.61.Final there is a vulnerability that enables request smuggling. The content-length header is not correctly validated if the request only uses a single Http2HeaderFrame with the endStream set to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1. This is a followup of GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which did miss to fix this one case. This was fixed as part of 4.1.61.Final (CVE-2021-21409).

This update for netty fixes the following issues:

• CVE-2021-21295: Fixed an improper Content-Length header field validation (bsc#1183262). :

This update was imported from the SUSE:SLE-15-SP2:Update update project.

These are all security issues fixed in the netty-4.1.60-1.4 package on the GA media of openSUSE Tumbleweed.

Rocky Enterprise Software Foundation Satellite is a systems management tool for Linux-based infrastructure. It allows for provisioning, remote management, and monitoring of multiple Linux deployments with a single centralized tool.

Security Fix(es):

• libsolv: Heap-based buffer overflow in testcase_read() in src/testcase.c (CVE-2021-3200)
• satellite: foreman: Authenticate remote code execution through Sendmail configuration (CVE-2021-3584)
• candlepin: Allow unintended SCA certificate to authenticate Candlepin (CVE-2021-4142)
• candlepin: netty: Information disclosure via the local system temporary directory (CVE-2021-21290)
• candlepin: netty: Possible request smuggling in HTTP/2 due missing validation (CVE-2021-21295)
• candlepin: netty: Request smuggling via content-length header (CVE-2021-21409)
• tfm-rubygem-sidekiq: XSS via the queue name of the live-poll feature (CVE-2021-30151)
• python-sqlparse: ReDoS via regular expression in StripComments filter (CVE-2021-32839)
• libsolv: various flaws (CVE-2021-33928 CVE-2021-33929 CVE-2021-33930 CVE-2021-33938)
• tfm-rubygem-puma: Inconsistent Interpretation of HTTP Requests in puma (CVE-2021-41136)
• logback-classic: Remote code execution through JNDI call from within its configuration file (CVE-2021-42550)
• candlepin: netty: Control chars in header names may lead to HTTP request smuggling (CVE-2021-43797)
• python-lxml: HTML Cleaner allows crafted and SVG embedded scripts to pass through (CVE-2021-43818)
• python3-django: Potential bypass of an upstream access control based on URL paths (CVE-2021-44420)
• libsolv: Heap overflow (CVE-2021-44568)
• python3-django: Various flaws (CVE-2021-45115 CVE-2021-45116 CVE-2021-45452 CVE-2022-22818)
• tfm-rubygem-actionpack: Information leak between requests (CVE-2022-23633)
• tfm-rubygem-puma: rubygem-rails: Information leak between requests (CVE-2022-23634)
• python3-django: Denial-of-service possibility in file uploads (CVE-2022-23833)
• tfm-rubygem-sidekiq: WebUI Denial of Service caused by number of days on graph (CVE-2022-23837)
• python3-django: Various flaws (CVE-2022-28346 CVE-2022-28347)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Additional Changes:

• New repo layout for Satellite, Utils, Maintenance, and Client repos.
• Support for Rocky Linux 9 clients
• Module-based installation on Rocky Linux 8
• Upgrading Satellite Server and Capsule Server installations from Rocky Linux 7 to Rocky Linux 8
• Connected and Disconnected servers supported on Rocky Linux 7 and Rocky Linux 8
• Inter-Server Synchronization improvements
• Puppet integration optional and disabled by default
• Pulp 3 updated to Python 3.8
• Change to Capsule certificate archive
• New default port for communication with Rocky Enterprise Software Foundation Subscription Management * (RHSM) API on Capsule servers
• New Content Views Page (Content Publication workflow simplification)
• New Hosts Page (Technology Preview)
• Registration and preview templates
• Simplified host content source changing
• Improved behavior for configuring and running remote jobs
• Provisioning improvements
• New error signaling unsupported options in TASK-Filter
• Virt-who configuration enhanced to support Nutanix AHV
• Cloud Connector configuration updated
• Improved Insights adoption

The items above are not a complete list of changes. This update also fixes several bugs and adds various enhancements. Documentation for these changes is available from the Release Notes document linked to in the References section.

This update for netty fixes the following issues:

• Updated to version 4.1.75:
  • CVE-2021-37136: Fixed an unrestricted decompressed data size in Bzip2Decoder (bsc#1190610).
  • CVE-2021-37137: Fixed an unrestricted chunk length in SnappyFrameDecoder, which might lead to excessive memory usage (#bsc#1190613).
  • CVE-2021-43797: Fixed a potential HTTP request smuggling issue due to insufficient validation against control characters (bsc#1193672).
  • CVE-2021-21290: Fixed an information disclosure via the local system temporary directory (bsc#1182103).

It was discovered that Netty's Zlib decoders did not limit memory allocations. A remote attacker could possibly use this issue to cause Netty to exhaust memory via malicious input, leading to a denial of service. This issue only affected Ubuntu 16.04 ESM and Ubuntu 20.04 ESM. (CVE-2020-11612)

It was discovered that Netty created temporary files with excessive permissions. A local attacker could possibly use this issue to expose sensitive information. This issue only affected Ubuntu 16.04 ESM, Ubuntu 18.04 ESM, and Ubuntu 20.04 ESM. (CVE-2021-21290)

It was discovered that Netty did not properly validate content-length headers. A remote attacker could possibly use this issue to smuggle requests. This issue was only fixed in Ubuntu 20.04 ESM. (CVE-2021-21295, CVE-2021-21409)

It was discovered that Netty's Bzip2 decompression decoder did not limit the decompressed output data size. A remote attacker could possibly use this issue to cause Netty to exhaust memory via malicious input, leading to a denial of service. This issue only affected Ubuntu 18.04 ESM, Ubuntu 20.04 ESM, Ubuntu 22.04 LTS, and Ubuntu 22.10. (CVE-2021-37136)

It was discovered that Netty's Snappy frame decoder function did not limit chunk lengths. A remote attacker could possibly use this issue to cause Netty to exhaust memory via malicious input, leading to a denial of service. (CVE-2021-37137)

It was discovered that Netty did not properly handle control chars at the beginning and end of header names. A remote attacker could possibly use this issue to smuggle requests. This issue only affected Ubuntu 18.04 ESM, Ubuntu 20.04 ESM, Ubuntu 22.04 LTS, and Ubuntu 22.10. (CVE-2021-43797)

It was discovered that Netty could be made into an infinite recursion when parsing a malformed crafted message. A remote attacker could possibly use this issue to cause Netty to crash, leading to a denial of service. This issue only affected Ubuntu 20.04 ESM, Ubuntu 22.04 LTS, and Ubuntu 22.10. (CVE-2022-41881)

It was discovered that Netty did not validate header values under certain circumstances. A remote attacker could possibly use this issue to perform HTTP response splitting via malicious header values. This issue only affected Ubuntu 18.04 ESM, Ubuntu 20.04 ESM, Ubuntu 22.04 LTS, and Ubuntu 22.10. (CVE-2022-41915)