Bug 61388 - unescaped %0A (\n) within a RewriteMap prg: result can show other users requested sites
Summary: unescaped %0A (\n) within a RewriteMap prg: result can show other users reque...
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_rewrite (show other bugs)
Version: 2.4.6
Hardware: HP Linux
: P2 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2017-08-07 15:58 UTC by Tom Tao
Modified: 2017-08-07 17:06 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tao 2017-08-07 15:58:20 UTC
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]

<IfModule mod_rewrite.c>
#    LogLevel info rewrite:trace7
    Mutex file:/appl/locks rewrite-map
    RewriteMap rewriteUrl   'prg:/appl/bin/rewriteUrl.bin'

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).
Comment 1 Eric Covener 2017-08-07 16:12:27 UTC
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?
Comment 2 Tom Tao 2017-08-07 16:26:44 UTC
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.
Comment 3 Eric Covener 2017-08-07 16:51:30 UTC
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}.
Comment 4 Tom Tao 2017-08-07 17:06:49 UTC
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.