Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbug-CC: ruby-http-parser...@packages.debian.org
Hello release team,
there is a minor (non-DSA) security issue open in the Debian 10
("buster") version of http-parser, and I'd like to fix that in a stable
point release. This is #977467 [CVE-2019-15605].
Usually I'd just upload such a change change without asking for prior
authorizsation, but there's a complication: The updated version will
break the test suite of the ruby-http-parser.rb package. See my article
in debian-devel about that story in unstable and the NMU for further
details.[1][2]
Please advise how to proceed. If you think that situation is acceptable,
just let that package pass or ask me to upload it. If however you think,
the ruby-http-parser.rb maintainers (Cc'd) should provide an updated
version first, let us know and I'll try to get things coordinated.
Another idea was to postpone this story until after the upcoming 10.10
point release so there will be more time to learn about regressions and
to thandle them.
Kind regards,
Christoph
[1] https://lists.debian.org/msgid-search/1609286...@msgid.manchmal.in-ulm.de
[2]
https://packages.qa.debian.org/r/ruby-http-parser.rb/news/20201227T111838Z.html
diff -Nru http-parser-2.8.1/debian/changelog http-parser-2.8.1/debian/changelog
--- http-parser-2.8.1/debian/changelog 2018-04-12 22:15:13.0 +0200
+++ http-parser-2.8.1/debian/changelog 2021-06-04 20:59:56.0 +0200
@@ -1,3 +1,10 @@
+http-parser (2.8.1-1+deb10u1) buster; urgency=medium
+
+ * Cherry-pick "Support multi-coding Transfer-Encoding".
+Closes: #977467 [CVE-2019-15605]
+
+ -- Christoph Biedl Fri, 04 Jun 2021
20:59:56 +0200
+
http-parser (2.8.1-1) unstable; urgency=medium
* Upload to unstable
diff -Nru
http-parser-2.8.1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch
http-parser-2.8.1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch
---
http-parser-2.8.1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch
1970-01-01 01:00:00.0 +0100
+++
http-parser-2.8.1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch
2021-06-04 20:59:56.0 +0200
@@ -0,0 +1,366 @@
+Subject: Support multi-coding Transfer-Encoding
+Origin: v2.9.2-2-g7d5c99d
+Upstream-Author: Fedor Indutny
+Date: Mon Feb 3 21:10:35 2020 +0100
+
+`Transfer-Encoding` header might have multiple codings in it. Even
+though llhttp cares only about `chunked`, it must check that `chunked`
+is the last coding (if present).
+
+ABNF from RFC 7230:
+
+```
+Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
+transfer-coding ] )
+transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
+transfer-extension
+ transfer-extension = token *( OWS ";" OWS transfer-parameter )
+ transfer-parameter = token BWS "=" BWS ( token / quoted-string )
+```
+
+However, if `chunked` is not last - llhttp must assume that the encoding
+and size of the body is unknown (according to 3.3.3 of RFC 7230) and
+read the response until EOF. For request - the error must be raised for
+an unknown `Transfer-Encoding`.
+
+Furthermore, 3.3.3 of RFC 7230 explicitly states that presence of both
+`Transfer-Encoding` and `Content-Length` indicates the smuggling attack
+and "ought to be handled as an error".
+
+For the lenient mode:
+
+* Unknown `Transfer-Encoding` in requests is not an error and request
+ body is simply read until EOF (end of connection)
+* Only `Transfer-Encoding: chunked` together with `Content-Length` would
+ result an error (just like before the patch)
+
+PR-URL: https://github.com/nodejs-private/http-parser-private/pull/4
+Reviewed-By: Matteo Collina
+Reviewed-By: Sam Roberts
+Reviewed-By: James M Snell
+
+--- a/http_parser.c
b/http_parser.c
+@@ -375,7 +375,10 @@
+ , h_transfer_encoding
+ , h_upgrade
+
++ , h_matching_transfer_encoding_token_start
+ , h_matching_transfer_encoding_chunked
++ , h_matching_transfer_encoding_token
++
+ , h_matching_connection_token_start
+ , h_matching_connection_keep_alive
+ , h_matching_connection_close
+@@ -1311,6 +1314,7 @@
+ parser->header_state = h_general;
+ } else if (parser->index == sizeof(TRANSFER_ENCODING)-2) {
+ parser->header_state = h_transfer_encoding;
++parser->flags |= F_TRANSFER_ENCODING;
+ }
+ break;
+
+@@ -1391,10 +1395,14 @@
+ if ('c' == c) {
+ parser->header_state = h_matching_transfer_encoding_chunked;
+ } else {
+- parser->header_state
