[ 
https://issues.apache.org/jira/browse/CXF-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606801#comment-17606801
 ] 

Andriy Redko commented on CXF-8765:
-----------------------------------

Thanks [~ben.manes] , I think it would make sense to make EhCache replaceable 
(behind JCache probably).

> Option to remove Ehcache
> ------------------------
>
>                 Key: CXF-8765
>                 URL: https://issues.apache.org/jira/browse/CXF-8765
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-RS Security
>            Reporter: Ben Manes
>            Priority: Major
>
> Is it possible to remove or replace Ehcache with an alternative provider? For 
> example if JCache was used then one could exclude this dependency and 
> register an alternative.
> I would like to ban Ehcache3 from my dependency tree because it is a trivial 
> target for a hash flooding denial of service attack. Unfortunately this has 
> been known and ignored by their team since 2015, and I am still able to 
> trivially introduce this problem in my test workloads (outside of CXF). For 
> example, in one simple case Ehcache takes 67 minutes whereas a simple LRU 
> takes 13 seconds. While I have not seen this exploited, at work we are 
> undergoing SOC-2 compliance and I'd like to shore up known deficiencies by 
> banning it company-wide.
> For background, the problem is that Ehcache uses a forked version of 
> ConcurrentHashMap. That map uses a very cheap and weak hash function because 
> it degrades to a red-black tree on collisions, so the problems are mitigated. 
> Ehcache uses an sampling policy that relies on the entries being uniformly 
> distributed during its traversal, which if not degrades to O\(n\). It is 
> trivial to construct a query pattern that is unfriendly to LRU, triggers an 
> eviction, and results in threads being stuck performing this eviction scan 
> instead of servicing requests. The solution is to update their fork with a 
> more robust hash function or ensure that the keys use a good hashCode, which 
> then drops this runtime to 1.4 minutes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to