Bug#880993: enable http2 protocol when http2 module is enabled
Source: apache2 Version: 2.4.25-3+deb9u3 Severity: wishlist It's unclear to me why the http2 module in the Apache2 debian package doesn't *actually* enable the http2 *protocol*. Maybe I don't understand this right, but it seems to me that to enable http2 in apache/Debian, you need to do the following: a2enmod http2 But then also add some configuration blurb like this somewhere: Protocols h2 h2c http/1.1 The above configuration will enable HTTP/2 over TLS (h2) and HTTP/2 over TCP (h2c, cleartext) then keep the http/1.1 as a backwards-compatibility option. Why isn't this part of /etc/apache2/mods-available/http2.conf? It seems to me if you want to enable HTTP2 on the server, you'd expect this to just turn on as well. I can imagine that people may want to enable only on *some* virtual hosts, but then that config can be commented out or disabled and added to virtual host as needed. Or it can be disabled in the relevant vhosts as well. It could also be a good place to have, commented out, sample H2Push configurations as well... e.g. # # HTTP/2 push configuration # # H2Push on # # # Default Priority Rule # # H2PushPriority * After 16 # # # More complex ruleset: # # H2PushPriority * after # H2PushPriority text/cssbefore # H2PushPriority image/jpeg after 32 # H2PushPriority image/png after 32 # H2PushPriority application/javascript interleaved # # # Configure some stylesheet and script to be pushed by the webserver # # # Header add Link "; rel=preload; as=style" # Header add Link "; rel=preload; as=script" # More sample configs are here: https://httpd.apache.org/docs/2.4/mod/mod_http2.html#h2pushpriority What do you think? -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
help needed to complete regression fix for apache2 Bug#858373
Hi, (Sorry for the large CC list, but I am hoping to get a broad approval of the next changes for this in order to avoid previous mistakes. ;) In particular, I'd be very grateful for some input by Stefan considering his knowledge of the Apache codebase and how ... exotic this problems is.) As I mentioned in the #858373 bug report, I started looking at fixing the regression introduced by the 2.2.22-13+deb7u8 upload, part of DLA-841-1. The problem occurs when a CGI(d) ErrorDocument is configured to handle 400 error messages that can be triggered with a simple "GET / HTTP/1.0\n\n". Such a request segfaults Apache in Wheezy right now. I have been able to confirm that there is an unitialized variable that gets carried around. This issue was introduced as part of CVE-2016-8743-aux.patch in the original upload, although I fail to remember now why this hunk is there exactly. It seems to be related to a patch I somewhat blindly and incorrectly merged (see 87r33tqvqs@curie.anarc.at for details). Unfortunately, re-introducing the protocol initialization code isn't sufficient: it does fix the segfaults, but the ErrorDocument handling is not quite working yet. Instead of seeing the output of the ErrorDocument, after 10 seconds, I get the raw 400 message, doubled with a 500 error document warning: $ echo -ne "GET /foo HTTP/1.0\n\n" | nc localhost 80 HTTP/1.1 400 Bad Request Date: Wed, 19 Jul 2017 19:11:13 GMT Server: Apache/2.2.22 (Debian) Vary: Accept-Encoding Content-Length: 433 Connection: close Content-Type: text/html; charset=iso-8859-1 400 Bad Request Bad Request Your browser sent a request that this server could not understand. Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.2.22 (Debian) Server at wheezy.raw Port 80 In the error log, I see: [Wed Jul 19 19:11:23 2017] [error] [client 127.0.0.1] (70007)The timeout specified has expired: Error reading request entity data The first part of the error is mod_reqtimeout kicking in as the request parser stalls on the CGI script. The second part is mod_cgi(d) failing to read the request from the CGI script, obviously. My theory is that there is *still* something wrong with the request parser, even after fixing the r->protocol initialization flaw. I base this theory on the fact that a 404 ErrorDocument works without problem. $ echo -ne "GET /foo HTTP/1.0\r\n\r\n" | nc localhost 80 HTTP/1.1 404 Not Found Date: Wed, 19 Jul 2017 19:13:44 GMT Server: Apache/2.2.22 (Debian) Vary: Accept-Encoding Connection: close Content-Type: text/html Hello, World. Note that I have also tried to see if sending "\r\n" instead of just "\n" in my "hello world" example would work around the issue: it doesn't, unfortunately. I am at a loss as where to go from here, to be honest. The patch (attached) at least fixes the segfault, which resolves the primary issue at hand here (DoS by crashing processes!) but it would be nice to actually fix the ErrorDocument as well.. Any ideas? Thanks in advance, A. signature.asc Description: PGP signature
Bug#858373: apache2: segfaults upon recieving bad request when using worker/event mpm and cgid errordoc
Hi! First, thank you very much for the detailed bug report, very useful! Responses inline. On Tue, Mar 21, 2017 at 11:56:40AM -0500, Brian Kroth wrote: > Package: apache2.2-common > Version: 2.2.22-13+deb7u8 > Severity: normal > Tags: security > > Dear Maintainer, > > We have some websites running on Debian Wheezy, so still using Apache > 2.2.22, that are configured either in Worker or Event MPM (so are using > mod_cgid in what follows), and have a custom "ErrorDocument 400" directive > that points at a perl script for providing custom ModSecurity error. Interesting. It would have been useful to see actual configuration examples, as I had to go through a little bit of digging to reproduce the issue. Just using cgid or worker is not sufficient - you actually *do* need a ErrorDocument directive as well. So thanks to providing those details, but snippets would have helped as well! :) > I haven't dug up an older version of the package from snapshots to confirm > this, but I think that since the recently backported HttpProtocolOptions > directive to that version (BTW, where was that announced - I had to run > strings on the binary to find it), I've been seeing a lot of > segfault/coredumps registered in the Apache error logs. I'm sorry to hear that. The change was announced in DLA-841-1 back in February: https://lists.debian.org/debian-lts-announce/2017/02/msg00031.html If you haven't seen that announcement, you may not be subscribed to the debian-lts-announce mailing list, in which case I strongly suggest you subscribe: https://lists.debian.org/debian-lts-announce/ There was also a lengthy discussion regarding the patchset on the debian-lts mailing list: https://lists.debian.org/87fukh7hcq@curie.anarc.at Participation to the debian-lts mailing list is not mandatory for LTS users, however... > After some analysis, I've found that I can reproduce the error with a fairly > trivial shell command: > > # echo -ne "GET / HTTP/1.0\n" | nc $some_website 80 This definitely looks like a heading parsing regression caused by DLA-841-1. I cannot reproduce with a vanilla Apache install. To reproduce, on wheezy: 1. apt-get install apache2 2. create a dummy perl script in /usr/lib/cgi-bin/hello.pl #!/usr/bin/perl print "Content-type: text/html\n\n"; print "Hello, World."; 3. make it executable 4. add this directive, say in /etc/apache2/conf.d/hello ErrorDocument 400 /cgi-bin/hello.pl 5. reload apache (apache2ctl graceful or whatever) 6. issue the killer request: echo -ne "GET / HTTP/1.0\n" | nc localhost 80 > > From the coredump, I was able to find that this line (1371) in the > cgid_handler() code in the modules/generators/mod_cgid.c source file has a > null pointer issue on the r->protocol field: > > is_included = !strcmp(r->protocol, "INCLUDED"); > > Seems like a bit of a security issue to me. Definifely. [...] On Tue, Apr 11, 2017 at 12:08:11PM +0930, Doran Moppert wrote: > This looks like a form of CVE-2015-0253, which affected upstream apache > 2.4.11, was introduced by the backport. The fix is to ensure > r->protocol is always populated: > > https://svn.apache.org/viewvc?view=revision=1668879 Good findings. The fun part is that the above patch doesn't apply because the protocol initialization was just missing. So this is possibly broader than just 400 errors. Note that I have tested this in jessie, and it doesn't seem affected, so the backport for CVE-2016-8743 was done correctly there. I'll prepare a package to fix this shortly. A. -- Cyberspace. A consensual hallucination experienced daily by billions of legitimate operators, in every nation, by children being taught mathematical concepts... - William Gibson signature.asc Description: PGP signature
