GitLab Releases Urgent Security Updates for Critical Flaw
GitLab is rolling out security patches that fix a bug that could let attackers leverage scheduled security scan policies to run pipelines as an arbitrary user.
Bad actors exploiting the flaw could pass themselves off as a user, enabling them to take over permissions, access sensitive data, modify and run code. It could lead to data being data, compromised code, or software supply-chain attacks.
GitLab, an open source code repository and DevOps collaborative software development platform, this week released versions 16.3.4 and 16.2.7 for its Community and Enterprise editions. The versions include the security fixes and the organization is urging users to upgrade their installations to one of the versions immediately.
The new security updates come after security researcher and bug hunter Johann Carlsson – also known as “joaxcar” – uncovered the vulnerability, tracked as CVE-2023-5009, and reported it through GitLab’s HackerOne bug hunting program.
It’s a bypass of an earlier flaw (CVE-2023-3932) would give an attacker similar capabilities. That vulnerability was fixed in August.
Where as the earlier bug has a medium CVSS severity score of 5.3, the later flaw brings with it a critical severity score of 9.6.
Digging deeper into the threat, Alex Ilgayev, head of security research at application security posture management firm Cycode, said exploiting the latest flaw would let an attacker take advantage of GitLab’s scan execution policy feature. Running pipelines as any users would enable them to compromise a user’s private repositories.
“Scan execution policy allows configuring built-in scanners for GitLab projects, such as static analysis and vulnerability scanning,” Ilgayev said. “These scanners are running in dedicated pipelines with a predefined set of permissions.”
The earlier vulnerability allowed a threat actor to forget the identity of the policy file committer, hijack pipeline permissions, and gain access to any user’s private repositories. Pointing to GitLab’s issue tracker and source code, he said that “any user can easily exploit that vulnerability by changing the policy file author using the ‘git config’ command. The scan is done through the identity of the policy file’s last committer, effectively gaining the permissions of arbitrary users.”
GitLab has since updated the mechanism, enabling it to execute the security scans using a dedicated bot user with limited permissions.
However, “while GitLab didn’t release official information regarding the bypass, by inspecting the GitLab source code, the bypass seems to involve removing the bot user from the group and allowing the execution of the previous vulnerability flow again,” Ilgayev said.
GitLab instances running versions starting from 13.12 before 16.2.7 and all versions starting from 16.3 before 16.3.4 are vulnerable to exploitation if both the direct transfers and security policies features are enabled at the same time, Nick Malcom, senior security engineer with the organization, wrote in the alert.
“In order to mitigate this vulnerability in situations where it’s not possible to upgrade, it is required to disable one or both features,” Malcom wrote.
