Julian Wälde and Alexander Klink reported a way to degrade performance of the Java Hashtable implementation by filling the hash table with keys with identical hash codes - see bug #770929 for details. The apr developers are looking at adding randomization [1] to apr to mitigate such attacks. It is unknown how such attacks may be mounted against applications using libapr, or what the result might be, but the developers are discussing how best to address this. There is currently no formal patch or commit to apr. [1] http://www.mail-archive.com/dev%40apr.apache.org/msg24439.html
(In reply to comment #0) > There is currently no formal patch or commit to apr. Patches start to appear upstream: http://svn.apache.org/viewvc?view=revision&revision=1231605 http://svn.apache.org/viewvc?view=revision&revision=1231858
The above were reverted. You can try: http://svn.apache.org/viewvc?view=revision&revision=1236642
(In reply to comment #8) > The above were reverted. You can try: > > http://svn.apache.org/viewvc?view=revision&revision=1236642 Actually, I just reverted this as well. It would not be effective.
New commit: http://svn.apache.org/viewvc?view=revision&revision=1236970
Also: http://svn.apache.org/viewvc?view=revision&revision=1237078
And: http://svn.apache.org/viewvc?view=revision&revision=1237507
This was assigned the name CVE-2012-0840: http://seclists.org/oss-sec/2012/q1/391
apr-1.4.6-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
apr-1.4.6-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
There have been a post from William A. Rowe Jr. indicating this should have not been called security upstream: http://thread.gmane.org/gmane.comp.apache.apr.devel/18632/focus=18802 which resulted in: http://svn.apache.org/viewvc?view=revision&revision=1293697 i.e. CHANGES file now says: *) Randomise hashes by providing a seed. Assigned CVE-2012-0840, oCERT-2011-003, but not known to be exploitable. [Bojan Smojver, Branko Čibej, Ruediger Pluem et al.] Bojan, Joe, I guess the randomization itself is not planned to be removed despite the above change.
(In reply to comment #16) > Bojan, Joe, I guess the randomization itself is not planned to be removed > despite the above change. No, it stays. It is a mitigation approach against a potential problem.
Dropping this to low as, reportedly, there is no suitable vector for this to be exploited: http://www.mail-archive.com/dev%40apr.apache.org/msg24609.html