CVE-2024-9264 - Grafana’s Experimental SQL Expressions Let Attackers Inject Code with `duckdb`

Grafana is one of the most popular open-source analytics and monitoring tools out there. But sometimes, new features can bring new risks – and CVE-2024-9264 proves that. In this post, you’ll learn step-by-step how this vulnerability works, how attackers could exploit it, and how to protect yourself.

> TL;DR: The experimental SQL Expressions feature lets anyone with VIEWER access run malicious queries using duckdb if the binary is on the system. This can lead to command injection and local file inclusion.

What Happened?

Grafana’s SQL Expressions (an experimental feature) allows users to run SQL queries and do cool stuff like calculations and data transformations right inside their dashboards. When Grafana runs these queries with the DuckDB engine via its binary, it doesn’t properly sanitize user inputs.

That means that if an attacker puts something dangerous into a SQL query, Grafana will hand it directly to DuckDB, where it might get executed as a system command — or even worse, let an attacker include files from the server.

Access Needed: Any user with at least VIEWER rights on Grafana

- Not affected by default: DuckDB is *not* installed with Grafana by default, but some Grafana admins may add it for advanced analytics

Example Exploit: Reading System Files

Suppose you have access to Grafana as a viewer. You create a panel that runs a SQL Expression. The following crafted SQL input could leak sensitive files:

SELECT read_file('/etc/passwd')

If DuckDB supports the read_file() function (or if you know of a similar function), this would read the server’s /etc/passwd and return its content right on your Grafana screen.

If the version of DuckDB supports the system() SQL function (experimentally)

SELECT system('cat /etc/shadow')

This would run the command cat /etc/shadow and could output the most sensitive password hashes on UNIX systems.

General Injection Input

Any input field in your SQL Expression panel could be abused. Here’s a mock-up of how a malicious input might look in a JSON snippet for a panel:

{
  "expression": "SELECT read_file('/home/grafana/.ssh/id_rsa')",
  "type": "sql"
}

Warning: Only in a controlled environment! Do not attack systems you do not own.

1. Set Up Grafana: Install Grafana, enable SQL Expressions, and make sure duckdb is on your $PATH.
2. Give Yourself Viewer Access: Log in as a viewer or use demo/demo or other low-privilege accounts.

`sql

SELECT read_file('/etc/hostname')

Very low privilege needed: Any VIEWER user can trigger this.

- Post-auth RCE/LFI: It’s not full remote code execution out of the box, but allows file reads and potentially code execution if more DuckDB tricks are available.
- Path requirement: Attack only works if duckdb is installed and exposed — but many analytics setups do this for extra power.

Original Sources and References

- Grafana Security Advisory (CVE-2024-9264)
- NVD Record for CVE-2024-9264
- DuckDB Documentation
- Grafana: SQL Expressions

Mitigation

- Remove DuckDB Binary: If you don’t need it, delete or restrict duckdb from Grafana’s $PATH.
- Upgrade Grafana: Grafana patched this behavior after early June 2024. Upgrade to the latest version!

Conclusion

Experimental features are cool — but they’re risky. CVE-2024-9264 teaches us to watch out for any code path that handles user input and brings in outside tools. If you run dashboards and let others view or edit them, always double-check what new features are enabled and what could go wrong. Stay sharp!

Want to go deeper? Check out the Grafana advisory for CVE-2024-9264 and NVD entry.

Timeline

Published on: 10/18/2024 04:15:04 UTC
Last modified on: 10/18/2024 12:52:33 UTC