Impact

A user with an administrator, projectadmin, or projectmaintainer 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/{projectname}/repositories/{repositoryname}/artifacts/{reference}/scan/{reportid}/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 extraattrs::jsonb->'reportuuids' @> 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)

Description Under OIDC authentication mode, there is a redirecturl parameter exposed in the URL which is used to redirect the current user to the defined location after the successful OIDC login, This redirecturl can be an ambiguous URL and can be used to embed a phishing URL. For example: if a user clicks the URL with a malicious redirecturl: https://<harborhostnmae>/c/oidc/login?redirecturl=https://<redirectdomain> It might redirect the current user without their knowledge to a malicious site, posing a potential risk. To avoid this issue, the redirecturl should be checked if it is a local path when reading it from the original request URL. //src/core/controllers/oidc.go ... redirectURL := oc.Ctx.Request.URL.Query().Get("redirecturl") if !utils.IsLocalPath(redirectURL) { log.Errorf("invalid redirect url: %v", redirectURL) oc.SendBadRequestError(fmt.Errorf("cannot redirect to other site")) return } if err := oc.SetSession(redirectURLKey, redirectURL); err != nil { ... Impact When Harbor is configured with OIDC authentication and users log in via a link outside the Harbor server, it might be vulnerable to an open redirect attack. This attack only involves the OIDC Harbor user, if the current Harbor instance is not configured with OIDC auth, the redirecturl doesn't exist and the Harbor instance is not vulnerable to the open redirect attack.

The following versions of Harbor are involved: <=Harbor 2.8.4, <=Harbor 2.9.2, <= Harbor 2.10.0

Patches Harbor 2.8.5, Harbor 2.9.3, Harbor 2.10.1

Workarounds When the Harbor is configured with OIDC authentication, warn the user not to log into the Harbor through external links.

References N/A

Credit Thanks Arnaud Cordier (arnaud@cordier.work)

Impact Harbor fails to validate the maintainer role permissions when creating/updating/deleting project configurations - API call:

- PUT /projects/{projectnameorid}/metadatas/{metaname} - POST /projects/{projectnameorid}/metadatas/{metaname} - DELETE /projects/{projectnameorid}/metadatas/{metaname}

By sending a request to create/update/delete a metadata with an name that belongs to a project that the currently authenticated and granted to the maintainer role user doesn’t have access to, the attacker could modify configurations in the current project.

BTW: the maintainer role in Harbor was intended for individuals who closely support the project admin in maintaining the project but lack configuration management permissions. However, the maintainer role can utilize the metadata API to circumvent this limitation. It's important to note that any potential attacker must be authenticated and granted a specific project maintainer role to modify configurations, limiting their scope to only that project.

Patches Will be fixed in v2.9.5, v2.10.3 and v2.11.0

Workarounds There are no workarounds available.

Credit Thanks to Ravid Mazon(rmazon@paloaltonetworks.com), Jay Chen (jaychen@paloaltonetworks.com) Palo Alto Networks for reporting this issue.