Apache Cassandra users urged to upgrade after vulnerability disclosed

Users of Apache Cassandra are being urged to upgrade their versions after JFrog’s Security Research team disclosed a remote code execution vulnerability that they said is “easy to exploit and has the potential to wreak havoc on systems.”

Shachar Menashe, senior director of security research at JFrog, told ZDNet that even though these new vulnerabilities do not affect Apache Cassandra default installations where User Defined Functions (UDFs) are disabled, many Cassandra configurations enable them, causing the instance to be vulnerable to an RCE or DoS attack. 

“We recommend looking at your Cassandra configuration and — if UDFs are enabled — take the appropriate steps to remediate,” Menashe said.

In a blog post, the JFrog’s Security Research team explained that CVE-2021-44521 was given a CVSS of 8.4 but said it only affects non-default configurations of Cassandra.

They noted that Netflix, Twitter, Urban Airship, Constant Contact, Reddit, Cisco, OpenX, Digg, CloudKick and more use Cassandra because it is a “highly scalable, distributed NoSQL database that is extremely popular due to the benefits of its distributed nature.”

“Cassandra offers the functionality of creating user-defined-functions (UDFs) to perform custom processing of data in the database. Cassandra UDFs can be written by default in Java and JavaScript. In JavaScript it uses the Nashorn engine in the Java Runtime Environment (JRE) which is a JavaScript engine that runs on top of the Java Virtual Machine (JVM),” JFrog’s security researchers said. 

“Nashorn is not guaranteed to be secure when accepting untrusted code. Therefore, any service that allows such behavior must always wrap the Nashorn execution in a sandbox. As we were researching the Cassandra UDF sandbox implementation, we realized that a mix of specific (non-default) configuration options could allow us to abuse the Nashorn engine, escape the sandbox and achieve remote code execution. This is the vulnerability that we reported as CVE-2021-44521.”

Deployments become vulnerable to the issue when the cassandra.yaml configuration file contains certain definitions described in the blog, and JFrog said it also found other issues with those running Cassandra on some non-default configurations.

They urged Apache Cassandra 3.0.x users to upgrade to 3.0.26, adding that 3.11.x users should upgrade to 3.11.12 and 4.0.x users should upgrade to 4.0.2. All of the updated versions resolve CVE-2021-44521. 

There are also several mitigations for those who cannot upgrade their Cassandra instances. Users can disable UDFs, if they are not actively used, by setting enable_user_defined_functions to false, and if UDFs are needed, users can set enable_user_defined_functions_threads to true. 

Users can also remove the permissions of creating, altering and executing functions for untrusted users by removing the following permissions: ALL FUNCTIONS, ALL FUNCTIONS IN KEYSPACE and FUNCTION for CREATE, ALTER and EXECUTE queries.

Netenrich threat hunter John Bambenek said that while this is not as serious as Log4j, it does have the appearance of something that is mobile and potentially widespread. 

“Even though it requires non-default user configuration settings, I suspect that the settings are common in many applications around the world. Unfortunately, there is no way to know exactly how many installations are vulnerable and this is likely the kind of vulnerability that will be missed by automated vulnerability scanners,” Bambenek said. 

“Enterprises will have to go into the configuration files of every Cassandra instance to determine what their risk is.”

Mike Parkin, an engineer at Vulcan Cyber, noted that any organization using Cassandra should be able to check their configuration easily, especially if they have configuration or risk management software, and correct it if it’s vulnerable.