Accepted netty 1:4.1.33-1+deb10u2 (source) into proposed-updates->stable-new, proposed-updates
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Thu, 01 Apr 2021 23:20:46 +0200
Source: netty
Architecture: source
Version: 1:4.1.33-1+deb10u2
Distribution: buster-security
Urgency: high
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Changed-By: Markus Koschany <apo@debian.org>
Changes:
netty (1:4.1.33-1+deb10u2) buster-security; urgency=high
.
* Team upload.
* Fix the following security vulnerabilites:
- CVE-2019-20444:
HttpObjectDecoder.java 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."
- CVE-2019-20445:
HttpObjectDecoder.java allows a Content-Length header to be accompanied
by a second Content-Length header, or by a Transfer-Encoding header.
- CVE-2020-7238:
Netty allows HTTP Request Smuggling because it mishandles
Transfer-Encoding whitespace (such as a [space]Transfer-Encoding:chunked
line) and a later Content-Length header.
- CVE-2020-11612:
The ZlibDecoders allow for unbounded memory allocation while decoding a
ZlibEncoded byte stream. An attacker could send a large ZlibEncoded byte
stream to the Netty server, forcing the server to allocate all of its
free memory to a single decoder.
- CVE-2021-21290:
In Netty 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.
- CVE-2021-21295:
In Netty 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.
- CVE-2021-21409:
In Netty 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.
Checksums-Sha1:
71dd655870d17592ee314977d2741cb538cb3661 2617 netty_4.1.33-1+deb10u2.dsc
dd79ba886e8002734909f12defaf0ae04413264f 26296 netty_4.1.33-1+deb10u2.debian.tar.xz
d8d5adff68da17c1ef395d72997176b3143b3234 14169 netty_4.1.33-1+deb10u2_amd64.buildinfo
Checksums-Sha256:
3286a5c945aef9f5a2a3f366d0b8668ec892df275dcdb55d44392b646a5493f6 2617 netty_4.1.33-1+deb10u2.dsc
b61e365af976a31b4dd23d0c4dc38499f417f113e3e7bcf2e2aa4c535b997ce1 26296 netty_4.1.33-1+deb10u2.debian.tar.xz
bec7ae1de8e7b7c4dfd45d89a96ea580b8d3eeb63439f00965455a4f8e61a179 14169 netty_4.1.33-1+deb10u2_amd64.buildinfo
Files:
ebd4b8b24b3a01ac2c8810b196c33746 2617 java optional netty_4.1.33-1+deb10u2.dsc
bc5841602653ab9d1b02d1b72d6ee5fb 26296 java optional netty_4.1.33-1+deb10u2.debian.tar.xz
383611a1f87ee35fab8a9a2979d3f25f 14169 java optional netty_4.1.33-1+deb10u2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQKjBAEBCgCNFiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAmBnZsNfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD
RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQPHGFwb0BkZWJp
YW4ub3JnAAoJENmtFLlRO1Hk4dUP+gLZAhVvDInz1c0B57cjYag0A42JBr6wHMmn
Z4axGwgF5ajjJKMT7w3xoM8Q54BKdM6OFBKg/gkbdwqKXPxKIzDS+lBp+1RAVgY3
t73A0y6JSwfm7nWnO7FsqL9P6bEh0cycFXMa/pXvtgTo3aq7RUQJ42P06p4yzTNa
h4/fzZFOmRvmt4hbRH5vkqarHf4KABjCUQEttJhEzi31xGL+MF1ahxTZQMvX8fUf
gDvWw1phabF4CEmyzEYscN1NLGK0riRCT0vHMjyoeW4LtXgi0yxhtr94SuBP0ndz
OsnHp1B5Qojpm1N92O1035Qg642sRUx2L3tSBW2ZtPxF1KIJmpE6FWeyhQRAGgQA
LeTyf8iqf7rY4UqKseaH4mt+zvzXAzBMIh6vikHOe8QSkwexqjONM8ZgUltX3b4a
9Xm6VtiIvdTX/a27H6W7+SX37s7xGdNG8FaTeIxh12Hq1moX5++B7DZDbbNl/dY/
19wraik18TyhLTlp0qDnreve9oj5TgJtVBVS9A9YR1rFNwnffzY2CMs+inH2ZtNR
uWQ7aBP0ThPkCQuD3/AoqFdO5gsqon2uSvgzy3K41pkpkaS3y+jVLcaTU5RksIu4
LqpuTRDVTTY+1LRBXL3pL9W3rS9PMmi19DnXEVBr1hxplrc7bRAFZI6bM9vryTA5
KDnR2wKE
=MZfh
-----END PGP SIGNATURE-----