{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/oxia/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Oxia"],"_cs_severities":["high"],"_cs_tags":["tls","mtls","certificate-validation","oxia","vulnerability"],"_cs_type":"advisory","_cs_vendors":["Oxia"],"content_html":"\u003cp\u003eThe Oxia database platform, specifically versions 0.16.1 and earlier, contains a vulnerability in its TLS configuration parsing. The \u003ccode\u003etrustedCertPool()\u003c/code\u003e function within the \u003ccode\u003ecommon/security/tls.go\u003c/code\u003e file is designed to load trusted Certificate Authority (CA) certificates for mTLS authentication. However, the function only processes the first PEM-encoded certificate block within a specified CA file. This means that if a CA file contains a bundle of certificates, such as an intermediate CA and a root CA, only the first certificate is loaded and the rest are silently discarded. This issue was reported on GitHub as GHSA-7jrq-q4pq-rhm6 and can lead to a significant degradation of security posture.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn administrator configures Oxia to use mTLS for client authentication, specifying a CA bundle file containing both intermediate and root CA certificates via the \u003ccode\u003etrustedCaFile\u003c/code\u003e setting.\u003c/li\u003e\n\u003cli\u003eOxia's \u003ccode\u003etrustedCertPool()\u003c/code\u003e function attempts to load the CA certificates from the specified file.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003epem.Decode()\u003c/code\u003e function is called, but it only parses the first PEM block (e.g., the intermediate CA certificate).\u003c/li\u003e\n\u003cli\u003eSubsequent certificates within the CA bundle (e.g., the root CA certificate) are silently ignored because the code doesn't iterate over all PEM blocks.\u003c/li\u003e\n\u003cli\u003eA legitimate client attempts to connect to Oxia using a certificate chain that is correctly signed by the intermediate CA, which is in turn signed by the root CA.\u003c/li\u003e\n\u003cli\u003eOxia only trusts the intermediate CA certificate that was loaded.\u003c/li\u003e\n\u003cli\u003eCertificate chain validation fails because the root CA is not trusted, resulting in the error \u0026quot;x509: certificate signed by unknown authority\u0026quot;.\u003c/li\u003e\n\u003cli\u003eThe legitimate client connection is rejected, effectively breaking mTLS authentication.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe vulnerability results in the failure of certificate chain validation in mTLS deployments of Oxia. This means that legitimate clients with properly chained certificates are rejected, leading to a denial of service. Operators might be forced to disable client certificate verification, which severely weakens the security posture of Oxia deployments. All Oxia versions up to and including 0.16.1 are vulnerable if TLS with the \u003ccode\u003etrustedCaFile\u003c/code\u003e configuration is used.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch provided by Oxia that iterates over all PEM blocks in the CA file (reference: GHSA-7jrq-q4pq-rhm6).\u003c/li\u003e\n\u003cli\u003eAs a temporary workaround, use CA files containing only a single certificate (the direct issuer of client certificates) for the \u003ccode\u003etrustedCaFile\u003c/code\u003e configuration (reference: GHSA-7jrq-q4pq-rhm6).\u003c/li\u003e\n\u003cli\u003eMonitor Oxia server logs for \u0026quot;x509: certificate signed by unknown authority\u0026quot; errors after configuring mTLS, which may indicate this vulnerability is being triggered.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-30-oxia-tls-failure/","summary":"Oxia's `trustedCertPool()` function fails to parse multi-certificate PEM bundles, leading to certificate chain validation failure and rejection of legitimate clients in mTLS deployments.","title":"Oxia TLS Certificate Chain Validation Failure","url":"https://feed.craftedsignal.io/briefs/2024-01-30-oxia-tls-failure/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Oxia"],"_cs_severities":["high"],"_cs_tags":["denial-of-service","race-condition","oxia"],"_cs_type":"advisory","_cs_vendors":["Oxia"],"content_html":"\u003cp\u003eA 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 \u003ccode\u003eheartbeat()\u003c/code\u003e method in \u003ccode\u003esession.go\u003c/code\u003e and the \u003ccode\u003eKeepAlive()\u003c/code\u003e function in \u003ccode\u003esession_manager.go\u003c/code\u003e. Specifically, a time-of-check-to-time-of-use (TOCTOU) gap occurs when \u003ccode\u003eKeepAlive()\u003c/code\u003e releases the session manager's read lock before calling \u003ccode\u003eheartbeat()\u003c/code\u003e, 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 \u003ccode\u003eKeepAlive\u003c/code\u003e patterns and plan for upgrading to patched versions.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA client establishes a session with the Oxia data server.\u003c/li\u003e\n\u003cli\u003eThe client sends regular \u003ccode\u003eKeepAlive\u003c/code\u003e requests to the server to maintain the session.\u003c/li\u003e\n\u003cli\u003eThe server's \u003ccode\u003eKeepAlive()\u003c/code\u003e function receives the request and releases the session manager's read lock.\u003c/li\u003e\n\u003cli\u003eBefore \u003ccode\u003eheartbeat()\u003c/code\u003e is called, the session expires or is closed due to other factors.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eheartbeat()\u003c/code\u003e method attempts to send a signal on the closed \u003ccode\u003eheartbeatCh\u003c/code\u003e channel.\u003c/li\u003e\n\u003cli\u003eDue to the race condition between session closure and the \u003ccode\u003eheartbeat()\u003c/code\u003e call, the server panics.\u003c/li\u003e\n\u003cli\u003eThe Oxia data server process crashes, leading to a denial-of-service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to a patched version of Oxia that includes the fixes for the heartbeat handling race condition.\u003c/li\u003e\n\u003cli\u003eImplement rate limiting on incoming \u003ccode\u003eKeepAlive\u003c/code\u003e requests to mitigate the impact of rapid requests (refer to network_connection log source).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect anomalous patterns of \u003ccode\u003eKeepAlive\u003c/code\u003e requests (see the Sigma rule targeting webserver logs).\u003c/li\u003e\n\u003cli\u003eMonitor webserver logs for unusual spikes in \u003ccode\u003eKeepAlive\u003c/code\u003e requests (refer to webserver log source).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T12:00:00Z","date_published":"2024-01-09T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-09-oxia-dos/","summary":"A race condition in Oxia's session heartbeat handling allows a remote client to trigger a denial-of-service by sending rapid KeepAlive requests during session expiration or closure, leading to a server crash.","title":"Oxia Server Crash via Session Heartbeat Race Condition","url":"https://feed.craftedsignal.io/briefs/2024-01-09-oxia-dos/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Oxia"],"_cs_severities":["high"],"_cs_tags":["oxia","jwt","token leakage","credential access"],"_cs_type":"advisory","_cs_vendors":["Oxia"],"content_html":"\u003cp\u003eOxia, a distributed database, is vulnerable to exposing sensitive bearer tokens in its debug logs. Specifically, when OpenID Connect (OIDC) authentication fails, the complete JWT, including header, payload, and signature, is logged in plaintext at the DEBUG level. This occurs in versions 0.16.1 and earlier. If debug logging is enabled in production environments, these tokens are written to application logs and potentially any connected log aggregation systems. An attacker gaining access to these logs could then extract valid JWT tokens and use them to impersonate legitimate users. The vulnerability stems from the \u003ccode\u003evalidateTokenWithContext()\u003c/code\u003e function within \u003ccode\u003eoxiad/common/rpc/auth/interceptor.go\u003c/code\u003e. Defenders should ensure that debug logging is disabled in production or implement detections to identify potential token leakage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user attempts to authenticate to an Oxia service using OIDC.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003evalidateTokenWithContext()\u003c/code\u003e function in \u003ccode\u003eoxiad/common/rpc/auth/interceptor.go\u003c/code\u003e is invoked to validate the provided JWT token.\u003c/li\u003e\n\u003cli\u003eIf the token validation fails, the complete token is logged at DEBUG level using \u003ccode\u003eslog.String(\u0026quot;token\u0026quot;, token)\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe debug logs containing the full bearer token are written to the application log files.\u003c/li\u003e\n\u003cli\u003eAn attacker gains unauthorized access to the application log files or the connected log aggregation system.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts valid JWT tokens from the compromised logs.\u003c/li\u003e\n\u003cli\u003eThe attacker replays the extracted JWT token to authenticate as a legitimate user.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to Oxia resources and data, performing actions as the compromised user.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe exposure of bearer tokens can lead to unauthorized access to Oxia resources. An attacker with access to application logs can extract valid JWT tokens and impersonate legitimate users. The impact depends on the privileges associated with the compromised user account. This vulnerability affects all Oxia deployments using OIDC authentication with debug logging enabled in production, potentially impacting a large number of users and sensitive data stored within the database.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnsure DEBUG-level logging is never enabled in production environments as a primary mitigation step (\u003ca href=\"#workarounds\"\u003eWorkarounds\u003c/a\u003e).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule to detect instances of failed authentication attempts where the full bearer token is logged, and investigate immediately ([Sigma rule: Detect Oxia Token Leak in Logs]).\u003c/li\u003e\n\u003cli\u003eUpgrade to a patched version of Oxia that redacts the token in log output, preserving only the last 8 characters.\u003c/li\u003e\n\u003cli\u003eReview and harden access controls for application logs and log aggregation systems to prevent unauthorized access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T12:00:00Z","date_published":"2024-01-09T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-09-oxia-token-leak/","summary":"Oxia exposes the full bearer token, including JWT header, payload, and signature, in debug log messages when OIDC authentication fails, allowing attackers with log access to replay the tokens.","title":"Oxia Bearer Token Exposure in Debug Logs","url":"https://feed.craftedsignal.io/briefs/2024-01-09-oxia-token-leak/"}],"language":"en","title":"CraftedSignal Threat Feed - Oxia","version":"https://jsonfeed.org/version/1.1"}