You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Netty is an asynchronous event-driven network application framework for
rapid development of maintainable high performance protocol servers and
clients.
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.
mend-bolt-for-githubbot
changed the title
CVE-2021-21295 (Medium) detected in netty-codec-http-4.1.32.Final.jar
CVE-2021-21295 (Medium) detected in netty-codec-http-4.1.16.Final.jar
Mar 31, 2021
CVE-2021-21295 - Medium Severity Vulnerability
Vulnerable Library - netty-codec-http-4.1.16.Final.jar
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers and clients.
Library home page: http://netty.io/
Path to dependency file: mall/mall-manager-impl/pom.xml
Path to vulnerable library: /home/wss-scanner/.m2/repository/io/netty/netty-codec-http/4.1.16.Final/netty-codec-http-4.1.16.Final.jar
Dependency Hierarchy:
Found in HEAD commit: cc9850c2db6a3193f4c814db229d98d38fce556c
Vulnerability Details
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.) viaHttp2StreamFrameToHttpObjectCodec
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
orHttp2FrameCodec
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 customChannelInboundHandler
that is put in theChannelPipeline
behindHttp2StreamFrameToHttpObjectCodec
.Publish Date: 2021-03-09
URL: CVE-2021-21295
CVSS 3 Score Details (5.9)
Base Score Metrics:
Suggested Fix
Type: Upgrade version
Origin: GHSA-wm47-8v5p-wjpj
Release Date: 2021-03-09
Fix Resolution: io.netty:netty-codec-http:4.1.60
The text was updated successfully, but these errors were encountered: