Ready to give LWN a try?With a subscription to LWN, you can stay current with what is happening in the Linux and free-software community and take advantage of subscriber-only site features. We are pleased to offer you a free trial subscription, no credit card required, so that you can see for yourself. Please, join us!
An unusual, some might say hostile, approach to disclosing an alleged
remote-code-execution (RCE) flaw in the Forgejo software-collaboration platform has
sparked a multifaceted conversation. A so-called
"carrot disclosure
" in April has raised questions about the
researcher's methods of unveiling a security problem, Forgejo's
security policies, and the project's overall security posture.
Forgejo was forked from the Gitea collaboration and hosting platform in 2022. It is a project supported by the Codeberg e.V. nonprofit and is the software used by the Codeberg hosting service. The Fedora Project is also in the final steps of replacing its homegrown Pagure platform with Forgejo.
Carrot disclosure
In his disclosure
post on April 29, Security researcher Julien Voisin said that
it was Fedora's choice of the project as its collaboration platform
that had inspired him to "take a good look at Forgejo's security
posture
". He claimed he had found a number of security flaws in
Forgejo:
All in all, it took me one evening after work to find a good amount of vulnerabilities (adding to the one I got from looking at gitea at some point in the past), and chain some of them to obtain a full-blown RCE [...]
On April 27, Voisin had opened a few pull requests with the Forgejo project: a fix to quote attributes in a comment form, a change to remove a method that passed user-supplied strings to a command, and another to remove the "plain" OAuth authentication method. None of the pull requests included a description that might cause a maintainer to address the fixes as urgent for security reasons.
It also appears that he did not report any specific security flaws
following the project's rather detailed security
policy, even after being asked
by "Gusted" when they noticed
that Voisin had opened three pull requests with "some security
relation
". Voisin replied
that he was going through his list of low-impact bugs "that could
barely qualify as security issues worth reporting privately let alone
choreographing an embargo
". He also complained
that the policy had "a lot of MUST, MUST NOT, MAY
" requirements
in reporting a security problem and wondered how the policy was
enforced.
Rather than reporting the specifics of the RCE directly to the project, Voisin
chose to do what he calls a "carrot disclosure
", a term that he had coined
in 2024. He defined it as "dangling a metaphorical carrot in front of the vendor to
incentivise change
", though in actuality the approach sounds more like the
stick than the carrot. The idea is to demonstrate that the software is
exploitable and to force the vendor to "perform a holistic audit of its
software, fixing as many issues as possible in the hope of fixing the showcased
vulnerability
", or to lose users who are unhappy about running
known-vulnerable software. "Users of this disclosure model are of course
called Bugs Bunnies.
"
Fans of Looney Tunes
cartoons might observe that, as a rule, Bugs did not go looking for
trouble. Often he would be hunted or harassed in some fashion and then declare "of
course you realize, this means war
": but he did not instigate trouble. That
seems relevant here, because Voisin's approach was the opposite: to go looking for
trouble, and then to be provocative about it after a flaw is
discovered.
Voisin claimed to have found an RCE, apparently unrelated to the
issues he had opened pull requests about, that required a Forgejo
instance to have open
registration—in other words, to allow anyone to sign up to
use the platform—and for it to have "a configuration option
set to a non-default value
". He did not specify which
configuration option but said that it was enabled on some instances
that he had looked at. His example showed him running a Python script,
without revealing the actual code, that achieved an RCE against a
Forgejo instance running on a local machine.
He said, in his disclosure post, that he could try to resolve the issues one by one with more pull requests but decided against it:
I could disclose the bugs to Forgejo, they even have a Security Policy, with a lot of MUST/MUST NOT about what I must or mustn't do should I decide to go this way. But given the sorry state of the codebase (not their fault though, they inherited the gitea/gogs ones), I'm pretty sure I could spend another evening and find another chain, and odds are that others have a bunch as well. I could try to fix the issues one by one myself and send pull-requests, but even if I wanted, this is a systemic issue, there is little point in playing endless wack-a-mole.
He said he was told, after discussing the topic with a friend, to "put my money
where my mouth is, and just go with carrot disclosure that I usually advocate
for in this kind of situation
". After publishing the disclosure, he promoted it on
the infosec.exchange Mastodon server on April 29. It quickly gained
attention and became a topic of discussion on the Fediverse and was also shared
on Hacker News, Lobste.rs, and
other discussion forums.
Response
The public response was mixed and generally fell into two categories: those
critical of Voisin's approach, and those who took Forgejo to task for its
security policy and perceived problems. For example, Hans van Zijst said
that it was "an incredibly condescending way to talk about someone else's
work, and a horrible attempt to force volunteers to follow your
priorities
". Henry Catalini Smith said: "what
you've done here was below any reasonable standard of professional conduct, and
also very strange to me
". He said that he had recently begun looking at
Forgejo's accessibility bugs and thought it would be fun to work with the
project on solving them; it made no sense to him that a specialist in a type of
problem would want to "build a brand as someone this publicly hostile
" to
projects that had security problems.
On the Privacy Guides forum, "HackOrSwim" said
that the reporter had acknowledged that many of Forgejo's problems were inherited
when it forked from Gitea, but not that it would require a lot of resources to
correct those problems. "This is essentially technical debt, which doesn't
make it acceptable, but it makes it understandable why these issues are
there. It's a non-profit, volunteer-driven project.
"
On the other side, Tony Arkles said
that the policy "comes across as pretty demanding for a team that's
getting free support from a community member
", and called the
process grating. "I think I'm with the author on this one.
"
Elliot Speck, an information-security consultant and researcher, found
that the Forgejo security guidelines are "obnoxious and
pretentious
". He said the project was "too busy taking the
wrong things seriously
".
Follow-up
Voisin published
a follow-up with a summary of the events that took place after the
disclosure on April 30. He said that he had been "called a
handful [of] vile names
", received complaints that he had
"brought unwanted attention to an easy target
", and responded
to complaints that his conduct was unprofessional: "The terms 'not
professional' (as in 'not acceptable in a professional environment')
has been thrown around a lot, but nothing here is or was being done in
a professional context.
"
He also said that he'd learned that "various entities
" had revised
their opinion about what Forgejo is, and isn't, "which was the main goal of
the previous blogpost
". Despite the drama, though, Voisin said it had led to
some productive, good-faith conversations:
It seems that experimenting with odd vulnerability disclosure schemes is frowned upon. So I ended up sending an 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.
On April 30, the Forgejo project published a short response. It said that Voisin had been in contact with Forgejo's security team with his findings:
The issues raised concern defense-in-depth improvements and denial-of-service risks. There is no known RCE exploit possible without internal server credentials.
We believe these findings can be addressed publicly. The security team will open issues where approaches to implement new defensive measurements will be discussed, we believe there's no single answer and as such appreciate the opinion of other Forgejo contributors on this matter.
The statement that the RCE is not possible without credentials seems to be at odds with Voisin's claims, but without more information there's no way to ascertain which is the case.
Given the increasing ease of using LLMs to find security flaws, it's entirely likely that Voisin casting a spotlight has increased the number of people spending tokens on finding holes in the project. Some of them may not be as well-intentioned as Voisin. In the coming weeks and months it will be interesting to watch Forgejo to see what kind of security improvements are made, and what kind of security flaws come to light.