Researchers at JFrog Security have released details of a remote code execution vulnerability with the popular NoSQL database, Apache Cassandra.
The popular database is used by enterprises such as Netflix, Twitter, Constast Contact, Cisco, Reddit and many more. The open source database is also used by devOps and cloud-native development circles and companies that provide cloud-based turnkey solutions.
Cassandra offers a user-defined function (UDF) to perform custom processing of the data in a Java default database. 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.
JFrog notes that Nashorn is not guaranteed to be secure when accepting untrusted code. It advisees any service that allows such behavior to wrap the Nashorn execution in the sandbox.
Read: What You Need To Know About The Log4j Vulnerability
When researching the Cassandra UDF sandbox implementation, the team discovered a mix of specific non-default configuration options that could allow hackers to abuse the Nashorn engine by escaping the sandbox and achieve remote code execution. The Cassandra vulnerability is reported as CVE-2021-44521 (CVSS 8.4).
Cassandra deployments are vulnerable when the cassandra.yaml configuration file contains the following:
enable_user_defined_functions: true enable_scripted_user_defined_functions: true enable_user_defined_functions_threads: falseNote that these are the only non-default configuration options required, since when enabling UDFs, all users are allowed to create and execute arbitrary UDFs. This includes anonymous logins, which are enabled by default (
authenticator=AllowAllAuthenticator).Note that Cassandra is also configurable via the Config.java configuration file, that supports the same flags as above.
According to JFrog, it is recommended to upgrade users on the following versions;
3.0.x users should upgrade to 3.0.26
3.11.x users should upgrade to 3.11.12
4.0.x users should upgrade to 4.0.2
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.
Users that want their UDFs to interact with elements outside the sandbox (and don’t mind the potential security risk) can turn on the flag to restore the legacy behavior (not recommended!).
For further remediation and mitigation tips, visit JFrog’s CVE-2021-4451 blog.
If you enjoyed this article and want to receive more valuable industry content like this, click here to sign up for our digital newsletters!
Leave a Reply