Cloud Native Computing Foundation Harbor prior to 1.8.6 and 1.9.3 has a Privilege Escalation Vulnerability in the VMware Harbor Container Registry for the Pivotal Platform.
Cloud Native Computing Foundation Harbor prior to 1.8.6 and 1.9.3 allows CSRF in the VMware Harbor Container Registry for the Pivotal Platform.
Impact Harbor fails to validate the user permissions to view Webhook policies including relevant credentials configured in different projects the user doesn’t have access to, resulting in malicious users being able to read Webhook policies of other users/projects. API call is
GET /projects/{projectnameorid}/webhook/policies/{webhookpolicyid}
By sending the below request and specifying different Webhook policy ids in the last part of the URL, the malicious user may disclose Webhook policies related to other repositories/projects.: none;">
Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.
Workarounds There are no workarounds available.
For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository
Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Impact Harbor fails to validate the user permissions when updating tag retention policies. API call:
PUT /retentions/{id}
By sending a request to update a tag retention policy with an id that belongs to a project that the currently authenticated user doesn’t have access to, the attacker could modify tag retention policies configured in other projects.
Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.
Workarounds There are no workarounds available.
For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository
Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Impact Harbor fails to validate the user permissions when updating tag immutability policies - API call:
PUT /projects/{projectnameorid}/immutabletagrules/{immutableruleid}
By sending a request to update a tag immutability policy with an id that belongs to a project that the currently authenticated user doesn’t have access to, the attacker could modify tag immutability policies configured in other projects.
Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.
Workarounds There are no workarounds available.
For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository
Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Harbor fails to validate the user permissions when updating p2p preheat policies. By sending a request to update a p2p preheat policy with an id that belongs to a project that the currently authenticated user doesn't have access to, the attacker could modify p2p preheat policies configured in other projects.
Harbor API has a Broken Access Control vulnerability. The vulnerability allows project administrators to use the Harbor API to create a robot account with unauthorized push and/or pull access permissions to a project they don't have access or control for. The Harbor API did not enforce the proper project permissions and project scope on the API request to create a new robot account.
DISPUTED An access control issue in Harbor v1.X.X to v2.5.3 allows attackers to access public and private image repositories without authentication. NOTE: the vendor's position is that this "is clearly described in the documentation as a feature."
Impact Harbor fails to validate the user permissions when reading job execution logs through the P2P preheat execution logs - API call
GET /projects/{projectname}/preheat/policies/{preheatpolicyname}/executions/{executionid}/tasks/{taskid}/logs
By sending a request that attempts to read P2P preheat execution logs and specifying different job ids, malicious authenticatedusers could read all the job logs stored in the Harbor database.
Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.
Workarounds There are no workarounds available.
For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository
Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Cloud Native Computing Foundation Harbor prior to 1.8.6 and 1.9.3 allows SQL Injection via user-groups in the VMware Harbor Container Registry for the Pivotal Platform.
core/api/user.go in Harbor 1.7.0 through 1.8.2 allows non-admin users to create admin accounts via the POST /api/users API, when Harbor is setup with DB as authentication backend and allow user to do self-registration. Fixed version: v1.7.6 v1.8.3. v.1.9.0. Workaround without applying the fix: configure Harbor to use non-DB authentication backend such as LDAP.
A timing condition in Harbor 2.6.x and below, Harbor 2.7.2 and below, Harbor 2.8.2 and below, and Harbor 1.10.17 and below allows an attacker with network access to create jobs/stop job tasks and retrieve job task information.
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.
Impact Harbor fails to validate the user permissions when updating a robot account that belongs to a project that the authenticated user doesn’t have access to. API call:
PUT /robots/{robotid}
By sending a request that attempts to update a robot account, and specifying a robot account id and robot account name that belongs to a different project that the user doesn’t have access to, it was possible to revoke the robot account permissions.
Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.
Workarounds There are no workarounds available.
For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository
Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
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
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)
In Harbor 2.0 before 2.0.5 and 2.1.x before 2.1.2 the catalog’s registry API is exposed on an unauthenticated path.
Impact Sean Wright from Secureworks has discovered an enumeration vulnerability. An attacker can make use of the Harbor API to make unauthenticated calls to the Harbor instance. Based on the HTTP status code in the response, an attacker is then able to work out which resources exist, and which do not. This would likely be accomplished by either providing a wordlist or enumerating through a sequence an unauthenticated attacker is able to enumerate resources on the system. This provides them with information such as existing projects, repositories, etc.
The vulnerability was immediately fixed by the Harbor team.
Issue The following API resources where found to be vulnerable to enumeration attacks: /api/chartrepo/{repo}/prov (POST) /api/chartrepo/{repo}/charts (GET, POST) /api/chartrepo/{repo}/charts/{name} (GET, DELETE) /api/chartrepo/{repo}/charts/{name}/{version} (GET, DELETE) /api/labels?name={name}&scope=p (GET) /api/repositories?projectid={id} (GET) /api/repositories/{reponame}/ (GET, PUT, DELETE) /api/repositories/{reponame}/tags (GET) /api/repositories/{reponame}/tags/{tag}/manifest?version={version} (GET) /api/repositories/{reponame/{tag}/labels (GET) /api/projects?projectname={name} (HEAD) /api/projects/{projectid}/summary (GET) /api/projects/{projectid}/logs (GET) /api/projects/{projectid} (GET, PUT, DELETE) /api/projects/{projectid}/metadatas (GET, POST) /api/projects/{projectid}/metadatas/{metadataname} (GET, PUT)
Known Attack Vectors Successful exploitation of this issue will lead to bad actors identifying which resources exist in Harbor without requiring authentication for the Harbor API.
Patches If your product uses the affected releases of Harbor, update to version 1.10.3 or 2.0.1 to patch this issue immediately.
https://github.com/goharbor/harbor/releases/tag/v1.10.3 https://github.com/goharbor/harbor/releases/tag/v2.0.1
Workarounds There is no known workaround
For more information If you have any questions or comments about this advisory, contact cncf-harbor-security@lists.cncf.io View our security policy at https://github.com/goharbor/harbor/security/policy
Cloud Native Computing Foundation Harbor prior to 1.8.6 and 1.9.3 allows SQL Injection via project quotas in the VMware Harbor Container Registry for the Pivotal Platform.
Impact
Hidde Smit from Cyber Eagle has discovered an User Enumeration flaw in Harbor. The issue is present in the "/users" api endpoint. This endpoint is supposed to be restricted to administrators. This restriction is able to be bypassed and information can be obtained via the "search" functionality.
Non-administrator users (such as those created via self-registration) can list all usernames and user IDs by sending a GET request to /api/users/search with parameter "username" and value "", as follows:
curl -X GET "https://<host>/api/users/search?username=" -H "accept: application/json" --user <user>:<password>
The vulnerability was immediately fixed by the Harbor team and all supported versions were patched. With the patched versions of Harbor, the username is required for search and we have removed the support for querying by email.
Patches If your product uses the affected releases of Harbor, update to either version 2.1.0 or 2.0.3 to fix this issue immediately
https://github.com/goharbor/harbor/releases/tag/v2.1.0 https://github.com/goharbor/harbor/releases/tag/v2.0.3
Workarounds There is no workaround for this issue
For more information If you have any questions or comments about this advisory, contact cncf-harbor-security@lists.cncf.io View our security policy at https://github.com/goharbor/harbor/security/policy https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13794
Harbor prior to 2.0.1 allows SSRF with this limitation: an attacker with the ability to edit projects can scan ports of hosts accessible on the Harbor server's intranet.
A User Enumeration flaw exists in Harbor. The issue is present in the "/users" API endpoint. This endpoint is supposed to be restricted to administrators. This restriction is able to be bypassed and information can be obtained about registered users can be obtained via the "search" functionality.