Live data from Hacker News

Carrot Disclosure: Forgejo

dustri.org

21–30 of 60 posts

Re: Carrot Disclosure: Forgejo

#21
post #15

This is a weird post to be honest. You've found a whole bunch of serious security issues, filed two PRs, one of which is adding some quotes because > Those aren't exploitable XSS, but it doesn't hurt to have a second layer of defense. The other suggests breaking clients that aren't using the more secure version of an OAuth method because > I can't think of any OAuth client that would like to [use it] That second one…

Closing the PR without providing feedback beyond "needs further discussion" does not engender said further discussion.

Re: Carrot Disclosure: Forgejo

#22
Did the author actually disclose this RCE or just open random PRs and claim there's an issue?

It doesn't appear like the author is acting in good faith, instead grandstanding in public because they feel superior.

Re: Carrot Disclosure: Forgejo

#23
post #21
post #15

This is a weird post to be honest. You've found a whole bunch of serious security issues, filed two PRs, one of which is adding some quotes because > Those aren't exploitable XSS, but it doesn't hurt to have a second layer of defense. The other suggests breaking clients that aren't using the more secure version of an OAuth method because > I can't think of any OAuth client that would like to [use it] That second one…

Closing the PR without providing feedback beyond "needs further discussion" does not engender said further discussion.

PR isn't a place for discussion about what or how to implement change in the first place, that should be forum/mailing list/issues

and there is open issue for that discussion https://codeberg.org/forgejo/forgejo/issues/8634

Re: Carrot Disclosure: Forgejo

#24
post #15

This is a weird post to be honest. You've found a whole bunch of serious security issues, filed two PRs, one of which is adding some quotes because > Those aren't exploitable XSS, but it doesn't hurt to have a second layer of defense. The other suggests breaking clients that aren't using the more secure version of an OAuth method because > I can't think of any OAuth client that would like to [use it] That second one…

> That second one is a good idea, but the maintainer is also right to ask for some discussion before introducing a breaking change.

The discussion seems to be already happening https://codeberg.org/forgejo/forgejo/issues/8634, author of the blog just did drive-by PR rather than looking at issue tracker

It's very much "I know better, do what I told you despise not thinking a second about any second order effects the change might cause" attitude that is so common with security people

Re: Carrot Disclosure: Forgejo

#25
post #21
post #15

This is a weird post to be honest. You've found a whole bunch of serious security issues, filed two PRs, one of which is adding some quotes because > Those aren't exploitable XSS, but it doesn't hurt to have a second layer of defense. The other suggests breaking clients that aren't using the more secure version of an OAuth method because > I can't think of any OAuth client that would like to [use it] That second one…

Closing the PR without providing feedback beyond "needs further discussion" does not engender said further discussion.

The response was, "needs a discussion," as in a post on `https://codeberg.org/forgejo/discussions`, rather than directly creating a PR.

There also was feedback saying approximately that they've been burned by security changes in the recent past and don't want to run into similar issues without due consideration.

Re: Carrot Disclosure: Forgejo

#26
post #2

The author's attitude is so off-putting. What gives? Did Forgejo hurt you? The Forgejo disclosure process looked pretty simple and straightforward to me. The bold and all-caps words that bothered the author are just making sure you know how to disclose vulnerabilities safely without leaking zero-day exploits to a wider audience than necessary. I'm also not impressed with a carrot disclosure that looks like this. Runn…

> I'm also not impressed with a carrot disclosure that looks like this. Running a python script to compromise a locally hosted instance? Bruh, you have physical hardware and host shell access. That python script could be doing anything including running as root.

> Show us the exploit hitting a remote server.

Watch out, their script works on HN too, as a proof here's me logging in to YOUR computer's root account (a bit more redacted for obvious reasons):

    $ python3 ./poc/chain_alpha.py --target dangus > out.txt
    $ grep Backdoor out.txt |  sed -r 's@[^:]+$@ [REDACTED]@g'
    [+]   Backdoor admin created: [REDACTED]
    $ grep IP out.txt |  sed -r 's@[^:]+$@ [REDACTED]@g'
    [+]   IPv4 address for dangus: [REDACTED]
    $ grep 'debug2: shell' out.txt
    [+]   debug2: shell request accepted on channel 0
    $ tail -n12 out.txt 
    ================================================================
    [+] COMMAND EXECUTION CONFIRMED!
    ================================================================
    
    Server-side output (received via SSH, with `set -x`):

      + id -u
      0
      + id -g
      0
    
    ================================================================
    $ sha256 ./poc/chain_alpha.py
    c10d28a5ff74646683953874b035ca6ba56742db2f95198b54e561523e1880d7  ./poc/chain_alpha.py

Re: Carrot Disclosure: Forgejo

#27
post #15

This is a weird post to be honest. You've found a whole bunch of serious security issues, filed two PRs, one of which is adding some quotes because > Those aren't exploitable XSS, but it doesn't hurt to have a second layer of defense. The other suggests breaking clients that aren't using the more secure version of an OAuth method because > I can't think of any OAuth client that would like to [use it] That second one…

> That second one is a good idea, but the maintainer is also right to ask for some discussion before introducing a breaking change. The discussion seems to be already happening https://codeberg.org/forgejo/forgejo/issues/8634 , author of the blog just did drive-by PR rather than looking at issue tracker It's very much "I know better, do what I told you despise not thinking a second about any second order effects the…

I believe the discussion in #8634 is for a different change, but one of a similar nature.

Re: Carrot Disclosure: Forgejo

#28
This entire post reads as rage bait. They’re mad because Forgejo has … a process? And what are these vulnerabilities, concretely?

> But given the sorry state of the codebase

I honesty want a refund on the 10 minutes I wasted reading this.

Re: Carrot Disclosure: Forgejo

#29

Did the author actually disclose this RCE or just open random PRs and claim there's an issue? It doesn't appear like the author is acting in good faith, instead grandstanding in public because they feel superior.

The author quite clearly outlines their reasoning for this in the article:

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

Re: Carrot Disclosure: Forgejo

#30

In the age of AI, carrot disclosure is potentially a full disclosure with extra steps. I'm no security expert, but with the context provided, the forgejo codebase and the outline of the redacted script, I think there is a good chance I could use codex to crunch through the vuln chain and reproduce the script.

Where's the vuln chain? Is it even obvious which APIs have been called?
Post reply on HN