I don’t get how that output showcases anything, unless he had run that against a known instance of forgejo so the owners of that instance could confirm that he actually executed code. But he’s only showing a text file, that’s like saying look I hacked super_secure_self_hosted_service:
python hack_it.py localhost:3000 Hacked!For all we know
chain_alpha.pyis just a bunch of prints.Also, even if it is real (which I don’t really doubt, but I have seen no proof) holding the information instead of properly disclosing it is just childish. It’s not a carrot methodology, it’s a stick one, and one without a carrot. This is the sort of thing you do to big companies with no morals, doing it to a small open source project is just wrong, they don’t have the manpower or money to redo the investigation you already did. Release a CVE, talk to the devs, and/or push a PR, but saying “I found a vulnerability but I won’t tell you about it” is just dumb.
I’m not sure why this Lemmy post was titled “RCE in Forgejo” when it just links to a yet-to-be-proven exploit, and the post itself is just a boast on not disclosing the vuln and telling maintainers to duplicate efforts. Feels rather disingenuous.
Other than that the idea of treating Forgejo as some sort of vendor to pull a carrot on is kind of a stupid joke. The security policy, even if lengthy, provides basis for collaboration. And these behaviors, although coming out the volunteer effort of a security researcher, does not exempt one from looking like an ass.
Also see the Mastodon thread for more.
Setting aside the Forgejo issues for a moment, I can’t quite see the logic behind the author’s description of a “carrot disclosure”.
As written, it’s a third option for disclosure, beyond 1) coordinated disclosure (often 90 days for the vendor to fix things) or 2) full disclosure (immediately going public, esp when the vulnerability is believed to be actively exploited). But what the author describes as the carrot is to publish only the output of a proof-of-concept, and then the onus is on the vendor to figure out both the vulnerability and the fixes.
This seems wildly irresponsible to me, to put the effort into writing a working PoC but then to willfully withhold it, so as to basically force the vendor into a wild goose chase. And that’s the best case scenario, when the PoC is actually legit. At worst, it’s a DoS against a vendor (causing them to re-audit code to find a bug that doesn’t actually exist, eg hallucinated AI slop) or is a form of defamation to scare users away.
Then there’s the issue of when it’s not a “vendor” per-se but a group of volunteers of an open-source project, which I will distinguish from commercial vendors as “maintainers”. Is it ethical to withhold an already-written PoC from FOSS maintainers, whom often do not have the material capabilities to do a full-scale audit when given basically no clues?
To be clear, I’m not a security researcher and have done zero disclosures of any form. But if I ever ran a project and received a so-called carrot disclosure, why shouldn’t I immediately call their bluff and treat it as full-disclosure? This situation seems like Schrodinger’s Cat, where the only way to rip away the uncertainty is to throw open the box. Worse case, the project suffers the reputational hit for having a legit vulnerability. But best case, the vulnerability is non-existent. But what this supposed “third way” purports to do is no different than sowing the seeds of fear, uncertainty, and doubt amongst users. Someone tell me how this isn’t one step away from extortion.
I think game theory would say that any and all recipients of “carrot” disclosures should always call the bluff, immediately and vocally. I don’t see any way for such disclosures to be anything but unnecessarily antagonistic. I refuse to credit the term with any legitimacy.
… Fortunately (or unfortunately depending who you’re asking), the RCE relies on open registration , and on a configuration option set to a non-default value (which is the case on some instances I’ve looked at, so nothing exotic), meaning that its selling value is pretty low/nonexistent …
From the posted blogpost
There’s an HN thread about this and yes it sounds like the guy is being stupid and/or there was a communications error. He submitted a PR for a potentially breaking change and it was closed as “needs discussion”. That is, instead of clicking “open PR”, he was advised to instead click “open discussion” and talk about the proposed change and its potential downstream effects. He instead got pissy and started spamming forums.
Alternatively: Forgejo reaches feature parity with GitHub.
What’s a good alternative? I’m not 100% sold on forgejo either due to some bugs and security issues I’ve run into as well, but I’ve found few self-hosted alternatives that are a good fit. I need very little beyond a git repo. But I like having the web UI for reviewing code and pull requests and basic issue tracking and need that to support OIDC, but otherwise I’m open. I want something relatively lightweight, fully FOSS, and telemetry and all other external communication can be disabled.
If I like having a web UI means you can do without it, git doesn’t require anything fancy. I just have my git repos on my server and push/pull from my workstations over SSH. It doesn’t require anything but git & SSH on the server. You can even collaborate with others by giving them a locked down account that can’t do anything other then interact with the git repo.
This approach certainly isn’t for everyone. The web UI can be super handy, but if you just want your own self-hosted git server, keep it simple.
Forgejo is fine. Don’t expose it to the internet unless you have to, or mirror your repos to Codeberg and let them worry about it.
What a dick that guy is.
I don’t really see what is so bad here… There was disclosure of type, but no reference to the exact code. This gives the maintainer a chance to reach out for specifics before bad actors can make a pseudo-zero day.
Is it the language you object to?
The entire attitude is shit. Could just contact the developers as outlined, instead of being a prude about it for some clout.
I understand what you’re saying, but Forgejo has an outdated and made-up-from-thin-air policy. From their security.md:
- You MUST disclose vulns to the author (why are we dictating instead of inviting participation)
- emails about vulns MUST be encrypted (I don’t even understand this one, this gives really strong “we don’t know how email works” vibes)
And it just goes on, like someone from 2003 wrote that policy.
Now, I’m going to agree with you that it’s a bit of a dick move to do the carrot dangle thing, but some vendors/devs just don’t respond without the pressure. And forgejo has been forced by github supporters to implement a security policy after trying to ignore it.
It seems that the author has some ongoing interactions with forgejo, and it would be great if these were disclosed in the article, but forgejo seems to need a kick in the pants, especially over an RCE, the forbidden sev 10 of vulns.
If you replaced Forgejo with GitHub then I would understand, but Forgejo isn’t a massive organization with hundreds of hired employees, it’s run by people in their spare time with the option of donations.
Anyone can help contribute, instead of doing that, this guy decided to try and get some clout by being an asshole because he is butthurt about some other interaction. If this guy went about it the proper way and then still got no answer or fix after months, then I would understand more, but he didn’t.
Most white-hat security researchers seem like dicks until you realize they are doing most of this research for free and have few ways to get groups to fix the issues beyond spending lots of time doing it themselves or exposing the vulnerabilities in some manner that doesn’t make exploits easy to create for the black-hats.
Can you please point out the hate speech you received? I can’t find any in the comments here, just people having different opinions.
As the time of writing the comment I am replying to has 15 up- and 3 downvotes. Doesn’t look like it has warranted hate speech.
Forgejo has a responsible disclosure policy, but this person seems like they just don’t want to deal with that and instead opted for the nuclear option immediately.
Did you read the policy and how complex it is? Did you look at the fixes they submitted and how simplistic they were that were rejected for not following a super complex policy meant for major issues in proprietary software? If an expert submits a fix with little to no risk and lots of potential for harm, why not have a simple process or just accept the fix? I wouldn’t want to follow that complex process and wait for embargos to pass before being allowed to suggest the fix for each of those issues.
Erm, did you read them? The policies aren’t complex at all, just submit the issue (and proposed fix if there is one) through a secure channel, that they’re happy to help set up. If you want to disclose the vulnerability, just wait until the embargo passes so there’s time to fix and have users update. There’s not really anything else you need to do here. This is pretty standard stuff that this person just seemed too lazy to participate in.
Of the three fixes submitted, only a single one was closed since it didn’t seem very major and would be a breaking change (which shouldn’t be made without prior discussion). The other two are still open, and a maintainer is helping to add tests for the fixes (since the author didn’t add them). The only comment that was somewhat negative was that security fixes should preferably follow the established guidelines. That’s all.
Yea. But did you read the security.md?
https://codeberg.org/forgejo/governance/src/branch/main/SECURITY-POLICY.mdUse an encrypted email to security@forgejo.org. If you can’t, tell them and they will set one up.
Seems very assholeish to not at least do that.
I don’t think you read the article.
Did you miss this part
with a lot of MUST/MUST NOT about what I must or mustn’t do should I decide to go this way.
Sounds like him being lazy.
Your comment said Forgejo has a disclosure process. The article says the author went with a carrot disclosure after reading the disclosure process and making a value judgement. Because your comment only mentioned Forgejo having a disclosure process, not an evaluation of the author’s evaluation of the disclosure process, it made you appear as if you had not read the article.
In your response to me calling that out, you offer an analysis. The author is lazy for using carrot disclosure over the defined disclosure process. That’s a valid take. I’m not going to disagree with that.
They explained that due to the systemic nature of the issues, many of which are across all forks of gitea, and the complex nature of the policy meaning disclosing each one individually and following the separate policies depending on the specifics of each issue, would require a very significant amount of time. Probably a day job worth for a while.
So, they could either drop it and give up, spend all of their free time for the foreseeable future properly disclosing each defect, or use the method they chose to get some level of attention on it without exposing details or breaking the security policy, but still letting both developers and users that there are issues.
I believe they were already frustrated by the responses to the fixes they did submit.
I get the frustration. It is how many big companies avoid responsibility, but that’s usually to avoid cost on actually fixing stuff. In a FOSS project, what’s the point of rejecting a simple fix because some complex process meant for complex issues in proprietary software that the security researcher can’t suggest specific fixes for wasn’t followed. Why fill out a bunch of “paperwork” and initiate a long embargo period before a fix is considered when the fix is already submitted and is simple enough and low risk and impact enough to not require more that a cursory review. It’s like asking a road engineer who sees a small pothole that only damages a few cars a year and offers to fill it because they are often affected by it to file a superior court case in order to report it, much less fix it.
So, it’s a matter of, give up because it’s too much of a burden to report, or announce in the most ethical way possible to incentivize fixes actually happening.
Alternatively, they could have sent the security team an email with the ‘carrot’ and saying “There seems to be fundamental, systemic, security issues in Forgejo; here’s some proof. There’s too much for me to raise individual reports, what are we going to do about it?”
I think there’s pros and cons to everything. That way would have been less of a dickhead move towards the Forgejo developers. But a big letdown to admins as they don’t know what’s up with the software they’re running on their servers. The way the author chose gives some new intelligence to admins, and they can now act on it, since it’s public knowledge. But it’s annoying to the devs.
I guess I as a Forgejo user am kinda greatful they did it this way. Now I got to learn the story and can allocate 2h on the weekend to see if my personal Forgejo container is isolated enough and whether the backups still work.
(But that’s just my opinion after reading one side of the story. Maybe there’s more to the story and they’re being a dick nonetheless…)
