| Summary: | unescaped %0A (\n) within a RewriteMap prg: result can show other users requested sites | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Tom Tao <tom.tao> |
| Component: | mod_rewrite | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | NEW --- | ||
| Severity: | major | ||
| Priority: | P2 | ||
| Version: | 2.4.6 | ||
| Target Milestone: | --- | ||
| Hardware: | HP | ||
| OS: | Linux | ||
Does it happen on 2.4.26 or later? Can you clarify what "mixup? happens? Is it just that the rewritemap invocation is reading the additional line in the rewritemap program output instead of what would be generated for the new input? We use httpd.x86_64 (2.4.6-45.el7). The rewritemap prg gets the raw query, unescapes it and prints (because of the now unescaped %0A (newline)) 2 lines to stdout. This results in the following behaviour: User A requests file X and gets file X. User B requests file Y and gets file Y User A requests file Z%0Aanything. From now on the results User A and User B are receiving are random. User A requests file X and gets file X or file Y or 404. User B requests file X and gets file X or file Y or 404. ... httpd -k graceful ... everything's ok again. I'm not sure if the later release would have prevented it.
However, the mapping program must produce line-based output. I think mod_rewrite
discarding multiple lines in the map output is an option but seeing as how you're on something 2.4.6-based It wouldn't be a very good idea to wait for it.
Beyond correcting the mapping program or having mod_rewrite discard unexpected lines from the rewrite map program, sending the still-encoded request URL would be another way to stop the map from producing bad output so easily. One way to
do this is to pass it a subset of %{THE_REQUEST}. But i am not sure if before 2.4.26 you may also see malicious CR/LF in %{THE_REQUEST}.
For me, it's no problem any more, since it was easy to fix in the mapping prg, once i found the cause of the problem (which was rather painful due to millions accesses to this webserver). I wanted to report this bug, because i think it is privacy-related. One bad guy could get access to other users websites just by submitting a %0A URL to a server running mod_rewrite (and of cause hoping, the rewritemap prg (if one is used) does not think about limiting its output). And i'm sure, there are many apaches < 2.4.26 out there. |
If you return an unescaped %0A (\n) in a RewriteMap prg: result, Apache (resp. mod_rewrite) becomes confused. It mixes up content results among all requesting clients. Example Apache Config: ... <Location /test> Require ip ... RewriteRule /html/(.+) "/${rewriteUrl:%{REQUEST_URI}?%{QUERY_STRING}}" [DPI] RewriteRule /expired/forbidden - [F,L] </Location> <IfModule mod_rewrite.c> # LogLevel info rewrite:trace7 Mutex file:/appl/locks rewrite-map RewriteMap rewriteUrl 'prg:/appl/bin/rewriteUrl.bin' </IfModule> ... Submitting the URL http://test.com/test?func=FILE&file=foo.jpg%0Abar.jff mixes up apache results among all users, if the rewriteUrl prg unescapes %0A to a newline character and therefor returns 2 lines. This behaviour remains until Apache is restarted (graceful).