[
https://issues.apache.org/jira/browse/TINKERPOP-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318204#comment-17318204
]
Aaron Coady commented on TINKERPOP-2535:
----------------------------------------
Updated Twistlock security scans have flagged two more issues with io.netty.
This one is identified as being fixed in 4.1.61:
[https://nvd.nist.gov/vuln/detail/CVE-2021-21409
]
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.
This one is identified as being fixed in 4.1.60:
[https://nvd.nist.gov/vuln/detail/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`.
> Netty 4.1.52 flagged as medium security violation
> -------------------------------------------------
>
> Key: TINKERPOP-2535
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2535
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
> Affects Versions: 3.4.10
> Reporter: Dan Snoddy
> Assignee: Stephen Mallette
> Priority: Major
> Fix For: 3.5.0, 3.4.11
>
>
> Security scan software (twistlock) flags netty-all-4.1.52.Final.jar as a
> medium security violation:
> MEDIUM:
> {color:#000000}Attack complexity: low,Has fix,Medium severity,Recent
> vulnerability
> {color}{color:#000000}CVE-2021-21290{color}
> {color:#000000}[+https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-21290+]{color}
> {color:#000000}Netty is an open-source, asynchronous event-driven network
> application framework for rapid development of maintainable high performance
> protocol servers & clients. In Netty before version 4.1.59.Final there is a
> vulnerability on Unix-like systems involving an insecure temp file. When
> netty\'s multipart decoders are used local information disclosure can occur
> via the local system temporary directory if temporary storing uploads on the
> disk is enabled. On unix-like systems, the temporary directory is shared
> between all user. As such, writing to this directory using APIs that do not
> explicitly set the file/directory permissions can lead to information
> disclosure. Of note, this does not impact modern MacOS Operating Systems. The
> method 'File.createTempFile' on unix-like systems creates a random file, but,
> by default will create this file with the permissions '-rw-r--r--'. Thus, if
> sensitive information is written to this file, other local users can read
> this information. This is the case in netty\'s 'AbstractDiskHttpData' is
> vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one
> may specify your own 'java.io.tmpdir' when you start the JVM or use
> 'DefaultHttpDataFactory.setBaseDir(...)' to set the directory to something
> that is only readable by the current user.{color}
> {color:#000000} {color}
> The scan report shows that the issue is addressed in version 4.1.59. Is there
> a plan to upgrade it?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
