Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2021-21295 (Medium) detected in netty-codec-http2-4.1.52.Final.jar #14

Open
mend-for-github-com bot opened this issue Jan 14, 2022 · 0 comments
Labels
security vulnerability Security vulnerability detected by WhiteSource

Comments

@mend-for-github-com
Copy link

CVE-2021-21295 - Medium Severity Vulnerability

Vulnerable Library - netty-codec-http2-4.1.52.Final.jar

Path to dependency file: /pom.xml

Path to vulnerable library: /home/wss-scanner/.m2/repository/io/netty/netty-codec-http2/4.1.52.Final/netty-codec-http2-4.1.52.Final.jar

Dependency Hierarchy:

  • beam-sdks-java-io-google-cloud-platform-2.32.0.jar (Root Library)
    • grpc-netty-1.37.0.jar
      • netty-codec-http2-4.1.52.Final.jar (Vulnerable Library)

Found in HEAD commit: dd7cd6660b3c3d0de5f379d8294b49e38a94ca65

Found in base branch: master

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.) 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.

Publish Date: 2021-03-09

URL: CVE-2021-21295

CVSS 3 Score Details (5.9)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: High
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: High
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-wm47-8v5p-wjpj

Release Date: 2021-03-09

Fix Resolution: io.netty:netty-all:4.1.60;io.netty:netty-codec-http:4.1.60;io.netty:netty-codec-http2:4.1.60

@mend-for-github-com mend-for-github-com bot added the security vulnerability Security vulnerability detected by WhiteSource label Jan 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security vulnerability Security vulnerability detected by WhiteSource
Projects
None yet
Development

No branches or pull requests

0 participants