Gitlab suffers from a second security issue in less than a week
In less than a week Gitlab developers have had to get down to work, Well, a few days ago the corrective updates for GitLab Collaborative Development Platform 15.3.1, 15.2.3 and 15.1.5 were released, which resolved a critical vulnerability.
listed under CVE-2022-2884, this vulnerability could allow an authenticated user with access to the GitHub Import API remotely run code on a server. No operational details have yet been released. The vulnerability was identified by a security researcher as part of HackerOne's vulnerability bounty program.
As a workaround, the admin was advised to disable the import from GitHub feature (in the GitLab web interface: “Menu” -> “Admin” -> “Settings” -> “General” -> “Visibility and access controls » -> «Import sources» -> disable «GitHub»).
After that and in less than a week GitLab I publish the next series of corrective updates for their collaborative development platform: 15.3.2, 15.2.4, and 15.1.6, which fixes the second critical vulnerability.
listed under CVE-2022-2992, this vulnerability allows an authenticated user to execute code remotely on a server. Like the CVE-2022-2884 vulnerability that was fixed a week ago, there is a new API issue for importing data from the GitHub service. The vulnerability manifests itself, among other things, in releases 15.3.1, 15.2.3, and 15.1.5, in which the first vulnerability in the import code from GitHub was fixed.
No operational details have yet been released. The vulnerability was submitted to GitLab as part of HackerOne's vulnerability bounty program, but unlike the previous issue, it was identified by another contributor.
As a workaround, the administrator is recommended to disable the import from GitHub feature (in the GitLab web interface: “Menu” -> “Admin” -> “Settings” -> “General” -> “Visibility and access controls » -> «Import sources» -> disable «GitHub»).
In addition, proposed updates fix 14 more vulnerabilities, two of which are marked as dangerous, ten have a medium severity level and two are marked as not dangerous.
The following are recognized as dangerous: vulnerability CVE-2022-2865, which allows you to add your own JavaScript code to the pages displayed to other users through the manipulation of color labels,
It was possible to exploit a vulnerability by configuring the label color feature that could lead to stored XSS that allowed attackers to perform arbitrary actions on behalf of victims on the client side.
Another one of the vulnerabilities that was solved with the new series of corrections, is the CVE-2022-2527, which makes it possible to replace its content through the description field on the Incident scale timeline). Medium severity vulnerabilities are primarily related to denial of service potential.
Lack of length validation on Snippet descriptions in GitLab CE/EE affecting all versions prior to 15.1.6, all versions from 15.2 prior to 15.2.4, all versions from 15.3 prior to 15.3.2 allows an authenticated attacker to create a maliciously large snippet that, when requested with or without authentication, causes excessive load on the server, potentially leading to a denial of service.
Of the other vulnerabilities that were solved:
- The packet registry does not fully honor the group's IP allow list, GitLab was not properly authenticating against some Package Registry when IP address restrictions were configured, allowing an attacker who already possessed a valid deployment token will misuse it from any location.
- Abusing Gitaly.GetTreeEntries calls leads to a denial of service, allowing an authenticated and authorized user to exhaust server resources by importing a malicious project.
- Possible arbitrary HTTP requests in .ipynb Notebook with malicious form tags, which allows an attacker to issue arbitrary HTTP requests.
- Regular expression denial of service via crafted input allowed an attacker to trigger high CPU usage via a crafted input added to the Confirm message field.
- Information disclosure through arbitrary GFM references represented in incident timeline events
- Read repository content via LivePreview function: It was possible for an unauthorized user to read repository content if a project member used a crafted link.
- Denial of Service via API when creating a branch: Improper data handling on branch creation could have been used to trigger high CPU usage.
- Denial of service via issue preview
Finally, if you are interested in knowing more about it, you can consult the details In the following link.