Details
Description
The YAML library used when parsing YAML configuration files in Cassandra by default allows configuration files to trigger instantiating arbitrary objects (which in turn may allow the provider of that value to execute arbitrary code as the cassandra process).
Because Cassandra only accepts configuration files from trusted sources, this is strictly speaking not a security problem. If downstream integrators allow less-trusted users to provide values that are passed into configuration files, it is up to them to validate those do not contain unexpected values. That said, it would be nice to harden against such scenario's.
There was a previous attempt to apply such hardening in CASSANDRA-18150. However, the change in https://github.com/apache/cassandra/commit/e7f55ab8c3bd6bac4c87354afec231d7237c35b8 is not effective: the class hierarchy is
rather confusing: org.yaml.snakeyaml.constructor.Constructor extends from org.yaml.snakeyaml.constructor.SafeConstructor, but removes some of its safety measures. Notably, it adds back generic constructors:
this.yamlConstructors.put((Object)null, new ConstructYamlObject());
this.yamlClassConstructors.put(NodeId.scalar, new ConstructScalar());
this.yamlClassConstructors.put(NodeId.mapping, new ConstructMapping());
this.yamlClassConstructors.put(NodeId.sequence, new ConstructSequence());
Removing them in Cassandra's YamlConfigurationLoader is not entirely trivial, as
it actually uses the generic constructors.