Return-Path: 
 <dev-return-24091-apmail-apr-dev-archive=apr.apache.org@apr.apache.org>
X-Original-To: apmail-apr-dev-archive@www.apache.org
Delivered-To: apmail-apr-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 232D9537E
	for <apmail-apr-dev-archive@www.apache.org>;
 Tue, 10 May 2011 18:26:40 +0000 (UTC)
Received: (qmail 290 invoked by uid 500); 10 May 2011 18:26:39 -0000
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 203 invoked by uid 500); 10 May 2011 18:26:39 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:dev@apr.apache.org>
List-Help: <mailto:dev-help@apr.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@apr.apache.org>
List-Id: <dev.apr.apache.org>
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 195 invoked by uid 99); 10 May 2011 18:26:39 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 May 2011 18:26:39 +0000
X-ASF-Spam-Status: No, hits=0.7 required=5.0
	tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [173.201.192.236] (HELO
 p3plsmtpa07-07.prod.phx3.secureserver.net) (173.201.192.236)
    by apache.org (qpsmtpd/0.29) with SMTP; Tue, 10 May 2011 18:26:30 +0000
Received: (qmail 22669 invoked from network); 10 May 2011 18:26:08 -0000
Received: from unknown (76.252.112.72)
  by p3plsmtpa07-07.prod.phx3.secureserver.net (173.201.192.236) with ESMTP;
 10 May 2011 18:26:07 -0000
Message-ID: <4DC9832D.50702@rowe-clan.net>
Date: Tue, 10 May 2011 13:25:49 -0500
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mark J Cox <mark@awe.com>
CC: "William A. Rowe Jr." <wrowe@apache.org>,
 private@subversion.apache.org, Jeff Trawick <trawick@gmail.com>,
 "security@httpd.apache.org" <security@httpd.apache.org>,
 Jim Jagielski <jim@jagunet.com>, APR Developer List <dev@apr.apache.org>
Subject: Re: fnmatch rewrite in apr, apr 1.4.3
References: <BANLkTikt0Lgc=ww4pfY-XBmCk1YzYmr9pw@mail.gmail.com>
	<4DC5D5A8.7060205@apache.org>
 <BANLkTi=BSOBT=Qby+JFgSrZhLLe+LJ6Ciw@mail.gmail.com>
In-Reply-To: <BANLkTi=BSOBT=Qby+JFgSrZhLLe+LJ6Ciw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

On 5/10/2011 10:02 AM, Mark J Cox wrote:
>> httpd 2.2.18 rolls in the next six hours, so to the extent that sharing
>> issues with apr/apr-util between httpd and svn is an issue for mod_dav_svn,
>> we should be in good shape midweek to broadcast any cautions and upgrade
>> advisories.
> 
> So is the plan to have an APR security advisory timed for when httpd
> 2.2.18 is released this week?

Not certain, with respect to httpd, this short statement is probably
enough for the announcement;

  If 'Options Indexes' is configured, an untrusted adminstrator or
  user has control of the contents of the indexed directory, or there
  are very long file paths (e.g. > <n> URL characters) there is the
  possibility of excessive stack memory consumption.  Users are
  cautioned to move to apr 1.4.4 (included in httpd 2.2.18), or to
  configure 'IndexOptions IgnoreClient' in the same configuration
  contexts where 'Options Indexes' is enabled.

In conjunction with svn 1.6.9 I suspect this might demand a CVE, and
that was when I intended that we make plain what APR 1.4.4 corrects, in
conjunction with their other announcement.

> Note that the reporter separately contacted Red Hat yesterday and
> reported the issue (since our site happens to have directories/files
> served by autoindex long enough for it to matter). We'd want to hold
> off updates until the ASF announcement.

I was under the impression this was sensitive to the number of path
components as opposed to the length of the resource name.

In your estimation, does this demand a CVE?  Is there a relevant CVE
already assigned to the BSD operating system?

I was never able to trigger this using win32 default thread stack size.