CVE-2023-45814 in Bunkum
Summary
by MITRE • 10/25/2023
Bunkum is an open-source protocol-agnostic request server for custom game servers. First, a little bit of background. So, in the beginning, Bunkum's `AuthenticationService` only supported injecting `IUser`s. However, as Refresh and SoundShapesServer implemented permissions systems support for injecting `IToken`s into endpoints was added. All was well until 4.0. Bunkum 4.0 then changed to enforce relations between `IToken`s and `IUser`s. This wasn't implemented in a very good way in the `AuthenticationService`, and ended up breaking caching in such a way that cached tokens would persist after the lifetime of the request - since we tried to cache both tokens and users. From that point until now, from what I understand, Bunkum was attempting to use that cached token at the start of the next request once cached. Naturally, when that token expired, downstream projects like Refresh would remove the object from Realm - and cause the object in the cache to be in a detached state, causing an exception from invalid use of `IToken.User`. So in other words, a use-after-free since Realm can't manage the lifetime of the cached token. Security-wise, the scope is fairly limited, can only be pulled off on a couple endpoints given a few conditions, and you can't guarantee which token you're going to get. Also, the token *would* get invalidated properly if the endpoint had either a `IToken` usage or a `IUser` usage. The fix is to just wipe the token cache after the request was handled, which is now in `4.2.1`. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/25/2023
The vulnerability described in CVE-2023-45814 affects Bunkum, an open-source protocol-agnostic request server designed for custom game servers. This issue emerged from a significant architectural change in version 4.0 where the AuthenticationService was modified to enforce relationships between IToken and IUser objects. The implementation flaw created a critical caching mechanism that persisted tokens beyond their intended request lifetime, establishing a dangerous state where cached tokens could remain active even after expiration. This architectural weakness specifically impacted how authentication tokens were managed within the server's memory space, creating a scenario where objects could exist in memory while their underlying data sources had been removed from the database.
The technical exploitation of this vulnerability relies on a use-after-free condition that occurs when downstream projects like Refresh remove expired token objects from Realm database storage. When subsequent requests attempt to access these cached tokens, they encounter detached objects that cannot properly reference their associated user data through the IToken.User property. This creates a memory management inconsistency where objects remain accessible in cache but are no longer valid in the database context, leading to exceptions that can potentially disrupt service availability or provide unauthorized access paths. The vulnerability specifically manifests in scenarios where cached tokens are accessed after their database records have been deleted, creating a state where the cached object references invalid memory locations.
The operational impact of this vulnerability is constrained by specific conditions required for exploitation, limiting its scope to particular endpoints within the server architecture. Security implications are further mitigated by the fact that attackers cannot guarantee which specific token they will access during exploitation attempts, making the vulnerability somewhat unpredictable in practice. However, the potential for service disruption remains significant since the use-after-free condition can cause application exceptions that may lead to denial of service or unauthorized access to protected resources. The vulnerability's limited attack surface means it primarily affects systems that rely heavily on token caching mechanisms and have specific integration patterns with database management systems like Realm.
The fix implemented in version 4.2.1 addresses the core issue by ensuring that token caches are properly cleared after each request processing cycle, eliminating the persistence of expired tokens in memory. This remediation follows established security principles for memory management and cache invalidation, preventing the accumulation of stale objects that could lead to use-after-free conditions. The solution aligns with common security practices for preventing memory-related vulnerabilities and demonstrates proper resource management in multi-threaded server environments. Organizations using Bunkum should prioritize upgrading to version 4.2.1 to eliminate this vulnerability, as no effective workarounds exist for addressing the underlying caching mechanism flaw. This vulnerability exemplifies the importance of proper resource lifecycle management in server-side applications and highlights how seemingly minor architectural changes can introduce significant security risks through improper cache handling and object reference management.