GHSA-GCCQ-H3XJ-JGVF
Vulnerability from github – Published: 2024-02-12 15:17 – Updated: 2024-10-11 21:35Summary
When processing requests authorization was improperly and insufficiently checked, allowing attackers to access far more functionality than users intended, including to the administrative and moderator functionality of the Pixelfed server.
This vulnerability affects every version of Pixelfed between v0.10.4 and v0.11.9, inclusive. A proof of concept of this vulnerability exists.
Details
In vulnerable versions of Pixelfed (versions before 0.11.11), when the API checked the request for permissions to perform a certain behavior, it did not check that the OAuth Application/Client had granted access to those API endpoints, it only checked if the user was authenticated via an access token, and if the user was the owner of the resource or an admin on the instance.
This meant that an attacker could request an access token for "read" permissions to authenticate you with their application, but the access token that they obtained actually could be used for "write" or even administrative actions, and the user who granted access to their account had zero knowledge of this elevated access.
Proof of Concept
- Create an access token either via 2-legged OAuth flow for the
readscope, or create a Personal Access Tokens with thereadscope. - Using that Access Token, perform a request that would need a particular higher-privilege scope, for instance, following a user or performing an administrative request. (respectively requiring
followoradmin:readandadmin:writescopes in the patched versions) - Observe that despite your access token having
readpermissions, the follow or administrative request was successful.
e.g., Maybe an attacker collects an access token (which expires in 1 year) wants to do something really nasty to an admin, such as disabling federation on their target's pixelfed server. As long as that server has instance.enable_cc configured (defaults to true), then the attacker can use the read scoped access token and perform the following request:
POST /api/admin/config/update
Content-Type: application/json
Accept: application/json
Authorization: Bearer <access token with read scope>
{ "key": "federation.activitypub.enabled": "value": false }
And federation of that pixelfed server would be subsequently disabled, as if the administrator had disabled it.
Impact
This vulnerability affects every local user of a Pixelfed server, and can potentially affect the servers' ability to federate.
Some user interaction is required to setup the conditions to be able to exercise the vulnerability, but the attacker could conduct this attack time-delayed manner, where user interaction is not actively required, since access tokens in Pixelfed have a 1-year lifetime before they expire, and users' often forget to revoke access tokens for applications that they are no longer using.
This also means that Access Tokens that may have been leaked from third-party OAuth Application's databases would be usable for a significant amount of time by potential attackers.
Prior versions
Whilst this vulnerability is listed as >= 0.10.4, there is potential that versions before 0.10.4 are also vulnerable to this sort of security bypass, however, given that the code changed significantly between 0.10.3 and 0.10.4 we've been unable to easily assess if these heavily outdated versions are vulnerable or not to this exploit.
Sponsorship
The work involved in investigating and remediation of this security vulnerability was provided by Nivenly Foundation, for whom we are grateful for their support of the Fediverse and Pixelfed.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "pixelfed/pixelfed"
},
"ranges": [
{
"events": [
{
"introduced": "0.10.4"
},
{
"fixed": "0.11.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-25108"
],
"database_specific": {
"cwe_ids": [
"CWE-280",
"CWE-285",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-12T15:17:23Z",
"nvd_published_at": "2024-02-12T20:15:08Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nWhen processing requests authorization was improperly and insufficiently checked, allowing attackers to access far more functionality than users intended, including to the administrative and moderator functionality of the Pixelfed server.\n\nThis vulnerability affects every version of Pixelfed between `v0.10.4` and `v0.11.9`, inclusive. A proof of concept of this vulnerability exists.\n\n### Details\n\nIn vulnerable versions of Pixelfed (versions before 0.11.11), when the API checked the request for permissions to perform a certain behavior, it did not check that the OAuth Application/Client had granted access to those API endpoints, it only checked if the user was authenticated via an access token, and if the user was the owner of the resource or an admin on the instance.\n\nThis meant that an attacker could request an access token for \"read\" permissions to authenticate you with their application, but the access token that they obtained actually could be used for \"write\" or even administrative actions, and the user who granted access to their account had zero knowledge of this elevated access.\n\n#### Proof of Concept\n\n1. Create an access token either via [2-legged OAuth flow](https://oauth.net/2/grant-types/authorization-code/) for the `read` scope, or create a Personal Access Tokens with the `read` scope.\n2. Using that Access Token, perform a request that would need a particular higher-privilege scope, for instance, following a user or performing an administrative request. (respectively requiring `follow` or `admin:read` and `admin:write` scopes in the patched versions)\n3. Observe that despite your access token having `read` permissions, the follow or administrative request was successful.\n\ne.g., Maybe an attacker collects an access token (which expires in 1 year) wants to do something really nasty to an admin, such as disabling federation on their target\u0027s pixelfed server. As long as that server has `instance.enable_cc` configured (defaults to `true`), then the attacker can use the `read` scoped access token and perform the following request:\n\n```\nPOST /api/admin/config/update\nContent-Type: application/json\nAccept: application/json\nAuthorization: Bearer \u003caccess token with read scope\u003e\n\n{ \"key\": \"federation.activitypub.enabled\": \"value\": false }\n```\n\nAnd federation of that pixelfed server would be subsequently disabled, as if the administrator had disabled it.\n\n### Impact\n\nThis vulnerability affects every local user of a Pixelfed server, and can potentially affect the servers\u0027 ability to federate.\n\nSome user interaction is required to setup the conditions to be able to exercise the vulnerability, but the attacker could conduct this attack time-delayed manner, where user interaction is not actively required, since access tokens in Pixelfed have a 1-year lifetime before they expire, and users\u0027 often forget to revoke access tokens for applications that they are no longer using.\n\nThis also means that Access Tokens that may have been leaked from third-party OAuth Application\u0027s databases would be usable for a significant amount of time by potential attackers.\n\n### Prior versions\n\nWhilst this vulnerability is listed as `\u003e= 0.10.4`, there is potential that versions before `0.10.4` are also vulnerable to this sort of security bypass, however, given that the code changed significantly between `0.10.3` and `0.10.4` we\u0027ve been unable to easily assess if these heavily outdated versions are vulnerable or not to this exploit.\n\n### Sponsorship\n\nThe work involved in investigating and remediation of this security vulnerability was provided by [Nivenly Foundation](https://nivenly.org/), for whom we are grateful for their support of the Fediverse and Pixelfed.",
"id": "GHSA-gccq-h3xj-jgvf",
"modified": "2024-10-11T21:35:07Z",
"published": "2024-02-12T15:17:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pixelfed/pixelfed/security/advisories/GHSA-gccq-h3xj-jgvf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25108"
},
{
"type": "WEB",
"url": "https://github.com/pixelfed/pixelfed/commit/7e47d6dccb0393a2e95c42813c562c854882b037"
},
{
"type": "WEB",
"url": "https://github.com/pixelfed/pixelfed/commit/fd7f5dbb"
},
{
"type": "WEB",
"url": "https://github.com/pixelfed/pixelfed/commit/fd7f5dbba13818f60d1c2b3ab110b499e996aa81"
},
{
"type": "PACKAGE",
"url": "https://github.com/pixelfed/pixelfed"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Pixelfed doesn\u0027t check OAuth Scopes in API routes, giving elevated permissions"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.