Arnout Engelen created CASSANDRA-18614:
------------------------------------------
Summary: Restrict the types of objects SnakeYAML is allowed to
instantiate
Key: CASSANDRA-18614
URL: https://issues.apache.org/jira/browse/CASSANDRA-18614
Project: Cassandra
Issue Type: Improvement
Reporter: Arnout Engelen
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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
