[
https://issues.apache.org/jira/browse/CXF-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Manes updated CXF-8765:
---------------------------
Description:
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.
was:
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 (with a higher hit rate). 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.
> 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)
