[
https://issues.apache.org/jira/browse/SPARK-35132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean R. Owen resolved SPARK-35132.
----------------------------------
Fix Version/s: 3.2.0
Resolution: Fixed
Issue resolved by pull request 32227
[https://github.com/apache/spark/pull/32227]
> Upgrade netty-all to 4.1.63.Final
> ---------------------------------
>
> Key: SPARK-35132
> URL: https://issues.apache.org/jira/browse/SPARK-35132
> Project: Spark
> Issue Type: Improvement
> Components: Build
> Affects Versions: 3.2.0
> Reporter: Yang Jie
> Assignee: Yang Jie
> Priority: Minor
> Fix For: 3.2.0
>
>
> Three CVE problems were found after netty 4.1.51.Final:
>
> ||Name||Description||
> |[CVE-2021-21409|https://cve.mitre.org/cgi-bin/cvename.cgi?name=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.|
> |[CVE-2021-21295|https://cve.mitre.org/cgi-bin/cvename.cgi?name=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`.|
> |[CVE-2021-21290|https://cve.mitre.org/cgi-bin/cvename.cgi?name=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.|
>
> Upgrade netty version to avoid these potential risks
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
