|Summary:||Continuation lines are broken during buffer resize|
|Product:||Apache httpd-2||Reporter:||Manuel Mausz <manuel-asf>|
|Component:||Core||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
Description Manuel Mausz 2013-12-19 12:15:58 UTC
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.
Comment 1 Manuel Mausz 2013-12-19 12:22:59 UTC
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
Comment 2 Manuel Mausz 2014-07-23 15:27:25 UTC
Comment 3 Manuel Mausz 2014-08-17 17:18:49 UTC
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.
Comment 4 Felipe Zimmerle 2014-12-10 20:05:43 UTC
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.
Comment 5 Rikus Goodell 2014-12-23 21:23:13 UTC
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.
Comment 6 Eric Covener 2014-12-29 17:28:22 UTC
Thanks Manuel, committed to trunk in 1648394 and will propose for backport shortly.