Gogs Vulnerabilities May Put Your Source Code At Risk
Four vulnerabilities in the Gogs open-source self-hosted Git service solution could enable attackers to steal, modify or delete valuable source code.
SonarSource researchers revealed in a blog published Tuesday that they discovered the four flaws last April while analyzing the popular solution for self-hosting source code. Gogs has more than 44,000 stars on GitHub and its Docker image has more than 90 million downloads.
Three of the flaws enable “argument injection,” which is an indirect form of command injection that can lead to reading, modification or deletion of code hosted on a vulnerable Gogs server. A fourth flaw also enables the “deletion of internal files.”
An authenticated user can exploit these vulnerabilities on an instance that has the built-in SSH server enabled. Exposed Gogs instances with registration enabled could allow an attacker to create an account to obtain the private SSH key necessary to exploit the flaws. If an attacker is not able to register their own account, they would need to compromise another account or steal a user’s private key to utilize the flaws.
The vulnerabilities are exploitable on Ubuntu and Debian instances due to their implementation of the env command, while Windows instances are not exploitable, as they do not use the env command.
The SonarSource blog post described the details of the first argument injection flaw, which relies on the split-string option of the env command. The env command is used to set environmental variables via SSH requests to the Gogs server. Using the split-spring option to divide two arguments allows the first half of the argument to be executed as a command on the server.
SonarSource planned to publish a second blog post, which will provide technical details for the remaining three flaws. The first blog provides mitigation options for the four flaws, including instructions to download a patch developed by SonarSource for version 0.13.0 of Gogs, in the absence of an official patch.
Besides installing the patch, which SonarSource warned could potentially cause functionality issues due to a lack of extensive testing, users can also prevent exploitation by disabling the built-in SSH server or disabling SSH entirely if it is not needed. Gogs users can also disable new user registrations to prevent an attacker from gaining the necessary private key to conduct the attacks.
A timeline published by SonarSource, starting from the initial report of the issues to Gogs’ maintainers on April 20, 2023, and concluding with the publication of the first blog post, shows that Gogs’ maintainers confirmed receipt of the report on April 28, 2023, and last responded to SonarSource on Dec. 5.
SonarSource published their own patch and blog post after seven months of no further contact from the Gogs maintainers, during which no fixes were released for vulnerabilities, according to the post. The blog authors said they informed the Gogs maintainers of their intention to publish the blog post on June 3, 2024.
Overall, SonarSource recommended users switch their source code hosting from Gogs to Gitea, a similar project which started as a fork of the original Gogs. The blog authors state that Gitea is more actively maintained and contains fixes for the four Gogs issues identified by SonarSource.
Gogs users can potentially detect exploitation of the first flaw by checking their network activity for env arguments starting with –split-string or its shortened form, -s. The second flaw, which involves argument injection when tagging new releases, could be detected on the network level by looking for an HTTP request with a path starting with /<user>/<repo>/_preview/<branch>/–. The user, repo and branch values will depend on the repository used for the attack.
The other two flaws, involving deletion of internal files and argument injection during changes preview, do not have reliable methods for exploitation detection, the authors said.
A Shodan search revealed 7,300 open Gogs instances on the internet, with the majority in China and nearly 600 in the United States, although the authors could not confirm how many of these instances were exploitable and said they did not have evidence of threat actors exploiting the vulnerabilities in the wild.
READ MORE HERE
