Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Quick note that this is not an RCE in the typical sense that I can rock up to a Forgejo installation and execute code on the server. The attack vector here is via a template repo specified when initializing a new repo. The template repo could contain malicious code that then executes on the host server. So if you don't create new repos from mystery meat template repos, you should be ok.
    by dboreham
  • >So if you don't create new repos from mystery meat template repos, you should be ok.

    You should be OK, but if attacker takes over your user (or any user in your forgejo instance) they can execute code on the host server - as you said yourself. In other words, it allows them to achieve remote code execution, so it's a RCE.

    by msm_
  • Are you sure? The change says "A malicious template repository could be used to read arbitrary data from the Forgejo host" (emphasis added). Couldn't an attacker create a template repo and then immediately create a new repo from their own template, causing the Forgejo process to execute their template code on the server?
    by nightpool
  • The opex and security fine costs of moving off managed services like GitHub/GitLab are catching up.
    by innocent_name
  • Wouldn't most users considering or using Forgejo also have considered (or used) self-hosted Gitlab which would have the same opex / security costs (and much higher hardware requirements)?
    by davidee
  • This vulnerability, which doesn’t affect my installation, would take approximately 5 minutes to patch if it did. With that exception, my server will have had approximately 99.999% uptime over the last several years.

    It would take a boatload of such events to equal the opex of GitHub hosting. That’s not an excuse to run amok, but it’s far from tipping the scales in GitHub’s cost favor.

    by kstrauser
  • The amount of time I need to spend maintaining my Forgejo instance this year, even after accounting for this RCE, has been less than the amount of time GitHub has been degraded or unavailable this year.
    by lukeify
  • Wonder how long it took from report to patch. IME codeberg has one of the rudest security teams in oss (fair enough or not, irrelevant). https://news.ycombinator.com/item?id=47941590 Is quite relevant
    by mmsc
  • Is that linked submission "your experience" or is there something else you're basing that on? Because that article you linked is kind of strange, read through the comments on what you linked.
    by embedding-shape
  • Forgejo's security team received disclosure of this issue on September 4th. (source: I am a member of that team)
    by mfenniak
  • For those on version 15 LTS, this fix was released with v15.0.8.
    by miguelgrinberg
  • Updated mine now. The release notes[0].

    0. https://codeberg.org/forgejo/forgejo/src/branch/forgejo/rele...

    by snvzz
  • I'm just reading the code here:

      // Before template expansion, .git was removed so that a fresh repo can be initialized; remove it again in case
  // some template variable usage has conflicted with this directory and impacts git operations.
  if err := root.RemoveAll(".git"); err != nil {
    return fmt.Errorf("unable to remove .git folder")
  }
    Why the `err` isn't carried by the error message? For security? Then maybe log it internally?

    User/operator can't really fix the problem if you keep giving them information this vague.

    by nirui
  • Our forgejo instance got affected by this. I saw the news and thought we don't need to upgrade (yet), as registration is closed for new users, and users having access is only those we control. As it turns out, when in app.ini we have DISABLE_REGISTRATION = true, it doesn't actually disable registration... Even though no sign in or sign up form was rendered, the attacker used openid registration

    as in our config I had

    [openid] ENABLE_OPENID_SIGNIN = true ENABLE_OPENID_SIGNUP = true

    attacker created a fake openid server, registered this way, created like 100+ repositories, was able to create a superadmin account on forgejo, mint tokens, execute commands from the runner trying to escalate permissions - either via git hooks, or in runner itself. Luckily our runner was running on a separate isolated server, but potential damage could have been much worse.

    So yeah, everyone update ASAP if you don't want to spend half a day fixing the consequences (:

    by mrnaif
  • ``` 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. ```

    Any mirror?

    by rcleveng
  • The PR is still accessible https://codeberg.org/forgejo/forgejo/pulls/14300

        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.
    by sbx320
  • Relevant change:

       Security bug fixes

    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.
    by jzebedee
  • It looks like this is a bit less concerning if you have turned off open account registration.
    by hephaes7us
  • Since the release notes is currently unreadable due to codeberg rate limits, the two fixes in the release notes are:

    https://codeberg.org/forgejo/forgejo/pulls/14301:

    *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.

    https://codeberg.org/forgejo/forgejo/pulls/14301:

    ensure authorization reducer is accessed when checking editable PRs in APIs. When editing a git repo contents through Forgejo's API, a specialized security control is used to permit repository maintainers to edit branches that they do not own when an open pull request with the "allow maintainer edit" option is present. This specialized security control did not take into account API-specific security restrictions, such as repo-specific access tokens. As a result, it was possible for an API access token with restricted permission to make modifications outside of that restricted permission. The specialized security control has been updated to take into account API authentication security restrictions.

    ---

    So if like me you run a private forgejo instance with closed signups and limited repository creation, you can wait for the update. Otherwise maybe take it off the public internet for a bit?

    by Macha
  • This was my first thought after they disallowed LLM contributions.

    They may not use AI to check for vulnerabilities but attackers are going to which puts themselves at the disadvantage.

    by keel-control
  • Why can't you use an LLM to find vulnerabilities and then hand-code the fix? You don't even have to clean-room implement it; let the LLM write the code, and then reimplement, doing what you can to de-LLM-ify it.
    by bdcravens
  • Disallowing LLM contributions doesn't disqualify the use of LLMs to identify vulnerabilities.
    by striking
  • I really disagree with their acceptable usage policy, but you can't say it with certainity that LLM contributions would be a fix for this. They generate so much noise (as the primary incentive behind an independent LLM scan is often cheap contributor brownie points for your CV) that it also could lead to bogus PRs being approved or helpful PRs being lost in the noise.
    by titularcomment
  • Was this discovered by AI? Is all AI code 100% free of bugs?

    You are implying that just by allowing LLM contributions your product is free of bugs, and the LLM won't introduce new bugs. Of course, if the LLM introduces bugs, the solution is to add another layer of LLM looking for bugs, ad infinitum.

    Another post from today from Shopify, praising LLM to code their frontend, also stated that their LLM generated code is not ready to deploy, and needs to be reviewed:

    > It’s tempting to just point an LLM to the React Native codebase and try to one-shot the same features in native, but it doesn’t work. Even if you ask it to gather as much information as it can up front, freeze that into specs, task files, and then implement it, you end up with a huge amount of unmaintainable code that can’t be shipped. [...] each [build] must prove its behavior with tests, match the running app in a visual review, survive two adversarial code reviewers, and get a human's nod before it's committed and the next one starts.

    by otherme123
  • They did not disallow LLM contributions, and they definitely didn't disallow using LLMs to research security vulnerabilities. They only disallowed projects that are majority LLM-written.

    https://codeberg.org/Codeberg/org/commit/71149c7fc95ccfeae36...

    by burkaman
  • Only posting here because I've been asked about it. Gitea is protected against both of these issues.

    (bias note: part of project leadership of Gitea)

    Edit: As a note, security incidents happen to everyone and we shouldn't shame anyone for reporting them, especially as that'd otherwise cause less issues to be reported overall.

    by techknowlogick
  • If you upgraded from < 1.25.5
    by philipwhiuk
  • Your note is really important! Thanks for adding it. None of us are perfect.
    by dabeeeenster
  • > Gitea is protected against both of these issues.

    Is Gitea's immunity just incidental because it was written by a different person, or is it due to a deliberate defensive system that prevents such bug/mistake from occurring?

    by tredre3
  • You should change the URL to https://codeberg.org/forgejo/forgejo/milestone/139655

    > 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.

    by amiga386