[
https://issues.apache.org/jira/browse/CXF-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8765:
------------------------------
Fix Version/s: 4.1.0
3.7.0
(was: 4.0.0)
(was: 3.6.0)
> 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
> Assignee: Andriy Redko
> Priority: Major
> Fix For: 4.1.0, 3.7.0
>
>
> 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)
