[
https://issues.apache.org/jira/browse/TEZ-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
D M Murali Krishna Reddy updated TEZ-4354:
------------------------------------------
Attachment: TEZ-4354.001.patch
> Update netty to 4.1.61.Final
> ----------------------------
>
> Key: TEZ-4354
> URL: https://issues.apache.org/jira/browse/TEZ-4354
> Project: Apache Tez
> Issue Type: Improvement
> Reporter: D M Murali Krishna Reddy
> Priority: Major
> Attachments: TEZ-4354.001.patch
>
>
> [https://nvd.nist.gov/vuln/detail/CVE-2019-16869]
> Netty before 4.1.42.Final mishandles whitespace before the colon in HTTP
> headers (such as a "Transfer-Encoding : chunked" line), which leads to HTTP
> request smuggling.
>
> [https://nvd.nist.gov/vuln/detail/CVE-2019-20444]
> HttpObjectDecoder.java in Netty before 4.1.44 allows an HTTP header that
> lacks a colon, which might be interpreted as a separate header with an
> incorrect syntax, or might be interpreted as an "invalid fold."
>
> [https://nvd.nist.gov/vuln/detail/CVE-2019-20445]
> HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length header
> to be accompanied by a second Content-Length header, or by a
> Transfer-Encoding header.
>
> [https://nvd.nist.gov/vuln/detail/CVE-2021-21290]
> 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.
>
> [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`.
>
> [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.
>
>
> There are a couple of critical vulnerabilities in the current netty version
> which is being used. It is better to upgrade netty from 4.0.52.Final to
> 4.1.61.Final
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
