You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@apr.apache.org by bu...@apache.org on 2011/05/18 15:07:04 UTC
DO NOT REPLY [Bug 51219] New: apr_fnmatch infinite loop on pattern
"/*/WEB-INF/"
https://issues.apache.org/bugzilla/show_bug.cgi?id=51219
Bug #: 51219
Summary: apr_fnmatch infinite loop on pattern "/*/WEB-INF/"
Product: APR
Version: HEAD
Platform: PC
OS/Version: Linux
Status: NEW
Severity: regression
Priority: P2
Component: APR
AssignedTo: bugs@apr.apache.org
ReportedBy: christian.roue@neolane.com
Classification: Unclassified
After last apr update on Debian 5&6 / i386 for CVE-2011-0419 we observed
multiple of our apache servers running 100%+ CPU randomely.
We identified function going into an infinite loop to be apr_fnmatch trying to
match pattern '/*/WEB-INF/' against any non matching uri.
This pattern is matched due to following directive in our .conf:
<Location "/*/WEB-INF/">
deny from all
</Location>
Problem was reproduced with Apache apr-1.4.4 recompiled from sources adding the
extra testcase (testfnmatch.c):
{"/*/WEB-INF/", "/wontmatch", FAIL},
Problem daesn't exist in apr-1.3.12.
Debian patch is apparently a back port of new code in 1.2/1.4 for Deb 5/6
Debian patch info:
http://packetstormsecurity.org/files/view/101435/dsa-2237-1.txt
Chris
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 51219] apr_fnmatch infinite loop on pattern
"/*/WEB-INF/"
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51219
--- Comment #1 from Chris <ch...@neolane.com> 2011-05-19 10:22:27 UTC ---
Bug reported to debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627182
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 51219] apr_fnmatch infinite loop on pattern
"/*/WEB-INF/"
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51219
Chris <ch...@neolane.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P1
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
DO NOT REPLY [Bug 51219] apr_fnmatch infinite loop on pattern
"/*/WEB-INF/"
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51219
Maksymilian <ma...@cxib.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |http://cvsweb.netbsd.org/bs
| |dweb.cgi/src/lib/libc/gen/f
| |nmatch.c.diff?r1=text&tr1=1
| |.22&r2=text&tr2=1.24
--- Comment #2 from Maksymilian <ma...@cxib.net> 2011-05-21 07:06:15 UTC ---
Instead of changing the algorithm, it is better to add recursion limit and set
64 (not bigger). I see only one recursion call inside apr_fnmatch
457 while (apr_dir_read(&finfo, APR_FINFO_NAME, dir) == APR_SUCCESS) {
458 if (apr_fnmatch(pattern, finfo.name, 0) == APR_SUCCESS) {
so better limit this call, than change the algorithm.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
[Bug 51219] apr_fnmatch infinite loop on pattern "/*/WEB-INF/"
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51219
Stefan Fritsch <sf...@sfritsch.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Stefan Fritsch <sf...@sfritsch.de> ---
This is fixed in 1.4.5
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
[Announce] Regressions in httpd 2.2.18, apr 1.4.4, and apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@apache.org>.
New releases are in progress for each of these projects and are
expected to be available in the coming days. The upcoming httpd
2.2.19 will bundle new releases of apr and apr-util which correct
the regressions described below. An announcement of these releases
will be broadcast.
Note: httpd 2.2.18 bundles apr 1.4.4 and apr-util 1.3.11.
Summary of regressions:
httpd 2.2.18: The ap_unescape_url_keep2f() function signature was changed.
This breaks binary compatibility of a number of third-party modules. In
addition, a regression in apr 1.4.4 (see below) could cause httpd to hang.
apr 1.4.4: A fix in apr 1.4.4 apr_fnmatch() to address CVE-2011-0419
introduced a new vulnerability. A patch is attached and should be used
if httpd workers enter a hung state (100% cpu utilization) after updating
to httpd 2.2.18 or apr-util 1.4.4, or if hangs are seen in other apr
applications which use apr_fnmatch().
apr-util 1.3.11: A fix to LDAP support in apr-util 1.3.11 could cause
crashes with httpd's mod_authnz_ldap in some situations.
[Announce] Regressions in httpd 2.2.18, apr 1.4.4, and apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@apache.org>.
New releases are in progress for each of these projects and are
expected to be available in the coming days. The upcoming httpd
2.2.19 will bundle new releases of apr and apr-util which correct
the regressions described below. An announcement of these releases
will be broadcast.
Note: httpd 2.2.18 bundles apr 1.4.4 and apr-util 1.3.11.
Summary of regressions:
httpd 2.2.18: The ap_unescape_url_keep2f() function signature was changed.
This breaks binary compatibility of a number of third-party modules. In
addition, a regression in apr 1.4.4 (see below) could cause httpd to hang.
apr 1.4.4: A fix in apr 1.4.4 apr_fnmatch() to address CVE-2011-0419
introduced a new vulnerability. A patch is attached and should be used
if httpd workers enter a hung state (100% cpu utilization) after updating
to httpd 2.2.18 or apr-util 1.4.4, or if hangs are seen in other apr
applications which use apr_fnmatch().
apr-util 1.3.11: A fix to LDAP support in apr-util 1.3.11 could cause
crashes with httpd's mod_authnz_ldap in some situations.
Re: [users@httpd] Re: [Announce] Regressions in httpd 2.2.18, apr
1.4.4, and apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/20/2011 9:21 AM, Jeff Trawick wrote:
> On Thu, May 19, 2011 at 9:40 PM, DW <xf...@hotmail.com> wrote:
>> William A. Rowe Jr. wrote:
>>> New releases are in progress for each of these projects and are
>>> expected to be available in the coming days. The upcoming httpd
>>> 2.2.19 will bundle new releases of apr and apr-util which correct
>>> the regressions described below. An announcement of these releases
>>> will be broadcast.
>>>
>>
>>
>> Is there time frame anywhere for 2.2.19 release date?
>
> "soon"
And the release vote is already underway, should be complete by midday
tomorrow, and we always give the mirrors a chance to catch up before
publishing the announcement.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: [Announce] Regressions in httpd 2.2.18, apr
1.4.4, and apr-util 1.3.11
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, May 19, 2011 at 9:40 PM, DW <xf...@hotmail.com> wrote:
> William A. Rowe Jr. wrote:
>> New releases are in progress for each of these projects and are
>> expected to be available in the coming days. The upcoming httpd
>> 2.2.19 will bundle new releases of apr and apr-util which correct
>> the regressions described below. An announcement of these releases
>> will be broadcast.
>>
>
>
> Is there time frame anywhere for 2.2.19 release date?
"soon"
I anticipate that there will be discussion on that by this evening on
dev@httpd.apache.org.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: [Announce] Regressions in httpd 2.2.18, apr 1.4.4, and apr-util
1.3.11
Posted by DW <xf...@hotmail.com>.
William A. Rowe Jr. wrote:
> New releases are in progress for each of these projects and are
> expected to be available in the coming days. The upcoming httpd
> 2.2.19 will bundle new releases of apr and apr-util which correct
> the regressions described below. An announcement of these releases
> will be broadcast.
>
Is there time frame anywhere for 2.2.19 release date?
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [Announce] Regressions in httpd 2.2.18, apr 1.4.4, and apr-util
1.3.11
Posted by DW <xf...@hotmail.com>.
William A. Rowe Jr. wrote:
> New releases are in progress for each of these projects and are
> expected to be available in the coming days. The upcoming httpd
> 2.2.19 will bundle new releases of apr and apr-util which correct
> the regressions described below. An announcement of these releases
> will be broadcast.
>
Is there time frame anywhere for 2.2.19 release date?
[users@httpd] [Announce] Regressions in httpd 2.2.18, apr 1.4.4, and apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
New releases are in progress for each of these projects and are
expected to be available in the coming days. The upcoming httpd
2.2.19 will bundle new releases of apr and apr-util which correct
the regressions described below. An announcement of these releases
will be broadcast.
Note: httpd 2.2.18 bundles apr 1.4.4 and apr-util 1.3.11.
Summary of regressions:
httpd 2.2.18: The ap_unescape_url_keep2f() function signature was changed.
This breaks binary compatibility of a number of third-party modules. In
addition, a regression in apr 1.4.4 (see below) could cause httpd to hang.
apr 1.4.4: A fix in apr 1.4.4 apr_fnmatch() to address CVE-2011-0419
introduced a new vulnerability. A patch is attached and should be used
if httpd workers enter a hung state (100% cpu utilization) after updating
to httpd 2.2.18 or apr-util 1.4.4, or if hangs are seen in other apr
applications which use apr_fnmatch().
apr-util 1.3.11: A fix to LDAP support in apr-util 1.3.11 could cause
crashes with httpd's mod_authnz_ldap in some situations.
[Announce] Regressions in httpd 2.2.18, apr 1.4.4, and apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
New releases are in progress for each of these projects and are
expected to be available in the coming days. The upcoming httpd
2.2.19 will bundle new releases of apr and apr-util which correct
the regressions described below. An announcement of these releases
will be broadcast.
Note: httpd 2.2.18 bundles apr 1.4.4 and apr-util 1.3.11.
Summary of regressions:
httpd 2.2.18: The ap_unescape_url_keep2f() function signature was changed.
This breaks binary compatibility of a number of third-party modules. In
addition, a regression in apr 1.4.4 (see below) could cause httpd to hang.
apr 1.4.4: A fix in apr 1.4.4 apr_fnmatch() to address CVE-2011-0419
introduced a new vulnerability. A patch is attached and should be used
if httpd workers enter a hung state (100% cpu utilization) after updating
to httpd 2.2.18 or apr-util 1.4.4, or if hangs are seen in other apr
applications which use apr_fnmatch().
apr-util 1.3.11: A fix to LDAP support in apr-util 1.3.11 could cause
crashes with httpd's mod_authnz_ldap in some situations.
[Announce] Regressions in httpd 2.2.18, apr 1.4.4, and apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
New releases are in progress for each of these projects and are
expected to be available in the coming days. The upcoming httpd
2.2.19 will bundle new releases of apr and apr-util which correct
the regressions described below. An announcement of these releases
will be broadcast.
Note: httpd 2.2.18 bundles apr 1.4.4 and apr-util 1.3.11.
Summary of regressions:
httpd 2.2.18: The ap_unescape_url_keep2f() function signature was changed.
This breaks binary compatibility of a number of third-party modules. In
addition, a regression in apr 1.4.4 (see below) could cause httpd to hang.
apr 1.4.4: A fix in apr 1.4.4 apr_fnmatch() to address CVE-2011-0419
introduced a new vulnerability. A patch is attached and should be used
if httpd workers enter a hung state (100% cpu utilization) after updating
to httpd 2.2.18 or apr-util 1.4.4, or if hangs are seen in other apr
applications which use apr_fnmatch().
apr-util 1.3.11: A fix to LDAP support in apr-util 1.3.11 could cause
crashes with httpd's mod_authnz_ldap in some situations.
Re: Fwd: DO NOT REPLY [Bug 51219] New: apr_fnmatch infinite loop on
pattern "/*/WEB-INF/"
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, May 19, 2011 at 2:07 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 5/19/2011 12:56 PM, William A. Rowe Jr. wrote:
>> [moving from embargoed to open discussion]
>>
>> On 5/19/2011 9:53 AM, Joe Orton wrote:
>>
>>> b) glibc does not match the pattern "\/" against "/" with FNM_PATHNAME
>>> set, but APR does:
>>>
>>> 0000000052585e22 apr_fnmatch(".*\//", ".//", 2) = 0, glibc=1
>>
>> Do we want to change this behavior? We must still be careful of the
>> special meaning of '/' but we can force a mismatch by dropping the
>> logic at line 218-219, which quietly ignores the leading backslash.
>> Other tests for \/ must remain.
>
> I would argue to keep our behavior, based on typical shell behavior;
>
> $ ls lib\/.svn
>
> tab completion or pressing enter here both work just fine, and this
> should be reflected by our APR_FNM_PATHNAME behavior as well.
BTW, where are we on the 1.4.5-readiness front? Things have been a
bit hectic here and I may have missed something.
Re: Fwd: DO NOT REPLY [Bug 51219] New: apr_fnmatch infinite loop
on pattern "/*/WEB-INF/"
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/19/2011 12:56 PM, William A. Rowe Jr. wrote:
> [moving from embargoed to open discussion]
>
> On 5/19/2011 9:53 AM, Joe Orton wrote:
>
>> b) glibc does not match the pattern "\/" against "/" with FNM_PATHNAME
>> set, but APR does:
>>
>> 0000000052585e22 apr_fnmatch(".*\//", ".//", 2) = 0, glibc=1
>
> Do we want to change this behavior? We must still be careful of the
> special meaning of '/' but we can force a mismatch by dropping the
> logic at line 218-219, which quietly ignores the leading backslash.
> Other tests for \/ must remain.
I would argue to keep our behavior, based on typical shell behavior;
$ ls lib\/.svn
tab completion or pressing enter here both work just fine, and this
should be reflected by our APR_FNM_PATHNAME behavior as well.
Re: Fwd: DO NOT REPLY [Bug 51219] New: apr_fnmatch infinite loop
on pattern "/*/WEB-INF/"
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/20/2011 4:29 AM, Joe Orton wrote:
>
> I've done one short run this morning with the 1.4.x tip. In the diff vs
> glibc, I filtered out patterns with ']', '[' and '/' within [], and also
> patterns containing \/. Only two patterns remained with different
> behaviour:
>
> 000000009199a75c apr_fnmatch("*?[.].", "/..", 4) = 0, glibc=1
> 00000000a504a704 apr_fnmatch("*?*[^aa]", "/.", 4) = 0, glibc=1
>
> the flag used is APR_FNM_PERIOD. APR looks correct for the first, I am
> not sure why the second is matching.
One can argue glibc is correct for both, in that the leading slash
was only significant if APR_FNM_PATHNAME was given. I'd have to reread
the three docs that sometimes disagree on these things. But in any case,
I would not consider this a blocker, and glad to read you found no other
concerning patterns!
Re: Fwd: DO NOT REPLY [Bug 51219] New: apr_fnmatch infinite loop on
pattern "/*/WEB-INF/"
Posted by Joe Orton <jo...@redhat.com>.
On Thu, May 19, 2011 at 12:56:23PM -0500, William Rowe wrote:
> [moving from embargoed to open discussion]
> On 5/19/2011 9:53 AM, Joe Orton wrote:
> > On Wed, May 18, 2011 at 04:11:19PM -0500, William Rowe wrote:
> >> On 5/18/2011 3:55 PM, Joe Orton wrote:
> > b) glibc does not match the pattern "\/" against "/" with FNM_PATHNAME
> > set, but APR does:
> >
> > 0000000052585e22 apr_fnmatch(".*\//", ".//", 2) = 0, glibc=1
>
> Do we want to change this behavior? We must still be careful of the
> special meaning of '/' but we can force a mismatch by dropping the
> logic at line 218-219, which quietly ignores the leading backslash.
> Other tests for \/ must remain.
If the spec doesn't disallow the current behaviour I don't see any harm
in keeping it, the pattern is unambiguous.
...
> I'm omitting your list for another pass through your tests, now that
> we have a fix on 1.4 branch (and trunk) to the issue you caught.
I screwed up the long run I set up last night so it did not complete :(
I've done one short run this morning with the 1.4.x tip. In the diff vs
glibc, I filtered out patterns with ']', '[' and '/' within [], and also
patterns containing \/. Only two patterns remained with different
behaviour:
000000009199a75c apr_fnmatch("*?[.].", "/..", 4) = 0, glibc=1
00000000a504a704 apr_fnmatch("*?*[^aa]", "/.", 4) = 0, glibc=1
the flag used is APR_FNM_PERIOD. APR looks correct for the first, I am
not sure why the second is matching.
Regards, Joe
Re: Fwd: DO NOT REPLY [Bug 51219] New: apr_fnmatch infinite loop
on pattern "/*/WEB-INF/"
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
[moving from embargoed to open discussion]
On 5/19/2011 9:53 AM, Joe Orton wrote:
> On Wed, May 18, 2011 at 04:11:19PM -0500, William Rowe wrote:
>> On 5/18/2011 3:55 PM, Joe Orton wrote:
>>>
>>> I am comparing 1.3.9 with the tip of the 1.4.x branch.
>>
>> If you want to fuzz between system fnmatch (linux, bsd, solaris
>> or wherever) and tip of 1.4.x branch, those difference would also
>> be interesting. I spent most of my time observing the deltas
>> between this new implementation and first bsd followed by linux.
>
>>From looking at diffs of 1.4.x vs glibc, I've found:
>
> a) the "/" inside [] thing discussed already
To recap; refer to 2.13.3 bullet 1. within
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_03
This behavior is optional, we choose to treat a[x/z]b as two segments, while
glibc appears to treat this as a range. Both are correct by spec, and ours
is more efficient in that we predetermine the end of segment. We do the same
for "\/" within [].
> b) glibc does not match the pattern "\/" against "/" with FNM_PATHNAME
> set, but APR does:
>
> 0000000052585e22 apr_fnmatch(".*\//", ".//", 2) = 0, glibc=1
Do we want to change this behavior? We must still be careful of the
special meaning of '/' but we can force a mismatch by dropping the
logic at line 218-219, which quietly ignores the leading backslash.
Other tests for \/ must remain.
> c) different interpretation of [ or ] within []
>
> 00000001a40dee60 apr_fnmatch("[^[.]", "l", 0) = 0, glibc=1
> 00000003947f62f0 apr_fnmatch("[[.]", ".", 0) = 0, glibc=1
We are correct here, implementations vary... in this case "[."...
looks like the introduction to a collating symbol. Stefen and I
spent some time on this (w.r.t. character classes) and determined
that where [:xxxx:] had broken syntax, we would rewind to the open
bracket and treat the '[' as a literal in the list of characters
to match.
> d) apr does not seem to handle back-slash-escapes inside [] correctly:
>
> 00000009058acad3 apr_fnmatch(".[\-\z]", ".z", 3) = 1, glibc=0
This is now fixed, I believe we can roll 1.4.5 now when folks are
satisfied that all defects are gone.
> e) a bunch of weird (invalid?) range specifications:
I'm omitting your list for another pass through your tests, now that
we have a fix on 1.4 branch (and trunk) to the issue you caught.
Re: [Preannounce] APR 1.4.4 vulnerability corrected
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/20/2011 1:44 AM, Rainer Jung wrote:
> On 19.05.2011 18:59, Jeff Trawick wrote:
>> On Thu, May 19, 2011 at 12:40 PM, William A. Rowe Jr.
>> <wr...@rowe-clan.net> wrote:
>>> Does anyone see an issue with this going out right now?
>> apr-util 1.3.11: A fix to LDAP support in apr-util 1.3.11 could cause
>> crashes with httpd's mod_authnz_ldap in some situations.
>
> This is of concern for any user of apr_ldap_rebind_init(). For httpd it
> is only relevant for 2.3.x. Previous versions do not use this function.
So it isn't an issue for announce-2.2, but could be mentioned by
Jim for announce-2.3-beta - thanks Rainer!