For the second time in less than a month GitLab has users scrambling to address a critical vulnerability in the community and enterprise editions of its DevOps platform that could impact continuous integration/continuous development (CI/CD) pipelines.
A GitLab CI/CD pipeline basically automates build, test and deployment steps in a software development lifecycle. As GitLab describes it: “At its most basic level, a pipeline gets code from point A to point B. The quicker and more efficient the pipeline is, the better it will accomplish this task.” Developers can trigger the automated workflow via code commits, merge requests or scheduled jobs.
The vulnerability, identified as CVE-2024-6385, gives attackers a way to run a pipeline in the context of any user within the GitLab system.
“This means that an attacker can potentially hijack the identity of any user, gaining unauthorized access to their projects, data, and code repositories,” says Howard Goodman, senior technical director at Skybox Security. “This can lead to a variety of malicious activities, such as injecting malicious code, accessing sensitive information, or disrupting the normal operations of development pipelines.”
The bug has a severity rating of 9.6 out of a maximum possible 10 on the CVSS scale, and affects GitLab CE/EE versions 15.8 prior to 16.11.6, 17.0 prior to 17.0.4, and 17.1 prior to 17.1.2.
GitLab urged users not to procrastinate on deploying its fix for the flaw. “This is a critical-severity issue,” the company noted in its advisory, “strongly” urging users to upgrade to the latest version as soon as possible.
Similar But Not Identical GitLab Bugs
The news comes after GitLab disclosed CVE-2024-5655 on June 26, which carries the same CVSS score of 9.8 and also gives attackers to run pipelines as arbitrary users. However, Goodman says that there are subtle differences between the two flaws.
“CVE-2024-5655 was more focused on the exploitation through specific API calls, whereas CVE-2024-6385 involves a broader range of potential attack vectors within the GitLab CI/CD pipeline process,” he explains. “The latter may present a wider attack surface, and potentially have more severe impact due to the range of actions an attacker can perform as any user.”
David Lindner, CISO at Contrast Security, says the new vulnerability suggests that GitLab either didn’t completely fix CVE-2024-5655 the first time around, or it discovered another path for exploiting the same kind of vulnerability. Both of these situations are pretty common in software he says, pointing to the Log4J vulnerability and the multiple related issues that researchers were able to dig up following its initial disclosure.
An attacker would require a valid user account within a specific GitLab environment in order to exploit the newly discovered flaws, Lindner says. “That means a prerequisite would be having an active account in that specific GitLab instance, which does decrease the likelihood of successful exploit,” he notes. “This would mean insider threat would be more likely. But if any of those accounts were or are compromised, an external attacker could take advantage of that.”
For its part, GitLab has assessed the vulnerability as something that involves little complexity for an unprivileged attacker to exploit.
“If the attacker has detailed knowledge of the GitLab environment and the vulnerability, exploiting it could be straightforward,” Goodman says. However, the complexity of the environment itself and required knowledge may serve as a barrier to less skilled attackers, he notes. “In addition, GitLab’s security measures and monitoring can detect and mitigate such attempts if they are properly configured and actively maintained.”
For organizations using GitLab, this week’s vulnerability marks the third severe bug in the DevOps platform that they had to contend with in just the last two-and-a-half months. In May, the company disclosed a maximum severity, improper access control bug that offered attackers a way to completely take over accounts. CISA added the bug to its Known Exploited Vulnerabilities catalog following extensive exploit activity in the days following the bug’s disclosure.
Source: www.darkreading.com