[BUG] Possible DoS attack vector with forged realm IDs

[adutra]

Is this a possible security vulnerability?

• This is NOT a possible security vulnerability

Describe the bug

So this is a bit of a security vulnerability, but it's already public, and we don't have any official release yet, so 🤷‍♂️

It is possible for a malicious actor to cause Polaris to OOM by flooding the server with requests having random realm IDs.

This is possible because a) the default RealmContextResolver does not validate that the realm exists and b) many components maintain an unbounded cache of objects keyed by realm ID, e.g.:

• RealmScopeContext
• RealmEntityManagerFactory
• RealmTokenBucketRateLimiter
• LocalPolarisMetaStoreManagerFactory

I suggest the following mitigation measures:

• The default RealmContextResolver MUST validate the realm IDs – which means that we need to persist realms in the database or somewhere else (maybe in configuration?)
• Any components caching by realm ID should use a bounded cache with proper eviction policies.

To Reproduce

No response

Actual Behavior

No response

Expected Behavior

No response

Additional context

No response

System information

No response

[adutra]

Neither the default realm context resolver nor the default call context resolver seems suitable for production usage:

polaris/service/common/src/main/java/org/apache/polaris/service/context/DefaultRealmContextResolver.java

Line 50 in 85f0beb

// Since this default resolver is strictly for use in test/dev environments, we'll consider

polaris/service/common/src/main/java/org/apache/polaris/service/context/DefaultCallContextResolver.java

Line 40 in 85f0beb

* For local/dev testing, this resolver simply expects a custom bearer-token format that is a

[adutra]

Investigating this a bit more, I think the most problematic aspects are:

1 RealmTokenBucketRateLimiter, because this filter kicks in before the authenticating filter, thus executing itself for any request, even unauthenticated. Since it holds a map of token buckets per realm, this map can grow uncontrollably.
2. The tokens endpoint, because this resource is not protected by the authenticating filter and is invoked for every request, even unauthenticated, thus potentially growing the internal maps in LocalPolarisMetaStoreManagerFactory.

On the bright side, I think that the internal maps would not grow uncontrollably in a "real-life" scenario with EclipseLink and a real database, because the realm initialization would fail on an unknown realm:

polaris/extension/persistence/eclipselink/src/main/java/org/apache/polaris/extension/persistence/impl/eclipselink/PolarisEclipseLinkMetaStoreSessionImpl.java

Line 181 in aee3a02

properties.put(JDBC_URL, properties.get(JDBC_URL).replace("{realm}", realm));

And that initialization would be triggered by the DefaultCallContextResolver that is invoked in the PolarisApplication.ContextResolverFilter, which is the very first filter to execute. So I believe that un unknown realm would throw an exception here:

polaris/dropwizard/service/src/main/java/org/apache/polaris/service/dropwizard/PolarisApplication.java

Line 510 in b844686

callContextResolver.resolveCallContext(

That said, it still feels a bit fragile to attempt to create a meta store session for any realm, even unknown, even if from an unauthenticated request, only to see the attempt fail.

(Also, EclipseLink with the default jdbc:h2:file datasource is likely to create meta store sessions for any realm without any form of verification.)

[adutra]

With #594 we have a first step into properly mitigating this issue. It makes it impossible, using the default realm resolver, to inject unknown realms into the application.