GHSA-4227-9989-jrhx: Go/github.com/perses/perses vulnerability
Impact
The datasource proxy authorizes the caller on the Datasource scope, then resolves and decrypts any Secret named in the request body with no Secret-scope check.
Datasource and Secret are distinct, independently grantable role scopes, so an operator can grant datasource access without secret access. The proxy and the service to create a datasource does not verify that the operator has the correct right.
A user holding only GlobalDatasource:create can create a GlobalDatasource and attached to it a GlobalSecret without having the right to get access to. The user can also do the same by using the unSaved datasource feature proposed by the proxy used to verify the connectivity to the datasource before creating the resource.
As soon as you can attach a secret that you don't have right to see, you can then create a Datasource that you control and then read anything send by Perses. Which include the secret in plain text. You can then have access to the secret without being granted to.
The project-scoped variant does the same within a project.
Patches The proxy and the service to create the datasource is verifying if you have the right to read a secret if a secret is attached to the datasource. This is patch in v0.54.0-rc.0
Workarounds This issue can be avoided by using the provisioning to create the datasource and by removing the right to create datasource.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/perses/persesto a version that resolves this vulnerability.Fixed in 0.54.0-rc.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in v0.54.0-rc.0 - Compensating control
Avoid the affected path by using the provisioning mechanism to create the datasource instead of the proxy/service flow described; additionally remove the right to create datasource (e.g., do not grant datasource creation permissions to operators who should not access secrets).
- Operational
If any secrets were exposed in the request body/provisioning ("included in plain text"), treat them as compromised and rotate/revoke any affected credentials/secrets after applying the fix.
Event History
Frequently Asked Questions
Can a user without permission to view a secret access its contents?
Yes. A user with only GlobalDatasource:create can attach a GlobalSecret they are not allowed to access to a datasource they control, causing Perses to send the secret to that datasource in plain text.
Does this require creating a saved datasource?
No. The unsaved datasource connectivity-check feature can also be used to attach a secret and expose its contents before the datasource resource is created.
Is the issue limited to global resources?
No. The project-scoped datasource and secret variants have the same authorization issue within a project.
What authorization check was added by the patch?
The proxy and datasource-creation service verify that the caller has permission to read a referenced secret before allowing it to be attached to a datasource.