I love Forgejo, but I also feel like git forges are huge attack surfaces, and wonder why we don't take more hardened approaches to building them from the start, when the expectation is public-facing.
It may be prudent to separate and isolate the actual git repositories, packages and of course CI from the project management features like issues and merge requests (that can be implemented as a standard web app).
Stupid scrapers are a major pain for public git forges right now, a radical change to reduce the surface would be to only offer git clone but no web view of the code (at leas to unauthenticated users).
Anything involving working with a checked out tree on disk with git is a minefield. A more hardened approach would be constructing the template tree directly via libgit2
What hailey said, and I really don't know the specifics about git / libgit2 implementations, but the ideal in my head would be roughly: treating git like a model layer somehow, and avoiding SQL-injection-like pitfalls (like this vulnerability) at that layer.
Maybe that's what a libgit2 implementation looks like, but I think ideal would be if .git wasn't a concern at all, and it's an implementation detail of on-disk git only. So whatever bad is in there becomes a git / libgit2 problem; for them to reject.
But I'm out of field here, and also want to stress I really do appreciate forgejo. :)
Same as any other project probably. I'm sure the developers don't try to ship insecure code, but they are time limited and generally focused on feature work.
This git endpoint is seeing a high influx of requests for this repository, to preserve the availability of Codeberg your search request will not be processed. Sorry for the inconvenience and please try again later.
That's something I haven't seen before. This URL works:
PR: Critical: fix: prevent template expansion from interfering with git repo initialization. When generating a new repository from a template repository, Forgejo clones the template repository, removes the .git folder, performs variable template expansion on files listed in .forgejo/template, and initializes a new git repository. During this process, variable template expansion could be misused in order to create a new .git folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.
First of all: would an attacker need to have write access to the template repository to launch this attack?
Secondly: isn't that access something that would be limited to admins anyways?
would an attacker need to have write access to the template repository
An ordinary user that can create a repository can turn it into a template (at least on Codeberg).
A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack.
You can now use your own template repository to gain code execution on the host.
stephank | 15 hours ago
I love Forgejo, but I also feel like git forges are huge attack surfaces, and wonder why we don't take more hardened approaches to building them from the start, when the expectation is public-facing.
pyfisch | 13 hours ago
Do you have a specific hardened design in mind?
It may be prudent to separate and isolate the actual git repositories, packages and of course CI from the project management features like issues and merge requests (that can be implemented as a standard web app).
Stupid scrapers are a major pain for public git forges right now, a radical change to reduce the surface would be to only offer git clone but no web view of the code (at leas to unauthenticated users).
hailey | 9 hours ago
Anything involving working with a checked out tree on disk with
gitis a minefield. A more hardened approach would be constructing the template tree directly via libgit2stephank | 4 hours ago
What hailey said, and I really don't know the specifics about git / libgit2 implementations, but the ideal in my head would be roughly: treating git like a model layer somehow, and avoiding SQL-injection-like pitfalls (like this vulnerability) at that layer.
Maybe that's what a libgit2 implementation looks like, but I think ideal would be if
.gitwasn't a concern at all, and it's an implementation detail of on-disk git only. So whatever bad is in there becomes a git / libgit2 problem; for them to reject.But I'm out of field here, and also want to stress I really do appreciate forgejo. :)
legoktm | 10 hours ago
Yogurt | 10 hours ago
Same as any other project probably. I'm sure the developers don't try to ship insecure code, but they are time limited and generally focused on feature work.
gnyeki | 15 hours ago
That's something I haven't seen before. This URL works:
https://codeberg.org/forgejo/forgejo/milestone/139655
wezm | 11 hours ago
The title here says Forgejo 16, but it also affects the current LTS release 15: https://codeberg.org/forgejo/security-announcements/issues/59
JulianSildenLanglo | 14 hours ago
First of all: would an attacker need to have write access to the template repository to launch this attack?
Secondly: isn't that access something that would be limited to admins anyways?
pyfisch | 13 hours ago
An ordinary user that can create a repository can turn it into a template (at least on Codeberg).
You can now use your own template repository to gain code execution on the host.
JulianSildenLanglo | 12 hours ago
Oh, yeah that's pretty bad.
Nicd | 3 hours ago
Phew, the title gave me a real fright until I noticed it was "Forgejo 16.0.4 has a critical security bug fix".
Been really happy with my own Forgejo instance, big ups to the team and community behind it. :)
pbsds | 12 hours ago
Does it affect gitea?
mewse | 12 hours ago
A comment on orange site said no:
sardaukar | 58 minutes ago
It did, but got fixed a while ago https://blog.gitea.com/release-of-1.25.5/ kinda worrying it took so long for Forgejo to fix it too (PR with the fix https://github.com/go-gitea/gitea/pull/36734)
ni5arga | 11 hours ago
From whatever I have read so far, this does not affect Gitea.
[OP] brn | 3 hours ago
I'd be curious to understand how did that happen without the fix coming back to Forgejo originally.
darkkindness | 18 minutes ago
Could it be LLM usage? I took a glance, the original Gitea fix was reviewed by Copilot, and Gitea's
CONTRIBUTING.mdhas the lineForgejo has the opposite stance regarding its own repository: