Re: Bug#849082: libapache2-mod-perl2: FTBFS: test failures with Apache 2.4.25
Control: retitle -1 libapache2-mod-perl2: FTBFS: test failures with Apache 2.4.25
Control: tag -1 patch
@apache2 maintainers (cc'd): it seems that mod_perl is no longer able
to 'inject headers' with apache2 2.4.25. See below. A workaround is to
explicitly configure the server for 'unsafe' behaviour. Is mod_perl just
doing something "wrong" at the moment, or is the whole feature something
that should not be possible anymore?
On Thu, Dec 22, 2016 at 05:17:34PM +0100, gregor herrmann wrote:
> On Thu, 22 Dec 2016 17:23:24 +0200, Niko Tyni wrote:
>
> > Package: libapache2-mod-perl2
> > Version: 2.0.10-1
> > Severity: serious
> From the apache2 changelog:
>
> * Security: CVE-2016-8743:
> Enforce HTTP request grammar corresponding to RFC7230 for request lines
> and request headers, to prevent response splitting and cache pollution by
> malicious clients or downstream proxies.
> * The stricter HTTP enforcement may cause compatibility problems with
> non-conforming clients. Fine-tuning is possible with the new
> HttpProtocolOptions directive.
Indeed, these changes seem to be the cause for the two new test failures.
> > # Failed test 1 in t/apache/read.t at line 52
> > request has failed (the response code was: 400)
This one is trivial: in t/apache/read.t
-for my $string ("POST $location http/1.0",
+for my $string ("POST $location HTTP/1.0",
Patch attached.
The other failure seems to be harder. The test is installing a "filter"
on the request headers and injecting new header lines on the server
side. The client code is t/filter/in_bbs_inject_header.t and the server
side is in t/filter/TestFilter/in_bbs_inject_header.pm.
# ./t/TEST -trace=debug t/filter/in_bbs_inject_header.t
[...]
request has failed (the response code was: 400)
see t/logs/error_log for more details
t/filter/in_bbs_inject_header.t .. Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 36/36 subtests
>From t/logs/error_log:
[ debug] -------------------- input filter called ---------------------
[ debug] filter read:
[
]
[ debug] END of original HTTP Headers
[ debug] queued header [X-Extra-Header2: Value 2
]
[ debug] queued header [X-Extra-Header3: Value 3
]
[ debug] queued header [
]
[ debug] injected header: [X-Extra-Header2: Value 2
]
[Fri Dec 23 16:05:28.968699 2016] [core:debug] [pid 15527:tid 139982245197568] protocol.c(957): (22)Invalid argument: [client 127.0.0.1:53182] Failed to read request header line X-Extra-Header2: Value 2
[Fri Dec 23 16:05:28.968717 2016] [core:debug] [pid 15527:tid 139982245197568] protocol.c(1313): [client 127.0.0.1:53182] AH00567: request failed: error reading the headers
It looks to me like the server is checking back on the received request
and noticing that the injected header was not there originally. The
400 response is certainly not caused by anything in the request itself;
a plain GET request gets the same response as well.
This passage in RFC 7230, section 9.4., seems relevant:
A more effective mitigation is to prevent anything other than the
server's core protocol libraries from sending a CR or LF within the
header section, which means restricting the output of header fields to
APIs that filter for bad octets and not allowing application servers
to write directly to the protocol stream.
I would expect mod_perl to be classified as a 'core protocol library' in
this sense, but I have no idea yet if it's just doing something wrong.
Patch attached to revert to the old "unsafe" behaviour in the virtual
host specific to this test.
--
Niko Tyni ntyni@debian.org
>From f4dd0394f0975892b51a889f023d0e207553a656 Mon Sep 17 00:00:00 2001
From: Niko Tyni <ntyni@debian.org>
Date: Fri, 23 Dec 2016 18:27:23 +0200
Subject: [PATCH 1/2] Fix t/apache/read.t HTTP syntax for Apache 2.4.25
compatibility
HTTP/1.1 RFC 7230, section 2.6. "Protocol Versioning" says the HTTP name
is case sensitive. Starting with Apache 2.4.25, using lower case will
make the server issue a 400 Bad request response, causing a test failure.
https://tools.ietf.org/html/rfc7230#section-2.6
Bug-Debian: https://bugs.debian.org/849082
---
t/apache/read.t | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/apache/read.t b/t/apache/read.t
index 83670c9..9f7f504 100644
--- a/t/apache/read.t
+++ b/t/apache/read.t
@@ -24,7 +24,7 @@ close $fh;
my $size = length $data;
-for my $string ("POST $location http/1.0",
+for my $string ("POST $location HTTP/1.0",
"Content-length: $size",
"") {
my $line = "$string\r\n";
--
2.11.0
>From edd3ca5e9f2666e8e4936ac98446d94a5907c137 Mon Sep 17 00:00:00 2001
From: Niko Tyni <ntyni@debian.org>
Date: Fri, 23 Dec 2016 18:31:01 +0200
Subject: [PATCH 2/2] Fix/workaround t/filter/in_bbs_inject_header.t failure
with Apache 2.4.25
Since Apache 2.4.25, header injection fails with
protocol.c(957): (22)Invalid argument: [client 127.0.0.1:53182] Failed to read request header line X-Extra-Header2: Value 2
protocol.c(1313): [client 127.0.0.1:53182] AH00567: request failed: error reading the headers
making the server issue a 400 Bad request response and causing test
failures.
This seems to be due to a new protection against "Response Splitting"
attacks; see RFC 7230, section 9.4. It's currently unclear if there is
a better way for mod_perl to inject the headers.
Fix/work around the issue by configuring the server for "unsafe" behaviour.
Bug-Debian: https://bugs.debian.org/849082
---
t/filter/TestFilter/in_bbs_inject_header.pm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/filter/TestFilter/in_bbs_inject_header.pm b/t/filter/TestFilter/in_bbs_inject_header.pm
index b09d6f9..c5cb28b 100644
--- a/t/filter/TestFilter/in_bbs_inject_header.pm
+++ b/t/filter/TestFilter/in_bbs_inject_header.pm
@@ -252,6 +252,9 @@ __END__
<VirtualHost TestFilter::in_bbs_inject_header>
PerlModule TestFilter::in_bbs_inject_header
PerlInputFilterHandler TestFilter::in_bbs_inject_header
+ <IfVersion > 2.4.23>
+ HttpProtocolOptions Unsafe
+ </IfVersion>
<Location /TestFilter__in_bbs_inject_header>
SetHandler modperl
PerlResponseHandler TestFilter::in_bbs_inject_header::response
--
2.11.0
Reply to: