Forgejo apparently has a systemic lack of good security practices in their codebase, resulting in this “carrot” disclosure:
Carrot Disclosure, dangling a metaphorical carrot in front of the vendor to incentivise change. The main idea is to only publish the (redacted) output of the exploit for a critical vulnerability, to showcase that the software is exploitable. Now the vendor has two choices: either perform a holistic audit of its software, fixing as many issues as possible in the hope of fixing the showcased vulnerability; or losing users who might not be happy running a known-vulnerable software. Users of this disclosure model are of course called Bugs Bunnies.
The result of a proof of concept of an RCE chain against Forgejo is shown in the post, but the source code of the PoC is not shown.
Any thoughts about this model of disclosure from a defender / vuln management / asset management perspective? I personally think that this was useful to know as a defender, and indicates that someone out there is almost certainly sitting on some Forgejo bugs already. I’m curious to hear other people’s thoughts though.
I think it’s pretty gross, tbh. The method of disclosure without anything like verifiable proof, and a nasty attitude from the “researcher.”
I’ll also add that as far as I can tell, the only attempt to actually contact the maintainers was via a PR that was tangentially related. No full PoC was provided.
Carrot disclosure (really seems like stick disclosure) should be a last resort, not first. Since the maintainers have not been provided details of the issue, this notice serves to attract attackers before defenders can take meaningful action.
I dont think its useful as a defender, sadly. If I run Forgejo, how is this supposed to help me defend it other than telling me to disable opem registrations? They could have worked with the maintainers, responsibly disclosed and Forgejo would have released a patch that would help me defend while not informing attackers that there is something there (if there actually is). But they decided to be a jerk because their PR didnt pass, there was no conversation and they couldnt be bothered to do the right thing for us all.
Thanks for the replies so far! I will say that I disagree and that I think Forgejo is a juicy enough target now that the researcher here is very likely not the first to find these bugs, and that a project having deep systemic issues isn’t something that repeatedly fixing specific bugs is going to address. However, my friends over at Treehouse dot systems let me know that they’ve talked with the researcher and has a good conversation, so will see what comes out of that: kouhai, of the health issues: "@oilheap@infosec.exchange @cxiao@infosec.exchange…" - Treehouse Mastodon
I posted this on Mastodon as well, but I had a thought related to the “this kind of disclosure is unfair to a volunteer project” defence:
I don’t think the following is a better outcome / use of volunteer resources either:
Disclosure process is followed
Patch is done
PoC code is released
PoC is modified to exploit a very similar but unpatched bug because the bug class still exists in the software
Repeat
Volunteer resources are now dedicated to reactively handling new specific exploits rather than fixing the entire class of bugs
The “systemic issues” are quoted by the author whose maturity I find lacking and does not hold sway with me nor is there evidence fixing bugs wouldn’t solve the issue. Sounds like defeatism and laziness on the blog authors part.
It is the first release of the bug (how defenders actually know about it) and how it is remediated that matters and is under scrutiny in this case. And again I ask, what does this do to help defend people running Forgejo? Is there a patch widely available by upstream sources that has been reviewed by maintainers that I can deploy? Sadly no.
I feel like “carrot disclosure” takes an adversarial stance towards project maintainers. It assumes that they don’t want to understand and fix the issues. (This can be true in some cases, but shouldn’t be the default)
If I was a maintainer receiving this kind of report, my first impression would be that it’s clout-chasing and/or slop: A supposed proof of an exploit, without any useful information to reproduce and fix it.
A valid security report being ignored is a problem, but this approach doesn’t seem good for anyone except the reporter.
IMO, this is why full disclosure still has its place. Sure, you should try coordinated disclosure to reduce how exposed users are, but if the vendor isn’t responsive, go ahead and release the details. That way users, sysadmins and security folks can try to patch it or deploy mitigations.
Letting users know that a secret vuln exists creates more FUD without helping them do anything about it.
Restrictive security policies, like the one that Forgejo has, seem actively hostile to people who report vulnerabilites though. If somebody wants to help, but you make them jump through too many hoops, chances are they won’t want to help you anymore.
Unfortunately I think systematic fixing of a bug class in direct response to a disclosure deadline / active exploitation in the wild is usually not what happens; not in commercial software and especially not in a volunteer project with limited resources. I take your point about some of this being speculative, but in practice I think some outcomes are much more likely than others.
The “researcher” attempted a single PR that really wasn’t fully related to findings
Upon closing, this was the next step
Do I have that correct? If so, this is a wildly inappropriate way to handle disclosure regardless of what the maintainers would or would not do with the information. They never got the chance, since the actual PoC was never provided.
I don’t think it was the intention of this PR to fix this particular bug or any particular vuln; as stated in the blog post this is an attempt to fix one of many systemic issues.
I think something else that may be missing here: The researcher here is an experienced security engineer, not a random script kiddie. I don’t know them personally, but from their previous work I think chasing clout is an unlikely motivation here.
I’m not claiming it was clout chasing. Never said that at all. But if there was in fact no attempt prior to this disclosure to provide a PoC, that’s straight-up bad cricket.
Oh, I wasn’t trying to cast aspersions on that specific researcher or claim they’re doing this clout.
My point was about carrot-disclosure-style reports in general. Since they don’t include information that allows you to identify and reproduce the issue, it would be hard for maintainers to distinguish such a report about a legitimate vulnerability from slop.
LLMs and Script Kiddies are already making up non-existent vulnerabilities, so going from that to making up the output of non-existent exploits doesn’t seem like much of a stretch. However, it would make it more time consuming for maintainers to verify whether the vuln actually exists.
The systemic issue you mention is real, I just don’t think this is the right approach to solve it.
FWIW, the researcher made several good faith PRs to fix pretty systemic issues/code smells/do exactly the kind of volunteer security auditing people are asking for: Gitprotocol-v2(5)) and will produce.
I personally cant describe a slew of public PRs that dont past tests and are followed up by an edgy blog post threatening release several days later as good faith
Clout-chasing was my take on it, too. Especially after the first post was deleted, it was reposted to another Fedi instance (I don’t know if it’s still up or not), and then it was posted to Bluesky. This did not seem like anything other than trying to get clout with that pattern and timing.
This and this are important (and I think part of the value of publishing this information for defenders)
The Netherlands deployed a sovereign software forge in the form of a public forgejo instance.
Various entities, including some with security teams, revised their judgment about what Forgejo is and isn’t, which was the main goal of the previous blogpost.
And in the end, the actions taken:
Nonetheless, some productive good faith conversations have been had as well, and it seems that experimenting with odd vulnerability disclosure schemes is frowned upon. So I ended up sending and email to Forgejo security team, containing: an apology, a bit about my reasoning for proceeding with carrot disclosure, recommendations about what to harden/review, and a bunch of commented exploits/proof-of-concepts as attachment. We’ll see how it goes.
Maybe it’s because I’m familiar with this researcher’s previous work, but the “clout chasing” accusation is so weird for me. This situation is closer to “you got a volunteer security audit, code patches included, from a very skilled web application security engineer”.