Oxia Server Crash via Session Heartbeat Race Condition

A denial-of-service vulnerability exists in Oxia, an open-source distributed database, due to a race condition in the session heartbeat handling mechanism. This vulnerability can be exploited by a remote client to crash the Oxia data server process. The root cause lies in the interaction between the heartbeat() method in session.go and the KeepAlive() function in session_manager.go. Specifically, a time-of-check-to-time-of-use (TOCTOU) gap occurs when KeepAlive() releases the session manager's read lock before calling heartbeat(), allowing the session to be closed concurrently. All Oxia versions up to and including 0.16.1 are affected. Defenders should prioritize implementing detection mechanisms to identify potentially malicious KeepAlive patterns and plan for upgrading to patched versions.

Attack Chain

1. A client establishes a session with the Oxia data server.
2. The client sends regular KeepAlive requests to the server to maintain the session.
3. The server's KeepAlive() function receives the request and releases the session manager's read lock.
4. Before heartbeat() is called, the session expires or is closed due to other factors.
5. The heartbeat() method attempts to send a signal on the closed heartbeatCh channel.
6. Due to the race condition between session closure and the heartbeat() call, the server panics.
7. The Oxia data server process crashes, leading to a denial-of-service.

Impact

Successful exploitation of this vulnerability results in a complete denial-of-service. The Oxia data server process crashes, interrupting all data services relying on that server. The number of affected systems depends on the scale of Oxia deployment. Organizations utilizing Oxia versions up to and including 0.16.1 are vulnerable. The impact can range from service disruption to data unavailability.

Recommendation

• Upgrade to a patched version of Oxia that includes the fixes for the heartbeat handling race condition.
• Implement rate limiting on incoming KeepAlive requests to mitigate the impact of rapid requests (refer to network_connection log source).
• Deploy the provided Sigma rule to detect anomalous patterns of KeepAlive requests (see the Sigma rule targeting webserver logs).
• Monitor webserver logs for unusual spikes in KeepAlive requests (refer to webserver log source).