You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rainer Jung <ra...@kippdata.de> on 2012/03/23 18:00:45 UTC
Fix for CVE-2011-4317 broke RewriteMap in forward proxy?
It seems using a rewrite map in a forward proxy is broken in 2.2.22. It
was working until 2.2.21. The problem is the fix for CVE-2011-4317 which
returns DECLINED in hook_uri2file() in mod_rewrite.
The config is roughly:
Listen 3128
<VirtualHost *:3128>
ProxyRequests on
RewriteEngine on
RewriteRule http://myserver.example.com/dummy.txt
/opt/apache/htdocs/dummy.txt
</VirtualHost>
The actual config is more complex, but the above suffices to reproduce.
In case you wonder why one would want to do that: the real config has a
list of rewrite rules (actually a rewrite map) containing URLs of large
files which have been deployed directly on the forward proxy and should
not be proxied, instead be delivered from the local file system.
The actual rules then have a part that fall back to normal proxying any
URL, which is not handled by the rewrite rules. I ommitted these here,
because they are not relevant for reproduction.
I added a log statement and it is indeed the new "return DECLINED" we
have backported from trunk in 2.2.22. The triggering case is that the
uri does not start with a "/".
Test case:
curl -x localhost:3128 http://myserver.example.com/dummy.txt
Expected result: getting the file /opt/data/dummy.txt
Actual result: The RewriteMap is not being called, instead the fallback
config I removed here is executed and the file is retrieved from the
origin server
Any idea how to fix? Or do you think this is correct behaviour?
Regards,
Rainer
Re: Fix for CVE-2011-4317 broke RewriteRule in forward proxy?
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Mar 24, 2012 at 12:27 PM, Rainer Jung <ra...@kippdata.de> wrote:
> On 24.03.2012 16:39, Jeff Trawick wrote:
>>
>> On Sat, Mar 24, 2012 at 7:31 AM, Rainer Jung<ra...@kippdata.de>
>> wrote:
>>>
>>> On 24.03.2012 07:02, Kaspar Brand wrote:
>>>>
>>>>
>>>> On 23.03.2012 18:11, Rainer Jung wrote:
>>>>>
>>>>>
>>>>> It should be RewriteRule not RewriteMap in my previous mail. I
>>>>> simplified the config to a single RewriteRule but forgot to adjst
>>>>> subject and intro of my mail. The problem remains the same.
>>>>
>>>>
>>>>
>>>> Doesn't that ring a bell - namely the one of PR 52774?
>>>
>>>
>>>
>>> Thanks Kaspar, yes that's the same issue. Sorry for not having remembered
>>> or
>>> searched that one.
>>>
>>> I expect the same problem for trunk, but will check it.
>>>
>>> I need to review the argumentation for the final variant of the
>>> CVE-2011-4317 fix but IMHO the current behavior is broken.
>>
>>
>> The primary reasoning was that it lets the long-standing fallback
>> logic in core fail the request if necessary, letting modules decide
>> what they could handle. Subsequently it was determined that the error
>> path in the initial 3368 fix didn't work for HTTP 0.9 in some levels
>> of code (2.0 IIRC) and just managed to work in 2.2.
>
>
>> But yes, this forward proxy situation needs to be supported. The
>> check added to mod_rewrite to skip things it didn't know how to handle
>> was not correct.
>>
>> After a cursory skim of the code, it seems that RewriteRule could
>> conceivably be used on anything that gets in r->uri or r->filename,
>> but that generality, hopefully unintentional, was part of the original
>> problem.
>
>
> Would it help to apply the current checks only for [P] flags? Or are there
> other known exposures for the proxy problem? I don't remember any, but maybe
> those were only the easiest once to understand.
>
> Currently we DECLINE in hook_uri2file() before we actually go through the
> rules. We could DECLINE only if we detect a [P] rule.
>
> Another question would then be, if the same check would again be necessary
> when running through the rules the second time in the fixup hook.
Adding Petr, who posted a patch to bug 52774...
I've stared at the patch a bit (no mysteries) as well as at Rainer's
suggestions above from a couple of weeks ago (whoops!) but haven't
settled on an opinion yet.
Re: Fix for CVE-2011-4317 broke RewriteRule in forward proxy?
Posted by Rainer Jung <ra...@kippdata.de>.
On 24.03.2012 16:39, Jeff Trawick wrote:
> On Sat, Mar 24, 2012 at 7:31 AM, Rainer Jung<ra...@kippdata.de> wrote:
>> On 24.03.2012 07:02, Kaspar Brand wrote:
>>>
>>> On 23.03.2012 18:11, Rainer Jung wrote:
>>>>
>>>> It should be RewriteRule not RewriteMap in my previous mail. I
>>>> simplified the config to a single RewriteRule but forgot to adjst
>>>> subject and intro of my mail. The problem remains the same.
>>>
>>>
>>> Doesn't that ring a bell - namely the one of PR 52774?
>>
>>
>> Thanks Kaspar, yes that's the same issue. Sorry for not having remembered or
>> searched that one.
>>
>> I expect the same problem for trunk, but will check it.
>>
>> I need to review the argumentation for the final variant of the
>> CVE-2011-4317 fix but IMHO the current behavior is broken.
>
> The primary reasoning was that it lets the long-standing fallback
> logic in core fail the request if necessary, letting modules decide
> what they could handle. Subsequently it was determined that the error
> path in the initial 3368 fix didn't work for HTTP 0.9 in some levels
> of code (2.0 IIRC) and just managed to work in 2.2.
> But yes, this forward proxy situation needs to be supported. The
> check added to mod_rewrite to skip things it didn't know how to handle
> was not correct.
>
> After a cursory skim of the code, it seems that RewriteRule could
> conceivably be used on anything that gets in r->uri or r->filename,
> but that generality, hopefully unintentional, was part of the original
> problem.
Would it help to apply the current checks only for [P] flags? Or are
there other known exposures for the proxy problem? I don't remember any,
but maybe those were only the easiest once to understand.
Currently we DECLINE in hook_uri2file() before we actually go through
the rules. We could DECLINE only if we detect a [P] rule.
Another question would then be, if the same check would again be
necessary when running through the rules the second time in the fixup hook.
Regards,
Rainer
Re: Fix for CVE-2011-4317 broke RewriteRule in forward proxy?
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Mar 24, 2012 at 7:31 AM, Rainer Jung <ra...@kippdata.de> wrote:
> On 24.03.2012 07:02, Kaspar Brand wrote:
>>
>> On 23.03.2012 18:11, Rainer Jung wrote:
>>>
>>> It should be RewriteRule not RewriteMap in my previous mail. I
>>> simplified the config to a single RewriteRule but forgot to adjst
>>> subject and intro of my mail. The problem remains the same.
>>
>>
>> Doesn't that ring a bell - namely the one of PR 52774?
>
>
> Thanks Kaspar, yes that's the same issue. Sorry for not having remembered or
> searched that one.
>
> I expect the same problem for trunk, but will check it.
>
> I need to review the argumentation for the final variant of the
> CVE-2011-4317 fix but IMHO the current behavior is broken.
The primary reasoning was that it lets the long-standing fallback
logic in core fail the request if necessary, letting modules decide
what they could handle. Subsequently it was determined that the error
path in the initial 3368 fix didn't work for HTTP 0.9 in some levels
of code (2.0 IIRC) and just managed to work in 2.2.
But yes, this forward proxy situation needs to be supported. The
check added to mod_rewrite to skip things it didn't know how to handle
was not correct.
After a cursory skim of the code, it seems that RewriteRule could
conceivably be used on anything that gets in r->uri or r->filename,
but that generality, hopefully unintentional, was part of the original
problem.
Re: Fix for CVE-2011-4317 broke RewriteRule in forward proxy?
Posted by Rainer Jung <ra...@kippdata.de>.
On 24.03.2012 07:02, Kaspar Brand wrote:
> On 23.03.2012 18:11, Rainer Jung wrote:
>> It should be RewriteRule not RewriteMap in my previous mail. I
>> simplified the config to a single RewriteRule but forgot to adjst
>> subject and intro of my mail. The problem remains the same.
>
> Doesn't that ring a bell - namely the one of PR 52774?
Thanks Kaspar, yes that's the same issue. Sorry for not having
remembered or searched that one.
I expect the same problem for trunk, but will check it.
I need to review the argumentation for the final variant of the
CVE-2011-4317 fix but IMHO the current behavior is broken.
Regards,
Rainer
Re: Fix for CVE-2011-4317 broke RewriteRule in forward proxy?
Posted by Kaspar Brand <ht...@velox.ch>.
On 23.03.2012 18:11, Rainer Jung wrote:
> It should be RewriteRule not RewriteMap in my previous mail. I
> simplified the config to a single RewriteRule but forgot to adjst
> subject and intro of my mail. The problem remains the same.
Doesn't that ring a bell - namely the one of PR 52774?
Kaspar
Re: Fix for CVE-2011-4317 broke RewriteRule in forward proxy?
Posted by Rainer Jung <ra...@kippdata.de>.
It should be RewriteRule not RewriteMap in my previous mail. I
simplified the config to a single RewriteRule but forgot to adjst
subject and intro of my mail. The problem remains the same.
On 23.03.2012 18:00, Rainer Jung wrote:
> It seems using a rewrite map in a forward proxy is broken in 2.2.22. It
> was working until 2.2.21. The problem is the fix for CVE-2011-4317 which
> returns DECLINED in hook_uri2file() in mod_rewrite.
>
> The config is roughly:
>
> Listen 3128
> <VirtualHost *:3128>
>
> ProxyRequests on
> RewriteEngine on
>
> RewriteRule http://myserver.example.com/dummy.txt
> /opt/apache/htdocs/dummy.txt
>
> </VirtualHost>
>
> The actual config is more complex, but the above suffices to reproduce.
>
> In case you wonder why one would want to do that: the real config has a
> list of rewrite rules (actually a rewrite map) containing URLs of large
> files which have been deployed directly on the forward proxy and should
> not be proxied, instead be delivered from the local file system.
>
> The actual rules then have a part that fall back to normal proxying any
> URL, which is not handled by the rewrite rules. I ommitted these here,
> because they are not relevant for reproduction.
>
> I added a log statement and it is indeed the new "return DECLINED" we
> have backported from trunk in 2.2.22. The triggering case is that the
> uri does not start with a "/".
>
> Test case:
>
> curl -x localhost:3128 http://myserver.example.com/dummy.txt
>
> Expected result: getting the file /opt/data/dummy.txt
> Actual result: The RewriteMap is not being called, instead the fallback
> config I removed here is executed and the file is retrieved from the
> origin server
>
> Any idea how to fix? Or do you think this is correct behaviour?
>
> Regards,
>
> Rainer
--
kippdata
informationstechnologie GmbH Tel: 0228 98549 -0
Bornheimer Str. 33a Fax: 0228 98549 -50
53111 Bonn www.kippdata.de
HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann