Live data from Hacker News

Anyone can access deleted and private repository data on GitHub

trufflesecurity.com

111–120 of 394 posts

Re: Anyone can access deleted and private repository data on GitHub

#111
post #4

I reported this on their HackerOne many years ago (2018 it seems) and they said it was working as intended. Conclusion: don't use private forks. Copy the repository instead. Here is their full response from back then: > Thanks for the submission! We have reviewed your report and validated your findings. After internally assessing the finding we have determined it is a known low risk issue. We may make this functional…

Honest question. Submitting these types of bugs only to get a: "we have determined it is known low risk issue..." seems like they really don't want to pay for someone else's time and dedication in making their product safer. If they knew about this, was this disclosed somewhere? If not I don't see them playing a fair game. What's the motivation to do this if in the end they can have the final decision to award you or…

No large company running a bug bounty cares one iota about stiffing you on a bounty payment. The teams running this programs are internally incentivized to maximize payouts; the payouts are evidence that the system is working. If you're denied a payment --- for a large company, at least --- there's something else going on.

The thing to keep in mind is that large-scale bug bounty programs make their own incentive weather. People game the hell out of them. If you ack and fix sev:info bugs, people submit lots more sev:info bugs, and now your security program has been reoriented around the dumbest bugs --- the opposite of what you want a bounty program to do.

Re: Anyone can access deleted and private repository data on GitHub

#112

People are so preoccupied with putting the code on GitHub. It’s like it doesn’t exist before it’s on GitHub. If you’re not gonna share it then it hardly matters. Use a backup drive. Git is distributed. You don’t have to put your dotfiles on GitHub. Local is enough.

Your laptop breaks in a way that your disk cannot be recovered. Now what? How often are you backing up your disk? Probably much easier to type "git commit" and "git push"

Am I really gonna get interrogated on HN for talking about automatic and redundant backup give me a break.

Re: Anyone can access deleted and private repository data on GitHub

#113

Earlier quoted context omitted.

Your laptop breaks in a way that your disk cannot be recovered. Now what? How often are you backing up your disk? Probably much easier to type "git commit" and "git push"

Am I really gonna get interrogated on HN for talking about automatic and redundant backup give me a break.

I wouldn't call the parent comment you're responding to an "interrogation" and I'm sorry you perceived it that way. You make a pretty extraordinary claim that local disk is better than a remote repository for storing/updating code for personal work - with no evidence to support this claim - so a followup question seems reasonable.

as far as "git is distributed" I don't know if that's the case if you keep it purely local, but hey, you seem to have it all figured out so good job.

Re: Anyone can access deleted and private repository data on GitHub

#114
post #4

I reported this on their HackerOne many years ago (2018 it seems) and they said it was working as intended. Conclusion: don't use private forks. Copy the repository instead. Here is their full response from back then: > Thanks for the submission! We have reviewed your report and validated your findings. After internally assessing the finding we have determined it is a known low risk issue. We may make this functional…

Honest question. Submitting these types of bugs only to get a: "we have determined it is known low risk issue..." seems like they really don't want to pay for someone else's time and dedication in making their product safer. If they knew about this, was this disclosed somewhere? If not I don't see them playing a fair game. What's the motivation to do this if in the end they can have the final decision to award you or…

The issue had been reported at least twice and was clearly documented. GitHub knew about this and had known for years. Their replies to the two notifications were even very similar.

GitHub clearly knew. Would you prefer that a vendor lie?

Re: Anyone can access deleted and private repository data on GitHub

#115

Earlier quoted context omitted.

The point of a bug bounty is for companies to find new security problems. If the (class of) problem is already known, it’s not worth rewarding.

I can see this argument making a bit of sense, but if they documented this 3 years after the issue was reported, they don't have a way to demonstrate that they truly already knew. At the end it boils down to: is Github being honest and fair in answering the bug bounty reports? If you think it is, cool. If you don't, maybe it's not worth playing ball with Github's bug bounty process

It doesn't matter if they knew. If they don't deem it a security vulnerability --- and they have put their money where their mouth is, by documenting it as part of the platform behavior --- it's not eligible for a payout. It can be a bug, but if it's not the kind of bug the bounty program is designed to address, it's not getting paid out. The incentives you create by paying for every random non-vulnerability are really bad.

The subtext of this thread is that companies should reward any research that turns up surprising or user-hostile behavior in products. It's good to want things. But that is not the point of a security bug bounty.

Re: Anyone can access deleted and private repository data on GitHub

#116

Earlier quoted context omitted.

In which case, yeah, thats a vulnerability. They shouldn't allow a short hash to match up against anything but public data.

It's common to use short hash in pull request, and then modify or rebase the commits. The solutions are: * Force people to use the full hash. * Get use to a lot of dead links. * Claim that it's a feature, not a bug.

* Force people to use the full hash for commits pushed now on?

Re: Anyone can access deleted and private repository data on GitHub

#117
post #106

Earlier quoted context omitted.

As the article pointed out, GitHub already publicly documented this vulnerability. My employer doesn't pay out for known security issues, especially if we have mitigating controls. A lot of people spam us with vulnerability reports from security tools we already use. At least half of them turn out to be false positives we are already aware of. In my opinion, running a bug bounty program at all is a net negative for u…

> As the article pointed out, GitHub already publicly documented this vulnerability. I'm honestly not yet convinced that is enough here - I've fallen victim to this without realizing it - the behaviour here is so far removed from how I suspect most user's mental model of github.com works. For me none of the exposed data is sensitive, but the point remains I was totally unawares it would be retrievable like this. If t…

The problem with this line of argument is that the fundamental workings of git are also surprising to people, such that they routinely attempt to address mistaken hazmat commits by simple reverts. If at bottom this whole story is just that git is treacherous, well, yeah, but not news.

There's a deeper problem here, which is that making the UX on hosting sites less surprising doesn't fix the underlying problem. There is a best-practices response to commiting hazmat to a repository: revoke the hazmat, so that its disclosure no long matters. You have to do this anyways. If you can't, you should be in contact with Github directly to remove it.

Re: Anyone can access deleted and private repository data on GitHub

#118
post #80

The biggest gotcha here is probably that if you start of with a private repo and a private fork, making the repo public also makes the fork "public". GitHub may very well say that this is working as intended, but if it truly is then you should be forced to make both the repo and fork public at the same time. Essentially "Making repo R public will make the following forks public as well 'My Fork', 'Super secret fork',…

Any time you make a private repo public it’s best to just copy that code into a new public repo and leave the private repo private. Otherwise have to audit every previous commit and every commit on every fork of your private code.

If I understand the issue correctly if you make the original repo public any private forks from other users are also effectively public. Right?

Re: Anyone can access deleted and private repository data on GitHub

#120
post #77
post #26

>This is such an enormous attack vector for all organizations that use GitHub that we’re introducing a new term: Cross Fork Object Reference (CFOR) Have we stopped naming vulnerabilities cute and fuzzy names and started inventing class names instead? Does this have a logo? Has this issue been identified anywhere else?

Introducing a new vulnerability... Git Forked™! chatgpt: Create a logo image of a fork impaling a small gnome named "code"

Much better name.

It's very formally called Cross Fork Object Reference (CFOR). But commonly known as Git Forked! (Including the exclamation mark).

Post reply on HN