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

["Ben Manes (Jira)" <ji...@apache.org>]

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

Ben Manes edited comment on CXF-8765 at 1/5/25 8:25 PM:
--------------------------------------------------------

 
Unfortunately I am still able to reproduce this denial of service attack on Ehcache. Running a sql database workload trace took 22.5 minutes on the latest Ehcache3 for a 28% hit rate, 42s if I override the key's hashCode using xxHash but drops to a 21.97% hit rate, while a a simple LRU (e.g. LinkedHashMap) is 6.9s at 20.3% hit rate, and Caffeine is 7.6s at a 45.8% hit rate.

Since this is a problem that gets worse with the cache size, if yours are small then it might not be a problem worth your time. If so, though, the WSS4J's usage of a disk cache would be seem unnecessary (defaults at 5,000 heap entries + 10 mb disk). JCache is dead so even if the API was rich enough the migration might not be very beneficial in retrospect.

I still find it very frustrating their disinterest to fix this exploit since a developer might actually want a moderately sized cache and be surprised, and that this has was disclosed to them during their pre-release (3.0-M4) and promptly swept under the rug.

 
{code:java}
java.lang.Thread.State: RUNNABLE
    at org.ehcache.impl.internal.concurrent.ConcurrentHashMap$Traverser.advance(ConcurrentHashMap.java:3410)
    at org.ehcache.impl.internal.concurrent.ConcurrentHashMap.getEvictionCandidate(ConcurrentHashMap.java:6493)
    at org.ehcache.impl.internal.store.heap.SimpleBackend.getEvictionCandidate(SimpleBackend.java:53)
    at org.ehcache.impl.internal.store.heap.OnHeapStore.evict(OnHeapStore.java:1579)
    at org.ehcache.impl.internal.store.heap.OnHeapStore.enforceCapacity(OnHeapStore.java:1558)
    at org.ehcache.impl.internal.store.heap.OnHeapStore.put(OnHeapStore.java:365)
    at org.ehcache.core.Ehcache.doPut(Ehcache.java:93)
    at org.ehcache.core.EhcacheBase.put(EhcacheBase.java:187){code}
 


was (Author: ben.manes):
 
Unfortunately I am still able to reproduce this denial of service attack on Ehcache. Running a sql database workload trace took 22.5 minutes on the latest Ehcache3 for a 28% hit rate, 42s if I override the key's hashCode using xxHash but drops to a 21.97% hit rate, while a a simple LRU (e.g. LinkedHashMap) is 6.9s at 20.3% hit rate, and Caffeine is 7.6s at a 45.8% hit rate.

Since this is a problem that gets worse with the cache size, if yours are small then it might not be a problem worth your time. If so, though, the WSS4J's usage of a disk cache would be seem unnecessary (defaults at 5,000 heap entries + 10 mb disk). JCache is dead so even if the API was rich enough the migration might not be very beneficial in retrospect.

I still find it very frustrating their disinterest to fix this exploit since a developer might actually want a moderately sized cache and be surprised, and that this has was disclosed to them during their pre-release (3.0-M3) and promptly swept under the rug.

 
{code:java}
java.lang.Thread.State: RUNNABLE
    at org.ehcache.impl.internal.concurrent.ConcurrentHashMap$Traverser.advance(ConcurrentHashMap.java:3410)
    at org.ehcache.impl.internal.concurrent.ConcurrentHashMap.getEvictionCandidate(ConcurrentHashMap.java:6493)
    at org.ehcache.impl.internal.store.heap.SimpleBackend.getEvictionCandidate(SimpleBackend.java:53)
    at org.ehcache.impl.internal.store.heap.OnHeapStore.evict(OnHeapStore.java:1579)
    at org.ehcache.impl.internal.store.heap.OnHeapStore.enforceCapacity(OnHeapStore.java:1558)
    at org.ehcache.impl.internal.store.heap.OnHeapStore.put(OnHeapStore.java:365)
    at org.ehcache.core.Ehcache.doPut(Ehcache.java:93)
    at org.ehcache.core.EhcacheBase.put(EhcacheBase.java:187){code}
 

> 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: 3.6.6, 4.0.7, 4.1.1
>
>
> 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)