https://bugzilla.redhat.com/show_bug.cgi?id=1937364
Bug ID: 1937364 Summary: CVE-2021-21295 netty: possible request smuggling in HTTP/2 due missing validation Product: Security Response Hardware: All OS: Linux Status: NEW Component: vulnerability Keywords: Security Severity: medium Priority: medium Assignee: security-response-team@redhat.com Reporter: gsuckevi@redhat.com CC: aboyko@redhat.com, aileenc@redhat.com, akoufoud@redhat.com, akurtako@redhat.com, alazarot@redhat.com, almorale@redhat.com, andjrobins@gmail.com, anstephe@redhat.com, aos-bugs@redhat.com, asoldano@redhat.com, atangrin@redhat.com, ataylor@redhat.com, avibelli@redhat.com, bbaranow@redhat.com, bbuckingham@redhat.com, bcourt@redhat.com, bgeorges@redhat.com, bkearney@redhat.com, bmaxwell@redhat.com, bmontgom@redhat.com, brian.stansberry@redhat.com, btotty@redhat.com, cdewolf@redhat.com, chazlett@redhat.com, clement.escoffier@redhat.com, dandread@redhat.com, darran.lofthouse@redhat.com, dbecker@redhat.com, dbhole@redhat.com, decathorpe@gmail.com, dkreling@redhat.com, dosoudil@redhat.com, drieden@redhat.com, ebaron@redhat.com, eclipse-sig@lists.fedoraproject.org, eleandro@redhat.com, eparis@redhat.com, etirelli@redhat.com, extras-orphan@fedoraproject.org, fjuma@redhat.com, ganandan@redhat.com, ggaughan@redhat.com, gmalinko@redhat.com, gsmet@redhat.com, hamadhan@redhat.com, hhudgeon@redhat.com, ibek@redhat.com, iweiss@redhat.com, janstey@redhat.com, java-sig-commits@lists.fedoraproject.org, jburrell@redhat.com, jcantril@redhat.com, jerboaa@gmail.com, jjohnstn@redhat.com, jjoyce@redhat.com, jochrist@redhat.com, jokerman@redhat.com, jpallich@redhat.com, jperkins@redhat.com, jross@redhat.com, jschluet@redhat.com, jstastny@redhat.com, jwon@redhat.com, kaycoth@redhat.com, krathod@redhat.com, kverlaen@redhat.com, kwills@redhat.com, lef@fedoraproject.org, lgao@redhat.com, lhh@redhat.com, loleary@redhat.com, lpeer@redhat.com, lthon@redhat.com, lzap@redhat.com, mat.booth@redhat.com, mburns@redhat.com, mkolesni@redhat.com, mmccune@redhat.com, mnovotny@redhat.com, msochure@redhat.com, msvehla@redhat.com, mszynkie@redhat.com, nmoumoul@redhat.com, nstielau@redhat.com, nwallace@redhat.com, pcreech@redhat.com, pdrozd@redhat.com, peholase@redhat.com, pgallagh@redhat.com, pjindal@redhat.com, pmackay@redhat.com, probinso@redhat.com, rchan@redhat.com, rgodfrey@redhat.com, rgrunber@redhat.com, rguimara@redhat.com, rjerrido@redhat.com, rrajasek@redhat.com, rruss@redhat.com, rstancel@redhat.com, rsvoboda@redhat.com, rsynek@redhat.com, sbiarozk@redhat.com, sclewis@redhat.com, scohen@redhat.com, sdaley@redhat.com, sd-operator-metering@redhat.com, sdouglas@redhat.com, slinaber@redhat.com, smaestri@redhat.com, sochotni@redhat.com, sokeeffe@redhat.com, spinder@redhat.com, sponnaga@redhat.com, sthorger@redhat.com, swoodman@redhat.com, tbrisker@redhat.com, tflannag@redhat.com, theute@redhat.com, tom.jenkinson@redhat.com, yborgess@redhat.com Target Milestone: --- Classification: Other
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`.
Reference: https://github.com/netty/netty/security/advisories/GHSA-wm47-8v5p-wjpj
Upstream patch: https://github.com/netty/netty/commit/89c241e3b1795ff257af4ad6eadc616cb2fb3d...