The exploit, patched since April, only affects customers running on-premises versions of GitLab and doesn’t affect GitLab.com.
Anybody running on-premise GitLab servers need to patch for CVE-2021-22205, an exploit that was discovered in April, and which GitLab patched on April 14.
Evidently a lot of people didn’t get the message to install the fix, which is unfortunate because the vulnerability is being exploited in the wild.
According to the headline on one security website: “Tens of thousands unpatched GitLab servers under attack.” Another website says that black hats are taking advantage of the vulnerability to launch distributed denial of service attacks exceeding 1 Tbps.
We’ve been here before — too often to mention. Some IT folks don’t seem to get that if you’re going to run public facing servers, you absolutely have to keep your software patched.
For those who don’t know, GitLab is an open source DevOps platform. On the surface it’s a Git repository manager, similar to GitHub but with additional features — such as issue-tracking, and continuous integration and deployment pipeline features. Like GitHub, users can use the company’s hosted service at GitLab.com, or they can download the software and run it on-premises.
GitLab came to the forefront several years back when, in the aftermath of Microsoft’s purchase of GitHub which wasn’t well received by many open source projects, there was something of an exodus of GitHub users to GitLab.
At the time, many open source advocates were hoping that GitLab would become the dominant Git repository. That didn’t happen and GitHub has flourished and grown under Redmond’s ownership, although GitLab has certainly benefited, both from projects that migrated en masse at the time of the purchase, and since from projects that are leery of trusting their code with GitHub because of its perceived close association with big business.
Dealing With the Exploit
One of the reasons why users of the software have been slow to patch might be that when the vulnerability was first discovered, GitLab thought that the vulnerability could only be exploited by authenticated users, but that assessment was changed to include unauthenticated access on September 21.
It’s the self-hosted versions of GitLab (specifically, versions 11.9.x – 13.8.7, 13.9.0 – 13.9.5, 13.10.0 – 13.10.2) that are open to this exploit. GitLab says that administrators can determine their GitLab version at gitlab_url/admin, and has published instructions for determining if an instance has been compromised on its website.
“Due to the severity and potential impact from exploitation of this vulnerability,” GitLab says on it’s website, “it is imperative users upgrade to a fixed version as soon as possible: https://about.gitlab.com/update. This issue was remediated and patched in the GitLab 13.10.3, 13.9.6, and 13.8.8 release from April 14, 2021. If you can’t upgrade quickly, a hotpatch is available.
“If you have questions, you may post in our forum on this topic. If you have an active Support contract, please create a support ticket at support.gitlab.com.”
To prevent an event like this from getting out of hand in the future, GitLab is asking users to subscribe to its security alerts mailing list.
Christine Hall has been a journalist since 1971. In 2001, she began writing a weekly consumer computer column and started covering Linux and FOSS in 2002 after making the switch to GNU/Linux. Follow her on Twitter: @BrideOfLinux
Hi,
thank you very much for this information!