CWE-566
AllowedAuthorization Bypass Through User-Controlled SQL Primary Key
Abstraction: Variant · Status: Incomplete
The product uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.
11 vulnerabilities reference this CWE, most recent first.
GHSA-VW63-824V-QF2J
Vulnerability from github – Published: 2024-06-02 22:32 – Updated: 2024-06-17 15:14Impact
A user with an administrator, project_admin, or project_maintainer role could utilize and exploit SQL Injection to allow the execution of any Postgres function or the extraction of sensitive information from the database through this API:
GET /api/v2.0/projects/{project_name}/repositories/{repository_name}/artifacts/{reference}/scan/{report_id}/log
The SQL injection might happen in the code:
https://github.com/goharbor/harbor/blob/9b7c1a2274fbc5ea16e19a484532f86c08926577/src/pkg/task/task.go#L241
Because raw SQL executed in ormer.Raw(Sql).QueryRows() is PrepareStatement. In the driver of Postgres, one PrepareStatement must contain only ONE SQL command, see https://www.postgresql.org/docs/15/libpq-exec.html#LIBPQ-PQPREPARE. The SQL should start with:
SELECT * FROM task WHERE extra_attrs::jsonb->'report_uuids' @>
Adding a delete/update operation by appending malicious content to the current SQL is impossible. Furthermore, the query result of the task is just an intermediate result, the task ID is used to locate the job log file, and the response only contains the content of the job log file. so this vulnerability can be used to execute SQL functions, but it can't leak any useful information to the response.
Harbor >=v2.8.1, >=2.9.0, >=2.10.0 are impacted.
Patches
Harbor v2.8.6, v2.9.4, v2.10.2 fixes this issue.
Workarounds
There is no workaround for this issue.
Credits
Thanks Taisei Inoue (taisei.inoue@gmo-cybersecurity.com)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/goharbor/harbor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.8.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/goharbor/harbor"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0"
},
{
"fixed": "2.9.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/goharbor/harbor"
},
"ranges": [
{
"events": [
{
"introduced": "2.10.0"
},
{
"fixed": "2.10.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-22261"
],
"database_specific": {
"cwe_ids": [
"CWE-566"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-02T22:32:40Z",
"nvd_published_at": "2024-06-11T00:15:13Z",
"severity": "LOW"
},
"details": "### Impact\n\nA user with an administrator, project_admin, or project_maintainer role could utilize and exploit SQL Injection to allow the execution of any Postgres function or the extraction of sensitive information from the database through this API:\n```\nGET /api/v2.0/projects/{project_name}/repositories/{repository_name}/artifacts/{reference}/scan/{report_id}/log\n```\nThe SQL injection might happen in the code: \n\nhttps://github.com/goharbor/harbor/blob/9b7c1a2274fbc5ea16e19a484532f86c08926577/src/pkg/task/task.go#L241\n\nBecause raw SQL executed in ormer.Raw(Sql).QueryRows() is PrepareStatement. In the driver of Postgres, one PrepareStatement must contain only ONE SQL command, see https://www.postgresql.org/docs/15/libpq-exec.html#LIBPQ-PQPREPARE. The SQL should start with:\n```\nSELECT * FROM task WHERE extra_attrs::jsonb-\u003e\u0027report_uuids\u0027 @\u003e\n```\nAdding a delete/update operation by appending malicious content to the current SQL is impossible. Furthermore, the query result of the task is just an intermediate result, the task ID is used to locate the job log file, and the response only contains the content of the job log file. so this vulnerability can be used to execute SQL functions, but it can\u0027t leak any useful information to the response.\n\nHarbor \u003e=v2.8.1, \u003e=2.9.0, \u003e=2.10.0 are impacted.\n\n### Patches\nHarbor v2.8.6, v2.9.4, v2.10.2 fixes this issue.\n\n### Workarounds\nThere is no workaround for this issue.\n\n### Credits\n\nThanks Taisei Inoue ([taisei.inoue@gmo-cybersecurity.com](mailto:taisei.inoue@gmo-cybersecurity.com))",
"id": "GHSA-vw63-824v-qf2j",
"modified": "2024-06-17T15:14:41Z",
"published": "2024-06-02T22:32:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/goharbor/harbor/security/advisories/GHSA-vw63-824v-qf2j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22261"
},
{
"type": "PACKAGE",
"url": "https://github.com/goharbor/harbor"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2024-2916"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "SQL Injection in Harbor scan log API"
}
Mitigation
Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data. Use an "accept known good" validation strategy.
Mitigation
Use a parameterized query AND make sure that the accepted values conform to the business rules. Construct your SQL statement accordingly.
No CAPEC attack patterns related to this CWE.