[jira] [Updated] (CXF-8765) Option to remove Ehcache

["Andriy Redko (Jira)" <ji...@apache.org>]

     [ 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)