开源软件构建与测试

Changes of Revision 3

_service:tar_scm:netty3.spec Changed

@@ -5,13 +5,18 @@
 
 Name:           netty3
 Version:        3.10.6
-Release:        6
+Release:        8
 Summary:        An asynchronous event-driven network application framework and tools for Java
 License:        ASL 2.0 and BSD and CC0
 URL:            http://netty.io/
 Source0:        https://github.com/netty/netty/archive/netty-%{name_ver}.tar.gz
 Patch0:         disableNPN.patch
 Patch1:         netty-3.10.6-port-to-jzlib-1.1.0.patch
+# Origin: https://launchpadlibrarian.net/497549180/netty-3.9_3.9.9.Final-1_3.9.9.Final-1+deb9u1build0.18.04.1.diff.gz
+Patch2:         CVE-2019-16869.patch
+Patch3:         CVE-2019-20444.patch
+Patch4:         CVE-2019-20445-1.patch
+Patch5:         CVE-2019-20445-2.patch
 
 BuildRequires:  maven-local
 BuildRequires:  mvn(org.sonatype.oss:oss-parent:pom:)
@@ -59,7 +64,7 @@
 
 
 %prep
-%setup -q -n netty-netty-%{name_ver}
+%autosetup -n netty-netty-%{name_ver} -p1
 
 rm -rf jar doc license
 
@@ -94,8 +99,6 @@
 sed -i s/org.jboss.netty.util.internal.jzlib/com.jcraft.jzlib/ \
     `find %{netty_handler_dir}/codec -name \*.java | sort -u`
 
-%patch0 -p1
-%patch1 -p1
 
 rm -v %{netty_handler_dir}/ssl/JettyNpnSslEngine.java
 
@@ -116,5 +119,11 @@
 
 
 %changelog
+* Wed Aug 28 2024 wangkai <13474090681@163.com> - 3.10.6-8
+- Fix CVE-2019-16869,CVE-2019-20444,CVE-2019-20445
+
+* Mon Feb 21 2022 wangkai <wangkai385@huawei.com> - 3.10.6-7
+- Rebuild for fix log4j1.x cves
+
 * Sat Dec 7 2019 huyan <hu.huyan@huawei.com> - 3.10.6-6
-- Package Initialization
\ No newline at end of file
+- Package Initialization

_service:tar_scm:CVE-2019-16869.patch Added

@@ -0,0 +1,60 @@
+From 39cafcb05c99f2aa9fce7e6597664c9ed6a63a95 Mon Sep 17 00:00:00 2001
+From: Norman Maurer <norman_maurer@apple.com>
+Date: Fri, 20 Sep 2019 21:02:11 +0200
+Subject: PATCH Correctly handle whitespaces in HTTP header names as defined
+ by RFC7230#section-3.2.4 (#9585)
+
+Motivation:
+
+When parsing HTTP headers special care needs to be taken when a whitespace is detected in the header name.
+
+Modifications:
+
+- Ignore whitespace when decoding response (just like before)
+- Throw exception when whitespace is detected during parsing
+- Add unit tests
+
+Result:
+
+Fixes https://github.com/netty/netty/issues/9571
+---
+ .../handler/codec/http/HttpObjectDecoder.java    | 16 +++++++++++++++-
+ .../codec/http/HttpRequestDecoderTest.java       | 14 ++++++++++++++
+ .../codec/http/HttpResponseDecoderTest.java      | 15 +++++++++++++++
+ 3 files changed, 44 insertions(+), 1 deletion(-)
+
+--- a/src/main/java/org/jboss/netty/handler/codec/http/HttpMessageDecoder.java
++++ b/src/main/java/org/jboss/netty/handler/codec/http/HttpMessageDecoder.java
+@@ -700,7 +700,7 @@
+                 cStart < cEnd? sb.substring(cStart, cEnd) : "" };
+     }
+ 
+-    private static String splitHeader(String sb) {
++    private String splitHeader(String sb) {
+         final int length = sb.length();
+         int nameStart;
+         int nameEnd;
+@@ -711,7 +711,21 @@
+         nameStart = findNonWhitespace(sb, 0);
+         for (nameEnd = nameStart; nameEnd < length; nameEnd ++) {
+             char ch = sb.charAt(nameEnd);
+-            if (ch == ':' || Character.isWhitespace(ch)) {
++            // https://tools.ietf.org/html/rfc7230#section-3.2.4
++            //
++            // No whitespace is allowed between the header field-name and colon. In
++            // the past, differences in the handling of such whitespace have led to
++            // security vulnerabilities in request routing and response handling. A
++            // server MUST reject any received request message that contains
++            // whitespace between a header field-name and colon with a response code
++            // of 400 (Bad Request). A proxy MUST remove any such whitespace from a
++            // response message before forwarding the message downstream.
++            if (ch == ':' ||
++                    // In case of decoding a request we will just continue processing and header validation
++                    // is done in the DefaultHttpHeaders implementation.
++                    //
++                    // In the case of decoding a response we will "skip" the whitespace.
++                    (!isDecodingRequest() && Character.isWhitespace(ch))) {
+                 break;
+             }
+         }
+

_service:tar_scm:CVE-2019-20444.patch Added

@@ -0,0 +1,38 @@
+From a7c18d44b46e02dadfe3da225a06e5091f5f328e Mon Sep 17 00:00:00 2001
+From: Norman Maurer <norman_maurer@apple.com>
+Date: Wed, 11 Dec 2019 15:49:07 +0100
+Subject: PATCH Detect missing colon when parsing http headers with no value
+ (#9871)
+
+Motivation:
+
+Technical speaking its valid to have http headers with no values so we should support it. That said we need to detect if these are "generated" because of an "invalid" fold.
+
+Modifications:
+
+- Detect if a colon is missing when parsing headers.
+- Add unit test
+
+Result:
+
+Fixes https://github.com/netty/netty/issues/9866
+---
+ .../handler/codec/http/HttpObjectDecoder.java    |  5 +++++
+ .../codec/http/HttpRequestDecoderTest.java       | 16 ++++++++++++++++
+ 2 files changed, 21 insertions(+)
+
+--- a/src/main/java/org/jboss/netty/handler/codec/http/HttpMessageDecoder.java
++++ b/src/main/java/org/jboss/netty/handler/codec/http/HttpMessageDecoder.java
+@@ -731,6 +731,11 @@
+             }
+         }
+ 
++        if (nameEnd == length) {
++            // There was no colon present at all.
++            throw new IllegalArgumentException("No colon found");
++        }
++
+         for (colonEnd = nameEnd; colonEnd < length; colonEnd ++) {
+             if (sb.charAt(colonEnd) == ':') {
+                 colonEnd ++;
+

_service:tar_scm:CVE-2019-20445-1.patch Added

@@ -0,0 +1,95 @@
+From 8494b046ec7e4f28dbd44bc699cc4c4c92251729 Mon Sep 17 00:00:00 2001
+From: Norman Maurer <norman_maurer@apple.com>
+Date: Fri, 13 Dec 2019 08:53:19 +0100
+Subject: PATCH Verify we do not receive multiple content-length headers or a
+ content-length and transfer-encoding: chunked header when using HTTP/1.1
+ (#9865)
+
+Motivation:
+
+RFC7230 states that we should not accept multiple content-length headers and also should not accept a content-length header in combination with transfer-encoding: chunked
+
+Modifications:
+
+- Check for multiple content-length headers and if found mark message as invalid
+- Check if we found a content-length header and also a transfer-encoding: chunked and if so mark the message as invalid
+- Add unit test
+
+Result:
+
+Fixes https://github.com/netty/netty/issues/9861
+---
+ .../handler/codec/http/HttpObjectDecoder.java | 50 +++++++++++++--
+ .../codec/http/HttpRequestDecoderTest.java    | 64 ++++++++++++++++---
+ 2 files changed, 99 insertions(+), 15 deletions(-)
+
+--- a/src/main/java/org/jboss/netty/handler/codec/http/HttpMessageDecoder.java
++++ b/src/main/java/org/jboss/netty/handler/codec/http/HttpMessageDecoder.java
+@@ -537,10 +537,30 @@
+             }
+         }
+ 
+-        State nextState;
++        List<String> values = message.headers().getAll(HttpHeaders.Names.CONTENT_LENGTH);
++        int contentLengthValuesCount = values.size();
++
++        if (contentLengthValuesCount > 0) {
++            // Guard against multiple Content-Length headers as stated in
++            // https://tools.ietf.org/html/rfc7230#section-3.3.2:
++            //
++            // If a message is received that has multiple Content-Length header
++            //   fields with field-values consisting of the same decimal value, or a
++            //   single Content-Length header field with a field value containing a
++            //   list of identical decimal values (e.g., "Content-Length: 42, 42"),
++            //   indicating that duplicate Content-Length header fields have been
++            //   generated or combined by an upstream message processor, then the
++            //   recipient MUST either reject the message as invalid or replace the
++            //   duplicated field-values with a single valid Content-Length field
++            //   containing that decimal value prior to determining the message body
++            //   length or forwarding the message.
++            if (contentLengthValuesCount > 1 && message.getProtocolVersion() == HttpVersion.HTTP_1_1) {
++                throw new IllegalArgumentException("Multiple Content-Length headers found");
++            }
++        }
+ 
+         if (isContentAlwaysEmpty(message)) {
+-            nextState = State.SKIP_CONTROL_CHARS;
++            return State.SKIP_CONTROL_CHARS;
+         } else if (message.isChunked()) {
+             // HttpMessage.isChunked() returns true when either:
+             // 1) HttpMessage.setChunked(true) was called or
+@@ -548,13 +568,29 @@
+             // Because this decoder did not call HttpMessage.setChunked(true)
+             // yet, HttpMessage.isChunked() should return true only when
+             // 'Transfer-Encoding' is 'chunked'.
+-            nextState = State.READ_CHUNK_SIZE;
++            // See https://tools.ietf.org/html/rfc7230#section-3.3.3
++            //
++            //       If a message is received with both a Transfer-Encoding and a
++            //       Content-Length header field, the Transfer-Encoding overrides the
++            //       Content-Length.  Such a message might indicate an attempt to
++            //       perform request smuggling (Section 9.5) or response splitting
++            //       (Section 9.4) and ought to be handled as an error.  A sender MUST
++            //       remove the received Content-Length field prior to forwarding such
++            //       a message downstream.
++            //
++            // This is also what http_parser does:
++            // https://github.com/nodejs/http-parser/blob/v2.9.2/http_parser.c#L1769
++            if (contentLengthValuesCount > 0 && message.getProtocolVersion() == HttpVersion.HTTP_1_1) {
++                throw new IllegalArgumentException(
++                        "Both 'Content-Length: " + contentLength + "' and 'Transfer-Encoding: chunked' found");
++            }
++
++            return State.READ_CHUNK_SIZE;
+         } else if (HttpHeaders.getContentLength(message, -1) >= 0) {
+-            nextState = State.READ_FIXED_LENGTH_CONTENT;
++            return State.READ_FIXED_LENGTH_CONTENT;
+         } else {
+-            nextState = State.READ_VARIABLE_LENGTH_CONTENT;
++            return State.READ_VARIABLE_LENGTH_CONTENT;
+         }
+-        return nextState;
+     }
+ 
+     private HttpChunkTrailer readTrailingHeaders(ChannelBuffer buffer) throws TooLongFrameException {
+

_service:tar_scm:CVE-2019-20445-2.patch Added

@@ -0,0 +1,104 @@
+From 629034624626b722128e0fcc6b3ec9d406cb3706 Mon Sep 17 00:00:00 2001
+From: Bennett Lynch <bennett.lynch@gmail.com>
+Date: Mon, 10 Feb 2020 01:41:57 -0800
+Subject: PATCH =?UTF-8?q?Remove=20"Content-Length"=20when=20decoding=20H?=
+ =?UTF-8?q?TTP/1.1=20message=20with=20both=20"Tra=E2=80=A6=20(#10003)?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Motivation
+
+As part of a recent commit for issue
+https://github.com/netty/netty/issues/9861 the HttpObjectDecoder was
+changed to throw an IllegalArgumentException (and produce a failed
+decoder result) when decoding a message with both "Transfer-Encoding:
+chunked" and "Content-Length".
+
+While it seems correct for Netty to try to sanitize these types of
+messages, the spec explicitly mentions that the Content-Length header
+should be *removed* in this scenario.
+
+Both Nginx 1.15.9 and Tomcat 9.0.31 also opt to remove the header:
+https://github.com/apache/tomcat/blob/b693d7c1981fa7f51e58bc8c8e72e3fe80b7b773/java/org/apache/coyote/http11/Http11Processor.java#L747-L755
+https://github.com/nginx/nginx/blob/0ad4393e30c119d250415cb769e3d8bc8dce5186/src/http/ngx_http_request.c#L1946-L1953
+
+Modifications
+
+* Change the default behavior from throwing an IllegalArgumentException
+to removing the "Content-Length" header
+* Extract the behavior to a new protected method,
+handleChunkedEncodingWithContentLength(), that can be overridden to
+change this behavior (or capture metrics)
+
+Result
+
+Messages of this nature will now be successfully decoded and have their
+"Content-Length" header removed, rather than creating invalid messages
+(decoder result failures). Users will be allowed to override and
+configure this behavior.
+---
+ .../handler/codec/http/HttpObjectDecoder.java | 42 ++++++++++++-------
+ .../codec/http/HttpRequestDecoderTest.java    | 10 ++++-
+ 2 files changed, 36 insertions(+), 16 deletions(-)
+
+--- a/src/main/java/org/jboss/netty/handler/codec/http/HttpMessageDecoder.java
++++ b/src/main/java/org/jboss/netty/handler/codec/http/HttpMessageDecoder.java
+@@ -568,23 +568,9 @@
+             // Because this decoder did not call HttpMessage.setChunked(true)
+             // yet, HttpMessage.isChunked() should return true only when
+             // 'Transfer-Encoding' is 'chunked'.
+-            // See https://tools.ietf.org/html/rfc7230#section-3.3.3
+-            //
+-            //       If a message is received with both a Transfer-Encoding and a
+-            //       Content-Length header field, the Transfer-Encoding overrides the
+-            //       Content-Length.  Such a message might indicate an attempt to
+-            //       perform request smuggling (Section 9.5) or response splitting
+-            //       (Section 9.4) and ought to be handled as an error.  A sender MUST
+-            //       remove the received Content-Length field prior to forwarding such
+-            //       a message downstream.
+-            //
+-            // This is also what http_parser does:
+-            // https://github.com/nodejs/http-parser/blob/v2.9.2/http_parser.c#L1769
+             if (contentLengthValuesCount > 0 && message.getProtocolVersion() == HttpVersion.HTTP_1_1) {
+-                throw new IllegalArgumentException(
+-                        "Both 'Content-Length: " + contentLength + "' and 'Transfer-Encoding: chunked' found");
++                handleTransferEncodingChunkedWithContentLength(message);
+             }
+-
+             return State.READ_CHUNK_SIZE;
+         } else if (HttpHeaders.getContentLength(message, -1) >= 0) {
+             return State.READ_FIXED_LENGTH_CONTENT;
+@@ -593,6 +579,31 @@
+         }
+     }
+ 
++    /**
++     * Invoked when a message with both a "Transfer-Encoding: chunked" and a "Content-Length" header field is detected.
++     * The default behavior is to <i>remove</i> the Content-Length field, but this method could be overridden
++     * to change the behavior (to, e.g., throw an exception and produce an invalid message).
++     * <p>
++     * See: https://tools.ietf.org/html/rfc7230#section-3.3.3
++     * <pre>
++     *     If a message is received with both a Transfer-Encoding and a
++     *     Content-Length header field, the Transfer-Encoding overrides the
++     *     Content-Length.  Such a message might indicate an attempt to
++     *     perform request smuggling (Section 9.5) or response splitting
++     *     (Section 9.4) and ought to be handled as an error.  A sender MUST
++     *     remove the received Content-Length field prior to forwarding such
++     *     a message downstream.
++     * </pre>
++     * Also see:
++     * https://github.com/apache/tomcat/blob/b693d7c1981fa7f51e58bc8c8e72e3fe80b7b773/
++     * java/org/apache/coyote/http11/Http11Processor.java#L747-L755
++     * https://github.com/nginx/nginx/blob/0ad4393e30c119d250415cb769e3d8bc8dce5186/
++     * src/http/ngx_http_request.c#L1946-L1953
++     */
++    protected void handleTransferEncodingChunkedWithContentLength(HttpMessage message) {
++        message.headers().remove(HttpHeaders.Names.CONTENT_LENGTH);
++    }
++
+     private HttpChunkTrailer readTrailingHeaders(ChannelBuffer buffer) throws TooLongFrameException {
+         headerSize = 0;
+         String line = readHeader(buffer);
+