Created attachment 31133 [details] continuation-lines.patch Handling of line wrapping is broken if "\" is the last character before buffer resizing. Right know that's the 206. character. Testcase: <VirtualHost *:80> DocumentRoot /var/www/test ServerName foo.bar ServerAlias 3456789 123456789 123456789 123456789 \ 123456789 123456789 123456789 123456789 123456789 \ 123456789 123456789 123456789 123456789 123456789 \ 123456789 123456789 123456789 123456789 123456789 1234 \ 123456789 </VirtualHost> I've also attached a quick fix.
A better testcase to make this more clear: <VirtualHost *:80> DocumentRoot /var/www/test ServerName foo.bar ServerAlias 3456789 123456789 123456789 123456789 \ 123456789 123456789 123456789 123456789 123456789 \ 123456789 123456789 123456789 123456789 123456789 \ 123456789 123456789 123456789 123456789 123456789 1234 \ thats_still_an_alias </VirtualHost> Results in: # apachectl configtest AH00526: Syntax error on line 198 of /etc/apache2/httpd.conf: Invalid command 'thats_still_an_alias', perhaps misspelled or defined by a module not included in the server configuration
bump
Created attachment 31923 [details] continuation-lines-v2.patch Since there doesn't seem to be much interest in fixing this edge case of the parser, I decided to rewrite the patch to be more sane. The outcome is attached. Instead of adding a grown-flag to indicate we can look behind the first byte, the function now expects the whole buffer, it's actual size and the current offset to write to. Additional I've fixed a bug in the "getch"-branch that also happens during buffer resize. The APR_ENOSPC check is *before* storing the current character. So this one gets lost. I've checked both branches against all our webservers and there were no parsing errors.
This issue is also affecting ModSecurity. Specially when it is used with the development version of the OWASP CRS which uses a lot of "continuation lines" (aka "\") to organize the rules in a format that is easy to read. (reference: https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0.0-dev/rules/REQUEST-13-SCANNER-DETECTION.conf) Using the OWASP CRS -dev it is possible to face this problem multiple times. The work around is to add random spaces in the rule that is exhibiting the problem. I have tested (on the branch http-2.4.x@b2f4b2) the patch attached and it fixed the problem. So far no other issue.
We've run into this same problem in multiple configuration files containing ModSecurity rules. At first I thought it might be a bug in ModSecurity, but once I confirmed that httpd itself was extracting a corrupted version of the directive's argument, I discovered this known bug. (Note: 2.2 does not appear to be affected, only 2.4) It would help us a lot if this could be fixed in 2.4, because we're automating the distribution and installation of ModSecurity rule sets and would prefer not to have to apply a custom patch to accommodate these long continuation lines.
Thanks Manuel, committed to trunk in 1648394 and will propose for backport shortly.
Backported to 2.4.11 in r1651653.