You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@gmail.com> on 2012/01/10 16:50:37 UTC
Re: [RFC] further proxy/rewrite URL validation security issue (CVE-2011-4317)
On Fri, Dec 16, 2011 at 7:35 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 12/16/2011 3:13 AM, Joe Orton wrote:
>> On Thu, Dec 15, 2011 at 10:04:03AM -0500, Jeff Trawick wrote:
>>> On Wed, Nov 23, 2011 at 9:23 AM, Joe Orton <jo...@redhat.com> wrote:
>>>> Prutha Parikh from Qualys reported a variant on the CVE-2011-3368 attack
>>>> against certain mod_proxy/mod_rewrite configurations. A new CVE name,
>>>> CVE-2011-4317, has been assigned to this variant.
>>>>
>>>> The configurations in question are the same as affected by -3368, e.g.:
>>>>
>>>> RewriteRule ^(.*) http://www.example.com$1 [P]
>>>>
>>>> and the equivalent ProxyPassMatch. Request examples are:
>>>>
>>>> GET @localhost::8880 HTTP/1.0\r\n\r\n
>>>> GET qualys:@qqq.qq.qualys.com HTTP/1.0\r\n\r\n
>>>
>>> These appear to not apply to 2.0.x because of a difference in URI
>>> parsing between apr-util 0.9.x and apr-util 1.something.x.
>>>
>>> Has anyone else tried that on 2.0.x?
>>
>> Tomas Hoger tracked this down to a change to apr_uri_parse(), see here:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=756483#c8
>>
>> The referenced change is in APR-util version 1.2.13, so httpd is not
>> vulnerable if using APR-util 1.2.12 or older versions.
>
> Can we determine this to be errant behavior in apr_uri_parse?
I think we can for at least a couple of these. In fact I assumed
based on the httpd 2.0 assessment pointed to earlier that the two URIs
already were rejected, and so I expected these two URIs to fail to
parse with apr-util 0.9. But no such luck:
Index: testuri.c
===================================================================
--- testuri.c (revision 1229335)
+++ testuri.c (working copy)
@@ -51,6 +51,14 @@
APR_EGENERAL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 0
},
{
+ "@127.0.0.1::8880",
+ APR_EGENERAL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 0
+ },
+ {
+ "qlalys:@127.0.0.1",
+ APR_EGENERAL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 0
+ },
+ {
"http://[::127.0.0.1]:9999/asdf.html",
0, "http", "[::127.0.0.1]:9999", NULL, NULL, "::127.0.0.1",
"9999", "/asdf.html", NULL, NULL, 9999
},
(perhaps I botched the URIs; spending 30 minutes on this every 2 weeks
isn't working well for me :( )
Fwd: Re: [RFC] further proxy/rewrite URL validation security issue
(CVE-2011-4317)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
-------- Original Message --------
Subject: Re: [RFC] further proxy/rewrite URL validation security issue (CVE-2011-4317)
Date: Tue, 17 Jan 2012 16:47:01 -0500
From: Jeff Trawick <tr...@gmail.com>
Reply-To: dev@httpd.apache.org
To: dev@httpd.apache.org
On Thu, Jan 12, 2012 at 4:54 AM, Tomas Hoger <th...@redhat.com> wrote:
> Jeff Trawick <trawick <at> gmail.com> writes:
>
>> >> Tomas Hoger tracked this down to a change to apr_uri_parse(), see here:
>> >>
>> >> https://bugzilla.redhat.com/show_bug.cgi?id=756483#c8
>> >>
>> >> The referenced change is in APR-util version 1.2.13, so httpd is not
>> >> vulnerable if using APR-util 1.2.12 or older versions.
>> >
>> > Can we determine this to be errant behavior in apr_uri_parse?
>>
>> I think we can for at least a couple of these. In fact I assumed
>> based on the httpd 2.0 assessment pointed to earlier that the two URIs
>> already were rejected, and so I expected these two URIs to fail to
>> parse with apr-util 0.9.
>
> These URIs do not fail to parse in older apr-util, but they are parsed in
> a different way. In recent versions, you get:
>
> scheme: @localhost, path: :8880
not a valid scheme; apr_uri_parse should have failed it for that
reason (needs to start with lower case, continue with lower case or
digit or +.-)
> scheme: qualys, path: @qqq.qq.qualys.com
valid scheme, valid path
--/--
so: does fixing apr_uri_parse() resolve these? not generally (but I
opened bug 52479 to track the bogus scheme issue)
some checking of acceptable URIs has to be added on top of that
> This does have path not starting with / (required for the attack) and
> also non-NULL scheme (required to bypass "does uri start with /?" check
> added in r1179239).
>
> In older versions, you get:
>
> scheme: (null), path: @localhost::8880
> scheme: (null), path: qualys:@qqq.qq.qualys.com
>
> With NULL scheme, there's no bypass of r1179239. AFAICS, when older
> apr_uri_parse() returns non-NULL scheme, path is either NULL or it
> starts with a /.
>
> HTH
yes, thanks a bunch!
>
> --
> Tomas Hoger
>
--
Born in Roswell... married an alien...
Re: [RFC] further proxy/rewrite URL validation security issue (CVE-2011-4317)
Posted by Tomas Hoger <th...@redhat.com>.
Jeff Trawick writes:
> > scheme: @localhost, path: :8880
>
> not a valid scheme; apr_uri_parse should have failed it for that
> reason (needs to start with lower case, continue with lower case or
> digit or +.-)
...
> so: does fixing apr_uri_parse() resolve these? not generally (but I
> opened bug 52479 to track the bogus scheme issue)
I agree that rejecting @localhost::8880 as invalid in apr_uri_parse()
because of the invalid scheme character does not resolve this issue.
Actually, the leading @ in that URI is misleading, as it's not needed
for the attack. localhost: or even http: should work equally well
(both result in non-NULL scheme and allow path starting with a
character different from /).
--
Tomas Hoger
Re: [RFC] further proxy/rewrite URL validation security issue (CVE-2011-4317)
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Jan 12, 2012 at 4:54 AM, Tomas Hoger <th...@redhat.com> wrote:
> Jeff Trawick <trawick <at> gmail.com> writes:
>
>> >> Tomas Hoger tracked this down to a change to apr_uri_parse(), see here:
>> >>
>> >> https://bugzilla.redhat.com/show_bug.cgi?id=756483#c8
>> >>
>> >> The referenced change is in APR-util version 1.2.13, so httpd is not
>> >> vulnerable if using APR-util 1.2.12 or older versions.
>> >
>> > Can we determine this to be errant behavior in apr_uri_parse?
>>
>> I think we can for at least a couple of these. In fact I assumed
>> based on the httpd 2.0 assessment pointed to earlier that the two URIs
>> already were rejected, and so I expected these two URIs to fail to
>> parse with apr-util 0.9.
>
> These URIs do not fail to parse in older apr-util, but they are parsed in
> a different way. In recent versions, you get:
>
> scheme: @localhost, path: :8880
not a valid scheme; apr_uri_parse should have failed it for that
reason (needs to start with lower case, continue with lower case or
digit or +.-)
> scheme: qualys, path: @qqq.qq.qualys.com
valid scheme, valid path
--/--
so: does fixing apr_uri_parse() resolve these? not generally (but I
opened bug 52479 to track the bogus scheme issue)
some checking of acceptable URIs has to be added on top of that
> This does have path not starting with / (required for the attack) and
> also non-NULL scheme (required to bypass "does uri start with /?" check
> added in r1179239).
>
> In older versions, you get:
>
> scheme: (null), path: @localhost::8880
> scheme: (null), path: qualys:@qqq.qq.qualys.com
>
> With NULL scheme, there's no bypass of r1179239. AFAICS, when older
> apr_uri_parse() returns non-NULL scheme, path is either NULL or it
> starts with a /.
>
> HTH
yes, thanks a bunch!
>
> --
> Tomas Hoger
>
--
Born in Roswell... married an alien...
Re: [RFC] further proxy/rewrite URL validation security issue (CVE-2011-4317)
Posted by Tomas Hoger <th...@redhat.com>.
Jeff Trawick <trawick <at> gmail.com> writes:
> >> Tomas Hoger tracked this down to a change to apr_uri_parse(), see here:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=756483#c8
> >>
> >> The referenced change is in APR-util version 1.2.13, so httpd is not
> >> vulnerable if using APR-util 1.2.12 or older versions.
> >
> > Can we determine this to be errant behavior in apr_uri_parse?
>
> I think we can for at least a couple of these. In fact I assumed
> based on the httpd 2.0 assessment pointed to earlier that the two URIs
> already were rejected, and so I expected these two URIs to fail to
> parse with apr-util 0.9.
These URIs do not fail to parse in older apr-util, but they are parsed in
a different way. In recent versions, you get:
scheme: @localhost, path: :8880
scheme: qualys, path: @qqq.qq.qualys.com
This does have path not starting with / (required for the attack) and
also non-NULL scheme (required to bypass "does uri start with /?" check
added in r1179239).
In older versions, you get:
scheme: (null), path: @localhost::8880
scheme: (null), path: qualys:@qqq.qq.qualys.com
With NULL scheme, there's no bypass of r1179239. AFAICS, when older
apr_uri_parse() returns non-NULL scheme, path is either NULL or it
starts with a /.
HTH
--
Tomas Hoger