Re: Bug#849082: libapache2-mod-perl2: FTBFS: test failures with Apache 2.4.25
On Friday, 23 December 2016 18:56:54 CET Niko Tyni wrote:
> 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.
The problem is that the injected header lines only have a LF and no CR. I
suggest the attached patch.
rfc7230 3.5 says:
Although the line terminator for the start-line and header fields is
the sequence CRLF, a recipient MAY recognize a single LF as a line
terminator and ignore any preceding CR.
Apache with strict enabled chooses not to implement the MAY. I am not 100%
sure that this is a good idea, but that is a different question. In any case,
mod_perl's test should send a compliant HTTP request.
Cheers,
Stefan--- ./t/filter/TestFilter/in_bbs_inject_header.pm.orig 2016-10-27 22:11:16.0 +0200
+++ ./t/filter/TestFilter/in_bbs_inject_header.pm 2016-12-24 06:55:19.049606491 +0100
@@ -181,7 +181,7 @@
if ($data and $data =~ /^POST/) {
# demonstrate how to add a header while processing other headers
-my $header = "$header1_key: $header1_val\n";
+my $header = "$header1_key: $header1_val\r\n";
push @{ $ctx->{buckets} }, APR::Bucket->new($c->bucket_alloc, $header);
debug "queued header [$header]";
}
@@ -199,7 +199,7 @@
# we hit the headers and body separator, which is a good
# time to add extra headers:
for my $key (keys %headers) {
-my $header = "$key: $headers{$key}\n";
+my $header = "$key: $headers{$key}\r\n";
push @{ $ctx->{buckets} }, APR::Bucket->new($c->bucket_alloc, $header);
debug "queued header [$header]";
}
Wheezy update of apache2?
Hello dear maintainer(s), the Debian LTS team would like to fix the security issues which are currently open in the Wheezy version of apache2: https://security-tracker.debian.org/tracker/CVE-2016-8743 Would you like to take care of this yourself? If yes, please follow the workflow we have defined here: https://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-...@lists.debian.org (via a debdiff, or with an URL pointing to the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. Indicate clearly whether you have tested the updated package or not. If you don't want to take care of this update, it's not a problem, we will do our best with your package. Just let us know whether you would like to review and/or test the updated package before it gets released. You can also opt-out from receiving future similar emails in your answer and then the LTS Team will take care of apache2 updates for the LTS releases. Thank you very much. Ola Lundqvist, on behalf of the Debian LTS team. PS: A member of the LTS team might start working on this update at any point in time. You can verify whether someone is registered on this update in this file: https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup PPS: I recently sent an email to wrong list. This is the reason why you see two versions of the same text. DS.
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 nt...@debian.org
>From f4dd0394f0975892b51a889f023d0e207553a656 Mon Sep 17 00:00:00 2001
From: Niko Tyni
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
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]
SUDO XE: in David's root and an Oracle flash of bright light. Look, use it--it's fire for freedom.
Blind? That's Exodus in reverse, and it's the most iconic phrase God has ever spoken. Listen. Let there be light. HTTP://BYGOD.PCRIOT.COM/bygod3.html This is a message about freedom--delivering true universal voting, indicating a number of technologies that have been hidden, and yet recorded by religion throughout history. This is a revolution, it is the Revolution. It's incendiary, it should have gone viral already--see that as glowing sign that we have a free speech problem. CARNIVORE, eating what? Oh right, packets and freedom. Wake up. This is a time sensitive message--I hope you can see that from it's delivery. There is a self-destruct. To be really, really clear--you have a big problem here; light this up now. Get as many eyes as you can on it.
