Skip to content
Tech News
← Back to articles

Carrot Disclosure: Forgejo

read original get Forgejo GitHub Repository → more articles
Why This Matters

This article highlights significant security vulnerabilities in Forgejo, a platform adopted by Fedora, raising concerns about its safety for users and developers. It underscores the importance of rigorous security practices in open-source projects to prevent potential exploits that could compromise sensitive data or system integrity.

Key Takeaways

Since Fedora moved from Pagure to Forgejo, I finally had an incentive to take a good look at Forgejo's security posture. The results aren't pretty to be honest: SSRF in a lot of places, no CSP/Trusted-Types, a bit of ghetto templating in javascript, cryptographic malpractices, overlooks in the authentication mechanisms (OAuth2, OTP, sessions/access handling, post-compromission recovery, …), a bunch of low-hanging DoS, information leak all over the place, various TOCTOU, … 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 them to obtain a full-blown RCE, some secrets leaks, a bunch of persistent account access, a handful of OAuth2 privesc, …

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. 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, I'm pretty sure I could spend another evening and find another chain. I could fix the issues myself and send pull-requests, but oh well.

I discussed the conundrum with a friend of mine, and was told to put my money where my mouth is, and just go with carrot disclosure that I usually advocate for in this kind of situation:

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.

So without further ado: