Page MenuHomePhabricator

Grafana may allow access to API unauthenticated [CVE-2021-27358]
Closed, ResolvedPublicSecurity


Affiliation: Researcher -

This was reported to Miraheze for our instance and I discussed with this @akosiaris on IRC so here's a heads up as we now have a POC.

Running this command without authentication should incorrectly allow anyone to create a dashboard and therefore potentially can cause a DoS. This was previously described in and is supposed to be fixed in 5.4.5 and 6.3.4, but doesn't seem to be fixed in the 7.x series.

curl -s XPOST -H "Accept: application/json" -H "Content-Type: application/json" -d '{"dashboard": {}}' | json_pp

You may want restrict access to your API via another means and we are raising this with grafana.


Author Affiliation
Other (Please specify in description)

Event Timeline

RhinosF1 created this object with visibility "Custom Policy".
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Just to update we have sent an email to Grafana's security team.

Triaging high as there's an active POC. I do note that wikimedia are running 7.1.3 compared to our 7.4.

Obviously I haven't tested on wikimedia as that would be irresponsible without your assistance (and I'm doing a lot of this from my phone with help from Paladox + Southparkfan).

RhinosF1 changed the subtype of this task from "Task" to "Security Issue".Feb 14 2021, 5:01 PM
RhinosF1 changed Author Affiliation from N/A to Other (Please specify in description).
RhinosF1 moved this task from Radar to Miraheze-Linked on the User-RhinosF1 board.
Reedy updated the task description. (Show Details)

This needs a closer look,

We applied the Grafana update which was supposed to fix this back in September 2019 in

Grafana Labs fixed this in which introduced a new configuration directive public_mode which defaults to "false". We don't apply this setting either in our puppetised grafana.ini, so we should be using the implicit default of "false" already:

Also reproducible with grafana2001, which is running the latest 7.4.1 upstream.

To rule out some incorrect default option parsing I explicitly added "public_mode = false" to the [snapshots] section of grafana.ini, but that doesn't change anything either.

We have just applied a stopgap with in the form of blocking access to POST /api/snapshots for the public vhost (both grafana.w.o and grafana-labs.w.o)

Interesting comeback of the CVE. Anyway, thanks for the tip @RhinosF1

@Paladox had already reached out to security@grafana and they stated:

You have anonymous access enabled, which means there is anonymous access enabled to the snapshot API. If you require anonymous access you should run Grafana behind an reverse proxy, and filter our requests to the snapshot endpoint.

This is a little surprising since it doesn't reflect the authorization role assigned in our config (which is the read-only "Viewer") and neither the original announcement nor the docs for "public_mode" at mentioned the latter part. But that means that 664224 is doing the right thing and can stay as a permanent setting.

I'll also prepare a PR for Grafana to update the docs for "public_mode". While the amount of intentionally public Grafana installations is probably very low, I'm sure others ran into the same issue.

I sent them a follow up email and they replied with:

public_mode enables snapshots anonymously when running with GF_AUTH_ANONYMOUS_ENABLED=false, 
the inverse is not true, that setting public_mode=false blocks access to the /snapshot endpoint even when GF_AUTH_ANONYMOUS_ENABLED=true 

Having said that, we're looking into the snapshot permissions again at the moment. I will get back to you when I have an answer.

FTR anonymous users can't create snapshots anymore as of Grafana 7.4.2 ( I've imported that version internally and will upgrade

@Paladox: Can you get this pushed to us as well?

MoritzMuehlenhoff claimed this task.

I verified that 7.4.2. correctly restricts the snapshots API (requests only yield a "message" : "Unauthorized"), but we'll still keep the Apache config as defense in depth.

With that all angles are addressed and I'm closing the task. Many thanks to @RhinosF1 for reaching out to us and to @Paladox for reporting this to the Grafana developers!

Thanks for all the help in investigating this.

@Paladox: Can you get this pushed to us as well?

Done by @Reception123.

Should be good to make public from my side and will do the same with our task unless anyone has any concerns

Many thanks to all for this. I was handled impeccably by all parties involved

sbassett added a subscriber: sbassett.

I reviewed this task for completeness and PII. Making public now per request from @RhinosF1.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".Feb 18 2021, 4:22 PM
RhinosF1 updated the task description. (Show Details)

Added attribution per request of researcher.

This eventually got assigned CVE-2021-27358.

Aklapper renamed this task from Grafana may allow access to API unauthenticated to Grafana may allow access to API unauthenticated [CVE-2021-27358].Fri, Mar 19, 12:48 PM