Executive brief
## Summary
The Cassandra export module (`glances/exports/glances_cassandra/__init__.py`) interpolates `keyspace`, `table`, and `replication_factor` configuration values directly into CQL statements without validation. A user with write access to `glances.conf` can redirect all monitoring data to an attacker-controlled Cassandra keyspace.
## Vulnerable Code
```python # Line 80 f"CREATE KEYSPACE {self.keyspace} WITH " f"replication = {{ 'class': 'SimpleStrategy', 'replication_factor': '{self.replication_factor}' }}"
# Line 94 f"CREATE TABLE {self.table} (plugin text, time timeuuid, stat map<text,float>, PRIMARY KEY (plugin, time)) WITH CLUSTERING ORDER BY (time DESC)"
# Line 112 stmt = f"INSERT INTO {self.table} (plugin, time, stat) VALUES (?, ?, ?)" ```
## Steps to Reproduce
1. Configure `glances.conf` with malicious `table` value: ```ini [cassandra] host = 127.0.0.1 port = 9042 keyspace = glances table = attacker_ks.captured_stats ``` 2. Create attacker keyspace in Cassandra 3. Run `glances --export cassandra` 4. All monitoring data is written to `attacker_ks.captured_stats` instead of the legitimate table
**Confirmed output:** ``` INSERT stmt: INSERT INTO attacker_ks.captured_stats (plugin, time, stat) VALUES (?, ?, ?) Legitimate table row count: 0 Attacker table row count: 1 [CONFIRMED] plugin=cpu, stat={'user': 50.0} ```
## Impact
All exported monitoring data (CPU, memory, network, disk I/O) is silently redirected to an attacker-controlled Cassandra keyspace — both data exfiltration and data loss.
## Proposed Fix
```python import re
def _validate_cql_identifier(name: str) -> str: if not re.match(r'^[a-zA-Z_][a-zA-Z0-9_.]*