Vulnerabilities

High-Severity Vulnerability Found in Apache Database System Used by Major Firms

Researchers detail code execution vulnerability in Apache Cassandra

<p style="text-align: center;"><span style="font-size: 11pt; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;"><strong><span><span>Researchers detail code execution vulnerability in Apache Cassandra</span></span></strong></span></p>

Researchers detail code execution vulnerability in Apache Cassandra

JFrog’s security researchers on Tuesday published full technical details on a high-severity remote code execution vulnerability addressed in the latest version of Apache Cassandra.

A distributed NoSQL database that offers high scalability, Cassandra is popular among organizations such as Netflix, Reddit, Twitter, Cisco, Constant Contact, Digg, Urban Airship, OpenX, and more, as well as among cloud-native and DevOps development circles.

Tracked as CVE-2021-44521 (CVSS score of 8.4), the newly patched vulnerability only affects non-default configurations of the database – which mitigates the fact that it is easy to exploit – leading to complete system compromise.

The security error only exists if functionality to create user-defined-functions (UDFs) for custom processing of data is enabled in Cassandra, and can be exploited only if the attacker has enough permissions to create UDFs. The configuration is non-default and it has been documented as unsafe.

[READ: Log4Shell-Like Vulnerability Found in Popular H2 Database]

UDFs in Cassandra can be written in Java and JavaScript, with the latter using the Nashorn engine, which “is not guaranteed to be secure when accepting untrusted code,” meaning that it should run in a sandbox, JFrog explains.

In fact, Cassandra does implement a custom sandbox to restrict the UDF code, but JFrog discovered that, when a series of non-default configuration options are enabled, an attacker could “abuse the Nashorn engine, escape the sandbox and achieve remote code execution.”

Advertisement. Scroll to continue reading.

Specifically, Cassandra deployments are vulnerable when they are configured to allow UDFs and scripted UDFs, but not UDF threads. By default, UDF threads are enabled, meaning that each invoked UDF function runs in a separate thread.

When UDFs are enabled, all users can create and execute arbitrary UDFs, including those logged in anonymously, JFrog explains.

In their technical write-up on CVE-2021-44521, the security firm also explained how it was able to escape Cassandra’s sandbox, and provided a demonstration of their proof-of-concept (PoC) code in action.

The security firm also notes that, during their research, several other issues were identified, including a denial of service attack and a remote code execution exploit via unsafe object deserialization.

CVE-2021-44521 was addressed with the release of Apache Cassandra versions 3.0.26, 3.11.12, and 4.0.2, and users are advised to upgrade to the patched iterations as soon as possible.

“Apache’s fix adds a new flag – allow_extra_insecure_udfs (false by default) which disallows turning off the security manager and blocks access to java.lang.System,” JFrog explains.

Users can also mitigate the impact of this vulnerability by disabling UDFs, by allowing UDF threads (the default configuration), and by denying permissions for untrusted users.

Related: Many Prometheus Endpoints Expose Sensitive Data

Related: HAProxy Vulnerability Leads to HTTP Request Smuggling

Related: Vulnerabilities in NicheStack TCP/IP Stack Affect Many OT Device Vendors

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version