Bug#849082: libapache2-mod-perl2: FTBFS: test failures with Apache 2.4.25

[Niko Tyni]

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 at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-t-apache-read.t-HTTP-syntax-for-Apache-2.4.25-co.patch
Type: text/x-diff
Size: 994 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20161223/17c823b0/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Fix-workaround-t-filter-in_bbs_inject_header.t-failu.patch
Type: text/x-diff
Size: 1637 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20161223/17c823b0/attachment-0003.patch>