Unquoted Search Path or Element vulnerability in Grafana Agent (Flow mode) on Windows allows Privilege Escalation from Local User to SYSTEM This issue affects Agent Flow: before 0.43.2

Grafana Agent is a telemetry collector for sending metrics, logs, and trace data to the opinionated Grafana observability stack. Prior to versions 0.20.1 and 0.21.2, inline secrets defined within a metrics instance config are exposed in plaintext over two endpoints: metrics instance configs defined in the base YAML file are exposed at /-/config and metrics instance configs defined for the scraping service are exposed at /agent/api/v1/configs/:key. Inline secrets will be exposed to anyone being able to reach these endpoints. If HTTPS with client authentication is not configured, these endpoints are accessible to unauthenticated users. Secrets found in these sections are used for delivering metrics to a Prometheus Remote Write system, authenticating against a system for discovering Prometheus targets, and authenticating against a system for collecting metrics. This does not apply for non-inlined secrets, such as file based secrets. This issue is patched in Grafana Agent versions 0.20.1 and 0.21.2. A few workarounds are available. Users who cannot upgrade should use non-inline secrets where possible. Users may also desire to restrict API access to Grafana Agent with some combination of restricting the network interfaces Grafana Agent listens on through httplistenaddress in the server block, configuring Grafana Agent to use HTTPS with client authentication, and/or using firewall rules to restrict external access to Grafana Agent's API.

Impact

Users running the Synthetic Monitoring agent in their local network are impacted. The authentication token used to communicate with the Synthetic Monitoring API is exposed thru a debugging endpoint. This token can be used to retrieve the Synthetic Monitoring checks created by the user and assigned to the agent identified with that token. The Synthetic Monitoring API will reject connections from already-connected agents, so access to the token does not guarantee access to the checks.

Patches

Fixed version is v0.12.0

Users are advised to rotate the agent tokens.

After upgrading to version v0.12.0 or later, it's recommended that user's of distribution packages (e.g. Debian or RedHat and their derivatives) review the configuration stored in /etc/synthetic-monitoring/synthetic-monitoring-agent.conf, specifically the APITOKEN variable which has been renamed to SMAGENTAPITOKEN.

Workarounds

With all previous versions, it's recommended that users review the agent settings and set the HTTP listening address in a manner that limits the exposure, for example, localhost or a non-routed network, by using the command line parameter -listen-address, e.g. -listen-address localhost:4050.

References

The following changes have been made to address this issue:

- Disable debug endpoint by default - Allow retrieving the token from the environment - Default to listening on localhost

For more information

If you have any questions or comments about this advisory: You can use the Synthetic Monitoring Agent discussions. Issues should be reported in the Synthetic Monitoring Agent issues. Email us at security@grafana.com.