Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F47239A.2020701@rowe-clan.net>
Date: Thu, 23 Feb 2012 23:43:54 -0600
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Kurt Seifried <kseifried@redhat.com>
CC: "Steven M. Christey" <coley@linus.mitre.org>,
 APR Developer List <dev@apr.apache.org>,
 mark cox <mark@awe.com>
Subject: Re: Fwd: Re: Hash collision vectors in APR?
References: <4F46E8AE.1060806@redhat.com> <4F46F5AB.7050502@rowe-clan.net>
In-Reply-To: <4F46F5AB.7050502@rowe-clan.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

And responding;

On 2/23/2012 8:27 PM, William A. Rowe Jr. wrote:
> Forwarded for Kurt, as he's not subscribed.
> 
> -------- Original Message --------
> Subject: Re: Hash collision vectors in APR?
> Date: Thu, 23 Feb 2012 18:32:30 -0700
> From: Kurt Seifried <kseifried@redhat.com>
> To: William A. Rowe Jr. <wrowe@rowe-clan.net>
> CC: APR Developer List <dev@apr.apache.org>, Stefan Fritsch <sf@sfritsch.de>,
> "Steven M. Christey" <coley@linus.mitre.org>
> 
> Apologies for the delayed reply.
> 
> CC'ing Steve since I can't actually remove or edit CVE's, just assign
> them.
> 
> On 02/22/2012 09:49 AM, William A. Rowe Jr. wrote:
>> After extensive consultation with the security projects of various
>> APR consumers, it's apparent that there are no actual
>> vulnerabilities to be exploited here.  Contrary to Mr Seifreid's
>> confusion, the recent code changes reflect a possibility of
>> mitigating potential hash collisions, but certainly do not and can
>> not eliminate such risks, and it is up to the developer to select
>> appropriate storage and lookup mechansims for their specific
>> problem domain.
> 
>> These changes do not represent either a security DEFECT nor any
>> actual security FIX.  The APR Project dis-acknowledges the
>> assignment of CVE-2012-0840 as erroneous, and invalid.  Kurt, since
>> you created the defect, please edit it appropriately.
>> security@apache.org is always happy to consult in order to avoid
>> future errors and misinformation.
> 
>> Stefan, please revert your miscommit.  In the future, please run
>> such things past security@apache.org before applying inaccurate
>> external assignments.
> 
> So as I now understand it APR doesn't expose itself in an exploitable
> manner, ergo the hash function, while technically vulnerable, cannot
> really be exploited in any current way, is this correct? Does this
> also take into account future changes/uses that may expose it
> potentially (or is that just not possible)? If you can confirm this
> then I guess the ball is in Steve's court (I'm also not sure how the
> CVE rules/etc. apply in this specific instance).

What is it 'vulnerable' to?  In the c language, I can code 'while (1) ;'
but that doesn't represent a vulnerability in the c language, simply
stupid programming.

The enhanced hash behavior seeks to avoid predictable hash collisions,
but it won't substitute for the intelligent application of apr_hash_t
objects.  It is similar to earlier language enhancements based on the
hash research published back in the early 2000's, but was in reaction
to other languages revisiting this computational issue, NOT to any
reported vulnerability.

This does not in and of itself fix any known SECURITY defect.  The
previous implementation was neither vulnerable nor invulnerable.  Simply,
there is no exploitable code which accepted an unlimited number of new
hash entries submitted by an untrusted entity into an apr_hash_t, as
happened in various cgi form processing applications written in some
other languages.

CVE's aren't used to track all possible future changes/uses/applications
of computing systems, that would be a rather absurd goal.  The Securina
report http://secunia.com/advisories/47862 in particular demonstrates the
disservice that Mitre agents can cause when creating CVE's without research.

CC'ing Mark who might be able to help untangle the mess introduced here.